WhoowwWeeeeee!!!!

[RandomMan]

Thank you, thank you, thank you!

I created a project using an old Borland compiler, and the executable had grown to about the 1MB mark.  BCB got flakey, and for that reason and various other reasons I tore out all the VCL code, and replaced it with a custom Windows wrapper.  (Yes, I like pain! - Or I'm really stupid, but I learned a lot, and did some stuff nobody else has done [Flicker free docking framework])  Got the project working again, and then added some more to it.  BCB gave error just trying to open up the program in debugging mode.  BCB also gave random assertion failures every couple hours, regardless of whether I was debugging or just editing - always a nice way to say hello.

Anyway, after one and a half days of learning, cussing, and learning some more, I have succeeded in porting the project to Code::Blocks using VS2003 toolkit!  The exact same code went from 867 kb to 568 kb.  Build time went from 1:01 to 1:22 (minutes, not hours), and I have only seen CB go flakey once (and there is no way I could reproduce it).

I just had to stop and say "Thank you!", and also a great big "Yippee! - It works", before crashing into bed at way too late in the morning.

David

[rickg22]

Yikes! :shock: you better take some valium for when we release RC2 next week I wouldn't want to be near you jumping around and everything :lol:

Anyway, we all thank you for the compliment!

[RandomMan]

Yikes!  :shock: you better take some valium for when we release RC2 next week  I wouldn't want to be near you jumping around and everything  :lol:

I might be back in the land of the living by then.  I was brain-dead (but happy) when I wrote that, as I had inadvertently introduced a bug into my code while porting, and had been up debugging and learning CB for way too long.  My excitement at the time was more the fact that _my code_ was working in CB, than the fact that CB was working.  But there was a LOT of excitement about that, as well    (Anytime you succesfully port 800 + kb of executable to a new environment in two days, you have had a succesful two days.)

(<BEGIN RANT>Why oh why does VC insist upon a fourth (functor) parameter for std::accumulate???  RogueWave's STL allows you to use only three args and no functor when the thingy being pointed to is a POD, and it AUTOMATICALLY did what you would think it should!  It added the thingys up, and gave you the accumulation of them!  But no, not VC.  You must create a functor for EVERYTHING.  Grrrrr.....  Back to a hand loop, screw it!  I hate functors for simple things.  But then more debugging, because I had forgotten what part of the container I was iterating over - duh!<END RANT>)

Anyhow...  I'm curious to see what improvements you have made for RC2.  I had tried 1.0 beta 5, and rc1-1 seems to be a big improvement over it.  But don't take that as a bash against beta5, as my code emitted too many warnings and errors to easily get it running while learning CB at the same time.  I recall being frustrated with beta5 for other reasons as well, but cannot remember them.  I am very pleased with rc1-1, though, now that I know the quirks, and I'm curious to see how many of the things I would change have been changed in your new toy.  But don't expect the same response at that time - I'll be busy being productive.

Thanks again!

David

[takeshimiya]

I don't know if that is a bug of the STL that come with MSVC, but in any case, you can try a another implementation (better and most standard compliant) of the STL available for most compilers: STLport http://www.stlport.org/

Anyways, happy C::Bing, and yes RC2 will have new features, but most important, lot of bug fixes.

[RandomMan]

Arrrgh!  I have played with it for five hours, trying to get it to work.  First, wasted four hours trying to compile the iostream library - WHAT A PITA!!!!  And even after all that pain, I was still unsuccessful, as it refused to link in the appropriate symbols.  It may have been my path settings, but everything looked right!

Finally gave up on that, and just did the minimal install.  Recompiled my project, and got one of the longest error messages I have ever seen:

Code

C:\Program Files\Programming\STLport-4.6.2\stlport\stl\_tree.h(245) : error C2668: 'std::_Construct' : ambiguous call to overloaded function
        C:\Program Files\Programming\MS Visual Toolkit\include\xmemory(40): could be 'void std::_Construct<_Value,_STL::_Rb_tree<_Key,_Value,_KeyOfValue,_Compare,_Alloc>::value_type>(_T1 *,const _T2 &)' [found using argument-dependent lookup]
        with
        [
            _Value=_STL::map<int,const wString>::value_type,
            _Key=_STL::map<int,const wString>::key_type,
            _KeyOfValue=_STL::_Select1st<_STL::map<int,const wString>::value_type>,
            _Compare=_STL::map<int,const wString>::key_compare,
            _Alloc=_STL::allocator<_STL::pair<const int,const wString>>,
            _T1=_STL::map<int,const wString>::value_type,
            _T2=_STL::_Rb_tree<_STL::map<int,const wString>::key_type,_STL::map<int,const wString>::value_type,_STL::_Select1st<_STL::map<int,const wString>::value_type>,_STL::map<int,const wString>::key_compare,_STL::allocator<_STL::pair<const int,const wString>>>::value_type
        ]
        C:\Program Files\Programming\STLport-4.6.2\stlport\stl\_construct.h(93): or       'void _STL::_Construct<_Value,_STL::_Rb_tree<_Key,_Value,_KeyOfValue,_Compare,_Alloc>::value_type>(_T1 *,const _T2 &)'
        with
        [
            _Value=_STL::map<int,const wString>::value_type,
            _Key=_STL::map<int,const wString>::key_type,
            _KeyOfValue=_STL::_Select1st<_STL::map<int,const wString>::value_type>,
            _Compare=_STL::map<int,const wString>::key_compare,
            _Alloc=_STL::allocator<_STL::pair<const int,const wString>>,
            _T1=_STL::map<int,const wString>::value_type,
            _T2=_STL::_Rb_tree<_STL::map<int,const wString>::key_type,_STL::map<int,const wString>::value_type,_STL::_Select1st<_STL::map<int,const wString>::value_type>,_STL::map<int,const wString>::key_compare,_STL::allocator<_STL::pair<const int,const wString>>>::value_type
        ]

It goes on for another four pages after that clipping.  This comes about from one of three declarations in the file being compiled at the time:

      std::set<int> releasedNums;  //probably not it
or
      typedef std::map<int, const wString> ToolTipCaption; //where 'wString' is: 'typedef std::basic_string<TCHAR> wString;
or
      typedef std::map<int, WinPopupCallback*> PopupCallBack;
      PopupCallBack listC;

[edit] It is probably the last one.[/edit]  This worked in BCB, Dev-C++, and VS.  Just not here.  So I go about removing the stlport directory from the directory options...

Leaves a bad taste in my programming brain, even though I've heard it bragged about extensively.

David

[rickg22]

(Note that Takeshimiya's STL suggestion was a personal one, the C::B team doesn't support  it.)

[RandomMan]

Have you experienced problems with it, or is it just that you don't want to be in the position of supporting it?  (I wouldn't blame you if the second was the case.)

[takeshimiya]

I usually use the STL that come with the compiler, but I remember I used STLport when I was using MSVC6, because the implementation of it was really bad.
I really don't know if the STL from MSVC7 have matured enough, and I wouldn't recommend STLport for GCC as I don't remember having problems with the one from GCC.
Actually, when I use Digital Mars compiler, I have no problems using STLport.