What's your favorite Programming goodie?
- Thread starter SD-[Inc]
- Start date
![SD-[Inc]](/board/data/avatars/m/5/5599.jpg?1710981566){kind=avatar}
Any language/platform you like...
spindoctor
New member
this might be slightly off topic but i am totally in love woth eclipse, especially after i had to go into eclipse api programming.
it is simply the best specimen of software design i have ever seen.
it is simply the best specimen of software design i have ever seen.
Cryptic cpp macros:
(was sent to LKML a few days ago. Explanation here
http://lwn.net/Articles/226205/)
Code:
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) \
+ sizeof(typeof(int[1 - 2*!!__builtin_types_compatible_p(typeof(arr), \
typeof(&arr[0]))]))*0)(was sent to LKML a few days ago. Explanation here
http://lwn.net/Articles/226205/)
soylent
New member
My favorite c++ construct is abstract baseclasses(ABC's). A class with virtual functions without implementation so that an instance of the object cannot be constructed. It is simply an interface.
Implementing a class with that interface is as easy as deriving a class from the ABC.
This is how many games implement their engine interfaces. A .dll file implements a class using that interface, and the program may call a function that retrieves an instance of that class typecasted to the baseclass from the .dll.
If the engine is updated the interface will generally stay the same and as long as that is the case the game does not need to be recompiled(!), which avoids breaking any old user MODs that are not longer being updated. The game may also ignore implementation details such as what api is actually being used(openGL/direct 3d 8 or 9, openAL/direct sound) once an interface has been retrieved and simply treat it like a black box with well defined behaviour as described in the documentation for the baseclass.
edit: Oops, no, I think I prefer unnamed namespaces to even that. I use them so much that they are invisible to me. When you have a namespace without a name everything within it will act as a global variable, except that the namespace really has a name used internally by the compiler that is guaranteed unique to this file, so they are global, but only visible within this cpp file. Thus you get a sweet tradeoff between truly global variables which allow action at a distance(including cryptic bugs), and encapsulated variables which often feel like programming with your gloves on. They are so terribly useful because you can't have anything but int constants within a class; here you can have arrays of floats initiated by an initiator list, arrays of characters, cstrings and whatever you wish without being afraid of name-collisions in a larger project. These should preferably be used as constant values or you're going to break re-entrancy and mt safety of code.
Singletons can be a bit of a pain. "It makes no sense to have more than one of x" tends to get outdated. And if you rely on a static member function to return a pointer to a static member instance of the class itself you don't know in which order multiple singletons are created or destroyed, which may result in bugs if they talk to each other while in their CTOR or DTOR.
Implementing a class with that interface is as easy as deriving a class from the ABC.
This is how many games implement their engine interfaces. A .dll file implements a class using that interface, and the program may call a function that retrieves an instance of that class typecasted to the baseclass from the .dll.
If the engine is updated the interface will generally stay the same and as long as that is the case the game does not need to be recompiled(!), which avoids breaking any old user MODs that are not longer being updated. The game may also ignore implementation details such as what api is actually being used(openGL/direct 3d 8 or 9, openAL/direct sound) once an interface has been retrieved and simply treat it like a black box with well defined behaviour as described in the documentation for the baseclass.
edit: Oops, no, I think I prefer unnamed namespaces to even that. I use them so much that they are invisible to me. When you have a namespace without a name everything within it will act as a global variable, except that the namespace really has a name used internally by the compiler that is guaranteed unique to this file, so they are global, but only visible within this cpp file. Thus you get a sweet tradeoff between truly global variables which allow action at a distance(including cryptic bugs), and encapsulated variables which often feel like programming with your gloves on. They are so terribly useful because you can't have anything but int constants within a class; here you can have arrays of floats initiated by an initiator list, arrays of characters, cstrings and whatever you wish without being afraid of name-collisions in a larger project. These should preferably be used as constant values or you're going to break re-entrancy and mt safety of code.
Singletons can be a bit of a pain. "It makes no sense to have more than one of x" tends to get outdated. And if you rely on a static member function to return a pointer to a static member instance of the class itself you don't know in which order multiple singletons are created or destroyed, which may result in bugs if they talk to each other while in their CTOR or DTOR.
Last edited:
