Searching and Inserting: Arrays vs Linked Lists

[WingedPanther]

His issue with macros is pretty simple: they can avoid type checking, which makes them far less safe. That said, he strongly encourages #define for things like include guards. C++ was designed to make macros almost completely unnecessary, which is my biggest problem with wxWidgets.

[outsid3r]

Well said, that's exactly where C++ aims.

[TkTech]

The name flew over my head in an incredibly daft way. Anyways, what do you say WingedPanther to him not only liking but recommending wxWidgets? And macro's will always, always be required. Why would you add overhead to a compiled program when it could be done in the preprocessor stages? Ex: Debug macros, varadic macros, ect..,

[WingedPanther]

One of the things I like about Bjarne is that he doesn't speak in absolutes. I think he likes wxWidgets because it was one of the first cross-platform GUI toolkits, but there are many others out there now.

I think macros have a place, but they should be used with caution.

[outsid3r]

In my opinion macros are really a great feature both in C and C++, but many things changed in C++ and we don't need to use macros excessively like in C. The main advantage that C++ can take from macros are definitions like natural or mathematical constants, like:

[highlight=c++]
#define PI = 3.141592653589793238f
#define SPEED_OF_LIGHT = 299792458
#define SECONDS_PER_DAY = 86400
[/highlight]

and not much more (besides standard doings like protection from re-inclusion, pragmas, conditional compilation for multi-platform code, debugging, etc.)

Like you said, of course that macros are required and they are a really great feature of C and C++ but it's non-sense to use macros like we used in C to do things like:


Generic code to return the max value:

[highlight=C++]
#define GET_MAX(a, b) (a > b ? a : b)
[/highlight]

This kind of things are sometimes used in C but should be really avoided in C++, we should use templates instead which are much more powerful, generic, specialized and safer to use.


An example of a function specialized only for int, float and string:

[highlight=C++]
template<typename T>
T get_max(const T& first, const T& second);


template<>
int get_max(const int& _F, const int& _S)
{
return _F > _S ? _F : _S;
}


template<>
float get_max(const float& _F, const float& _S)
{
return _F > _S ? _F : _S;
}


// Returns the biggest string
template<>
string get_max(const string& _F, const string& _S)
{
return _F.size() > _S.size() ? _F : _S;
}
[/highlight]


For variadic macros i don't see any use in C++ but in C it's ok, we don't need to rely on VA_ARGS in C++, i prefer to use a function that for receive a random number of params uses a list or other kind of generic dynamic array.

[WingedPanther]

I would implement:

#define PI = 3.141592653589793238f
#define SPEED_OF_LIGHT = 299792458
#define SECONDS_PER_DAY = 86400

as

const double PI = 3.141592653589793238f
const int SPEED_OF_LIGHT = 299792458
const int SECONDS_PER_DAY = 86400

[outsid3r]

There is nothing wrong with your representation, and i would even prefer it to define non natural or mathematical constants, but for really natural and mathematical constants i think that i may prefer defines, like you can see in some libraries like math3d.h for example.

EDIT:

I found very recently in a book named "effective c++" some information about the advantage of using const representations to define constants instead of using defines, i think that it's worth mentioning:


"This Item might better be called "prefer the compiler to the preprocessor," because #define is often treated as if it's not part of the language per se. That's one of its problems. When you do something like this,

#define ASPECT_RATIO 1.653

the symbolic name ASPECT_RATIO may never be seen by compilers; it may be removed by the preprocessor before the source code ever gets to a compiler. As a result, the name ASPECT_RATIO may not get entered into the symbol table. This can be confusing if you get an error during compilation involving the use of the constant, because the error message may refer to 1.653, not ASPECT_RATIO. If ASPECT_RATIO was defined in a header file you didn't write, you'd then have no idea where that 1.653 came from, and you'd probably waste time tracking it down. This problem can also crop up in a symbolic debugger, because, again, the name you're programming with may not be in the symbol table.

The solution to this sorry scenario is simple and succinct. Instead of using a preprocessor macro, define a constant:

const double ASPECT_RATIO = 1.653;

This approach works like a charm. There are two special cases worth mentioning, however.


First, things can get a bit tricky when defining constant pointers. Because constant definitions are typically put in header files (where many different source files will include them), it's important that the pointer be declared const, usually in addition to what the pointer points to. To define a constant char*-based string in a header file, for example, you have to write const twice:

const char * const authorName = "Scott Meyers";

For a discussion of the meanings and uses of const, especially in conjunction with pointers, see Item 21.

Second, it's often convenient to define class-specific constants, and that calls for a slightly different tack. To limit the scope of a constant to a class, you must make it a member, and to ensure there's at most one copy of the constant, you must make it a static member:

class GamePlayer {
private:
static const int NUM_TURNS = 5; // constant declaration
int scores[NUM_TURNS]; // use of constant
...
};

There's a minor wrinkle, however, which is that what you see above is a declaration for NUM_TURNS, not a definition. You must still define static class members in an implementation file:

const int GamePlayer::NUM_TURNS; // mandatory definition;
// goes in class impl. file

There's no need to lose sleep worrying about this detail. If you forget the definition, your linker should remind you."