Here is a coding style idea I recently fell in love with. It works in C/C++ thanks to macros.
Archive for November, 2012
I am a strange developer.
My preferred development environment is GCC running in a simulated BASH shell on Windows. This madness all started well over a decade ago when I first discovered DJGPP, a GCC for DOS. This means GCC was my first C and C++ compiler.
Now sure, like most kids (?!) I used Visual C++ in College. That was mainly for my school projects though. Whenever it was me time, I was rocking the DJGPP. To be honest, I can’t really remember when I switched away from DJGPP, but I’m fairly certain I was still using it in 1999.
End of 1999 I was hired by long forgotten game developer Sandbox Studios as a GameBoy programmer. I had been dabbling with the GameBoy homebrew during the summer of 1999, made some little games, and won some stuff in a contest (Flashcarts). This lead to me using a GameBoy assembler called RGBDS (Rednex GameBoy Development Suite), which was a great little macro assembler suite. All command line.
My point: I’ve been comfortably working in command lines and shells for a long time. And I do it on Windows, where everybody else uses Visual Studio. I treat my Windows as a Linux box.
For the past decade, Cygwin and MinGW/MSYS have been the go-to ways of working Linux’y on Windows. I used to use a lot of Cygwin, especially since all the major video game console toolchains of the time were GCC based, and Cygwin did a much better job at simulating/hosting/building a GCC cross compiler. GameBoy Advance, PlayStation, though there were some alternatives (SN, CodeWarrior), in my books GCC was the way to go.
Today I rarely use Cygwin, but I always keep it around. Instead I use MinGW, which is a GCC port with a mostly compatible set of Win32 libraries, and MSYS (a minimal Bash/Cygwin like environment). It’s had its rough moments over the years, but for my needs I find it to be the better of the two. Cygwin’s goals are to simulate Unix on Windows. MinGW/MSYS’s goals are to target Windows with GCC. Why half-ass it?
A few months back I did this little investigation in to C++11 support across compilers. The goal here was to figure out what C++11 features I could safely use today. I also ended up creating a useful list of compiler versions sorted by platform. I will continue, at least for the near term, updating this list as I see changes.
This post is a follow up to that. I’m more familiar now with the actual use of many of these ‘nextgen’ features, so this post is a brief on certain features I really want to use, and why I can or can not use them.
I did a post some time ago on a threading library called TinyThread++. You can find it here.
Like always, the following is just a collection of notes.
Item 1: TinyThread++ is an almost functionally equivalent alternative to C++11 threads, but instead of taking multiple arguments to the thread it takes a single void*. When C++11 support improves everywhere, that will be the time to switch. But in the meantime, a void* is a good compromise.
Item 2: Whenever I describe how and why a member function is different than a global/static function, I often say that a member function has a “secret 1st argument, the ‘this’ pointer”. Heck, if I was going to build a C++ compiler, I would implement it like this. So for the longest time I just assumed this is how others implemented it.
If this is true, then it should be possible to convert a member function in to a “void Func(void*)”.
* * *
Long story short, this behavior is forbidden by the C++ standard. That said, it works in GCC, but fails in MSVC. In GCC’s case, while it does work, it invokes a warning known as “pmf-conversions”. You can explicitly disable the warning with “-Wno-pmf-conversions”, but given that this just doesn’t work in Visual Studio it’s probably unwise to do in the first place.
My nice solution was to add a static proxy function that takes a single “this class” pointer, and call the function as if it was a member of the class (because it is).