🚀 go-pugleaf

"Ian Knowles" <ian@who.net.nospam> wrote in message
news:Lfxj5.74643$N4.1973768@ozemail.com.au...
> "John A. Grant" <jazrant@zsc.nrcan.zc.ca> wrote:
>
> >So what's the prognosis for BC++ 5.02?  All I want is a good
> >Win32 API C++ development system - I don't want Delphi,
> >Builder, OWL or VCL or any of that stuff. Just the straight Win32
> >API. I've been led to believe that Builder isn't a complete a
> >development system as BC++ 5.02, so I've stayed with BC++
> >5.02
>
> IMHO the only sensible thing to do with BC++ 5.02 is to leave it
> behind ASAP. Not only will you continue to have issues with such API
> headers but if you try to write *standard* C++ you'll end up being
> very unhappy indeed.
>
> I have also found the 5.02 compiler to be quite buggy (e.g. I can all
> too easily produce code that upon throwing an exception will attempt
> to execute a destructor for a local object [especially a string
> object] that [due to the execution path] had never actually been
> constructed [result == GPF]).
>
> I think that C++ Builder [version 4 patch 2 at least] is a reliable
> and (quite reasonably) standard conforming compiler. If you're worried
> about RC file editing then you might wish to continue to use 5.02
> simply for the resource files (I have actually got used to editing RC
> files as text after getting sick of the 5.02 resource editor ripping
> out important comments and conditional pre-processor macros :).

    Thanks for the comments. I received a pointer to a site
    where I can get a new <commtrl.h>, but there doesn't
    seem to be any ongoing update of this stuff from Borland.
    I hate to admit it, but I think you're right and I may have to
    abandon ship and go with VC++.  The SDK seems to be
    updated almost daily and it always has the latest stuff.
    Unfortunately, most of the #Include files are VC++-specific.
    Well, not really - it's just that they don't accomodate BC++.
    One of the issues is the #pragmas. Luckily, both VC++
    and BC++ use things like pshpack*.h, which helps. BC++
    has support for both Win16 & Win32 and uses /include/win16
    and /include/win32 to keep this stuff separate. That
    immediately causes a problem with the #include files because
    VC++ is Win32-only.

    I have not had any problems with the BC++ IDE or with the
    code that's generated. But I don't use OWL and my C++
    is pretty rudimentary - nothing exotic.

    I'm not sure what you mean by your comment about having
    problems writing standard C. Maybe I don't use enough
    exotic (too me) C++ language features to notice the problem.

--
John A. Grant  * I speak only for myself *  (remove 'z' to reply)
Radiation Geophysics, Geological Survey of Canada, Ottawa
If you followup, please do NOT e-mail me a copy: I will read it here