Re: g++ 3.4.5 doesn't zero-initialize
Alf P. Steinbach wrote:
Happily it turned out that it's only in the context of a memory
initializer list that g++ goofs up the default initialization, so the
code's now
struct WndClassEx: WNDCLASSEX
{
WndClassEx(
cppx::WideString const& name,
Params const& params
)
//: WNDCLASSEX()
{
*static_cast<WNDCLASSEX*>( this ) = WNDCLASSEX(); // MinGW
g++.
While your code may look more OO-like I would always prefer to use
memset for POD types.
memset(static_cast<WNDCLASSEX*>( this ), 0, sizeof(WNDCLASSEX));
does the job too and works most probably with any existing C++ compiler
that understands static_cast. And since memset is mostly an intrinsic
function it will usually not create any runtime overhead too.
Honestly, the calendar is 2009 by now, but I'd not rely in value init
even of current compielrs -- at least without first checking the
version and include some defense cludges in code should it migrate
away...
And by the way, the gdb debugger is driving me crazy.
:-)
I successfully avoided gdb for at least the last 15 years. Fortunately
gcc can create debug infos that is readable by other debuggers too.
Too bad -- if doing windows, why not use the windows toolset? I doubt
gdb will ever come close to Visual's... If your prog is portable, it
will go in VS express, if not -- what is the wisdom behind locking
into a compiler that is poorly supported on the target platform?
VS has the second place in the list of buggy or incomplete C++ compilers
in my experience. (The first place was Borland.)
On the contrary, to avoid a compiler lock-in one should compile the code
with at least 2 different compilers.
ACK.
However, I had to provide a number of declarations of Windows API things
not supported by the g++ Windows headers and import libraries.
I haven't tried on Windows, but gcc does not ship with a recent SDK. So
I usually use the platform specific SDK files with gcc.
And if porting win code away, why to an archaic version of gcc
instead of a current?
g++ 3.4.5 *is*, unfortunately, the still current version of MinGW. :-(
cygwin with gcc4 package is at 4.3.2 as far as I know.
There are of course "unofficial" Windows builds of later g++ versions
since g++ is into version 4.x on *nix.
Whatever is an official build of a gcc on the windows platform?
But I think it's best (at least for my purposes) to write code that will
compile with current versions of popupular compilers.
Indeed, if someone else should compile your code you have no choice.
I tend to avoid uncommon C++ idioms in such cases unless I really need
them. Doing that I am able to compile some of my current code even on
the very old IBM compiler (Visual Age C++ 3.0). It takes about one tenth
of the time of gcc to compile a larger project.
The functionality of simple OO wrappers like your WndClassEx will almost
not depend on any C++ feature that is less the 15 years old.
Marcel