CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 19 123411 ... LastLast
Results 1 to 15 of 280
  1. #1
    Join Date
    Jan 2002
    Location
    Scaro, UK
    Posts
    5,940

    To STL or not to STL, that is the question...

    I hate the standard template library.

    I hate the fact you can't use DEBUG_NEW with it to track down memory leaks.

    I hate all the std::blah blah stuff when there's classes in MFC which do virtually the same job but much, much nicer.

    I don't even like CArray.

    However CPtrArray, CObArray and CStringArray are very, very, very useful.

    You can't inherit from any of the STL classes because they don't have virtual destructors so you can't for instance do nice things that you can in MFC like :

    Code:
    class CServerNames : public CStringArray
    {
    public:
        CServerNames();
        virtual ~CServerNames();
    } ;
    where this class would load in all server names from wherever.

    In one line.

    Wherever you wanted to put it in the code.

    In an MFC environment I don't see any reason to use it. Ever !

    I know my comments are very forward, but I'm invoking discussion.

    This should be very, very interesting.

    Darwen.

  2. #2
    Join Date
    Jan 2002
    Location
    Scaro, UK
    Posts
    5,940
    Oh, or of course you couldn't derive from std::vector and add them to a linked list because there's no virtual destructors.

    The more I think, the more I come up with about how much I hate STL.

    There you go !

    OK guys, flames away !

    Darwen.

  3. #3
    Join Date
    Apr 1999
    Posts
    27,449

    Re: To STL or not to STL, that is the question...

    [QUOTE]Originally posted by darwen
    I hate the fact you can't use DEBUG_NEW with it to track down memory leaks.
    There's a whole lot of code that is not STL where DEBUG_NEW cannot be used. So that's strike one.
    I hate all the std::blah blah stuff when there's classes in MFC which do virtually the same job but much, much nicer.
    OK. Go sort a CList. Also, std:: is called a namespace. Again, nothing to do with STL, but just basic C++. Strike 2.
    I don't even like CArray.
    Why? It's MFC, isn't it?
    However CPtrArray, CObArray and CStringArray are very, very, very useful.
    If you want all that overhead of CObject added to your classes, go right ahead. Most C++ programmers do not want their classes hamstrung being derived from CObject.
    You can't inherit from any of the STL classes because they don't have virtual destructors so you can't for instance do nice things that you can in MFC like :

    Code:
    class CServerNames : public CStringArray
    {
    public:
        CServerNames();
        virtual ~CServerNames();
    } ;
    where this class would load in all server names from wherever.

    In one line.

    Wherever you wanted to put it in the code.
    Let's see the code that loads everything in "one line". Just posting a class without any code is not very convincing.
    Code:
    class CServerNames
    {
       public:
           CServerNames() { LoadNames(); }
           std::vector<std::string> AllMyNames;
           void LoadNames()
           {
                // Code to load server names into AllMyNames
           }
    };
    
    void foo()
    {
        CServerNames S;  // I've just loaded all the names
    }
    I guess that's strike 3, but I'll keep going...
    In an MFC environment I don't see any reason to use it. Ever !
    Go sort a CPtrArray, or CStringArray, or CList. You can't unless you write your own code. I can do it in one line of STL code using std::sort. Oh, you must have forgot, STL isn't just about containers, there are a whole lot of algorithm functions (such as std::sort) that work on MFC Array classes. Maybe when you need to sort your CStringArray or call a function that acts on each element of your CPtrArray, you will see for_each() and not know what it does.
    I know my comments are very forward, but I'm invoking discussion.
    Looks like your trolling.

    Regards,

    Paul McKenzie

  4. #4
    Join Date
    Sep 2003
    Location
    STL LAND
    Posts
    15
    I have been waiting in the shadows for my moment to come!
    AT LAST IT IS HERE

    who dares to call the usefullness of the STL into question?
    Could it be that your hate is rooted in your lack of understanding?

    Overcome your your own awkward handling of this wonderfull tool and bask in
    the glory of the STL
    DEFENDER OF ALL THINGS STL!!!

  5. #5
    Join Date
    Jan 2002
    Location
    Scaro, UK
    Posts
    5,940
    Ha ha ! Just the kind of thing that I wanted. This should be fun.

    OK - how useful is STL ?

    (1) No memory leak detection because you can't use DEBUG_NEW.
    (2) No inheritance (even though it's a basic premise of object orientation....).

    So it even breaks the rules of good software design !

    Nasty, nasty.

    What's so wonderful about it then ? Let's have some points eh ?

    Darwen.

  6. #6
    Join Date
    Jan 2002
    Location
    Scaro, UK
    Posts
    5,940
    Oh and as to sorting stuff - you still have to write your own code to sort lists which means it isn't any better than MFC.

    At any rate you can still use the function ::sort if you wish.

    Overhead of CObject from what I've seen is very, very small. I've never had any performance hits from it.

    I've also in my 10 or so years of programming windows have never come across anything except for the STL that won't work with DEBUG_NEW. Please give an example.

    And in your example of using a list the trouble with that is you either have to expose the member so you have

    Code:
    CServerNames asNames;
    asNames.GetList(). blah

    which is ugly in my opinion, or you have to override all the members of the list as members of your class.

    With inheritance you don't need to.

    Yes, MFC isn't perfect but it's certainly better than STL.

    I know std:: is a namespace. A bit nit-picky arguing about it if you ask me.

    Never mind that the stuff like

    Code:
    std::vector<std::string> AllMyNames;
    looks really ugly and horrid in my opinion.

    Darwen.

  7. #7
    Join Date
    Apr 2003
    Location
    Athens, Greece
    Posts
    1,094
    Well, namespaces are meant to make things clearer.
    You may
    typedef std::vector<std::string>
    to whatever you like or write a
    using std declaration.
    I also read somewhere that the STL classes are designed so that they perform quite well (which may be very important) whereas the MFC classes with all that virtual staff I doubt they are that good. But I think there have to be made specific tests on the performance of the MFC - STL and if smne has done smthng like that I would be very glad to hear some comparative results.
    Moreover with STL you may write whole (non UI) classes that are portable. You never know what compiler you may need to use.
    And what if MS drops MFC in the future?
    Extreme situations require extreme measures

  8. #8
    Join Date
    Jan 2002
    Location
    Scaro, UK
    Posts
    5,940
    I think the possibility of MFC being dropped is very low at the moment.

    At any rate, thanks for your comments.

    I knew this issue wasn't going to be resolved, but as far as I know no discussion such as this has ever taken place on code guru and I thought it should.

    Yes, portability of code is one reason why you would use STL but my point is that if you're not going to port code to other platforms (e.g. UNIX) is there any reason to use it in a windows app ?

    I actually know both the STL and MFC very, very well having used both for a large number of years and prefer MFC.

    Inheritance, in my opinion, is one of the greatest advantages of C++ and to completely disallow it in such a widespread toolkit as STL is terrible.

    I'm sure a lot more is going to get added to this thread and I will respond, but only to new arguments. I think we've covered all the 'surface' issues already.

    Many thanks for the interest. It has been a great deal of fun arguing my point with you....

    Darwen.


  9. #9
    Join Date
    Jan 2002
    Location
    Scaro, UK
    Posts
    5,940
    Oh and on second reading of your mail typedef-ing a class to another name is very, very bad in C++ design terms.

    Just think if you did that on a commercial (1,000,000 lines of code+) level ? OOoooohhh, I dread to think about the bugs !

    Why don't they allow inheritance panayotisk ? Seems really daft to me but there you go.

    In fact in my opinion MFC has it wrong too. Classes such as CStringArray etc should have almost all their members as virtuals so you can override them.

    Mind you, nobody has mentioned the biggest problem with CStringArray - efficiency ! It returns CStrings which means it does a lot of creation/destruction every time you get an item out of it.

    In our stuff at my place of work we have a COptimisedStringArray which is derived from CPtrArray and just stores and returns pointers to strings.

    And just about all its members are virtual !

    No, MFC is not perfect but I have still to be pursuaded that stl is worth using although some of your comments have made me reconsider my position.

    Which after all is the point of discussion isn't it ?

    I hope some of my comments have made other people reconsider their position too. Then we can go forwards as one, united body of excellent coders (lol !). <Soap box mode off>

    Darwen.

  10. #10
    Join Date
    Sep 2002
    Location
    Maryland - Fear The Turtle!
    Posts
    7,537
    (1) No memory leak detection because you can't use DEBUG_NEW.
    hmm what are you saying about DEBUG_NEW and stl? Are you saying if I take a std:list and 'new' some of my defined object types into the list, and maybe forget to delete some..I wouldn't get output like this letting me know??? without the use of afx.h...


    Detected memory leaks!
    Dumping objects ->
    {63} normal block at 0x002F46B8, 12 bytes long.
    Data: < C/ F/ `F/ > 98 43 2F 00 18 46 2F 00 60 46 2F 00
    c:\dev\debugnew\debugnew.cpp(33) : {62} normal block at 0x002F4660, 24 bytes long.
    Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
    {61} normal block at 0x002F4618, 12 bytes long.
    Data: < F/ xE/ E/ > B8 46 2F 00 78 45 2F 00 C0 45 2F 00
    c:\dev\debugnew\debugnew.cpp(33) : {60} normal block at 0x002F45C0, 24 bytes long.
    Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
    {59} normal block at 0x002F4578, 12 bytes long.
    Data: < F/ D/ E/ > 18 46 2F 00 D8 44 2F 00 20 45 2F 00
    c:\dev\debugnew\debugnew.cpp(33) : {58} normal block at 0x002F4520, 24 bytes long.
    Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
    {57} normal block at 0x002F44D8, 12 bytes long.
    Data: <xE/ 8D/ D/ > 78 45 2F 00 38 44 2F 00 80 44 2F 00
    c:\dev\debugnew\debugnew.cpp(33) : {56} normal block at 0x002F4480, 24 bytes long.
    Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
    {55} normal block at 0x002F4438, 12 bytes long.
    Data: < D/ C/ C/ > D8 44 2F 00 98 43 2F 00 E0 43 2F 00
    c:\dev\debugnew\debugnew.cpp(33) : {54} normal block at 0x002F43E0, 24 bytes long.
    Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
    {53} normal block at 0x002F4398, 12 bytes long.
    Data: <8D/ F/ > 38 44 2F 00 B8 46 2F 00 CD CD CD CD
    Object dump complete.

  11. #11
    Join Date
    Apr 2003
    Location
    Athens, Greece
    Posts
    1,094
    This is a very interesting discussion.

    I have to tell you that I am programming VC++ professionaly for just about 8 months and I am not so experienced as you guys. Moreover I've never used STL...

    Yes, portability of code is one reason why you would use STL but my point is that if you're not going to port code to other platforms (e.g. UNIX) is there any reason to use it in a windows app ?
    Well, if you also program for Windows using Borland C++ I think you cannot use MFC there... (I haven't touched Borland C++ since version 5.0, so I am not sure)

    Anyway, I insist we have to find out if there is considerable efficiency difference between MFC - STL.
    But is it true that inheritence in STL is not allowed? I thought this library was meant to be extensible. This is a very serious drawback if it is real.
    Extreme situations require extreme measures

  12. #12
    Join Date
    Mar 2003
    Location
    India {Mumbai};
    Posts
    3,871
    And what about the copilation problems with STL. Illigally coded stl variable usage will raise lot of errors! I also do not prefer use of STL. Its performance does not seem to anyway better than equivalent than MFC.
    My latest article: Explicating the new C++ standard (C++0x)

    Do rate the posts you find useful.

  13. #13
    Join Date
    Nov 2002
    Location
    Los Angeles, California
    Posts
    3,863
    I am a bit confused as to what the issue is with DEBUG_NEW.
    I think Mick already pointed out my confusion.

    The STL containers do not have virtual destructors because they
    are designed for efficiency. Including a virtual destructor means
    that there is now a vtable, vptr and inlining is effectively eliminated.

    I don't see why it is such a big deal to write a wrapper class for
    an STL container if you want to add functionality.

    Darwin you said you had written lots of extensions of the MFC
    classes to gain the functionality offered by the STL. There is the point. You do not need to write anything if you just use the STL
    directly.

    To finish I will quote

    Scott Meyers: On STL containers
    Their popularity is easy to understand. They're simply better than
    their competition, regardless of whether that competition comes
    from containers in other libraries or is a container type you'd
    write yourself. STL containers aren't just good. They're really good
    I guess I will have to agree with the newest member of the Justice League, STL MAN, on this one.
    Last edited by souldog; August 18th, 2004 at 04:05 AM.
    Wakeup in the morning and kick the day in the teeth!! Or something like that.

    "i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."

  14. #14
    Join Date
    May 2000
    Location
    KY, USA
    Posts
    18,652
    I do not want to get involved too deep here...since this is more a religious thing to discuss just like 'Which operating system is better - Windows or Linux?'.

    However, there is one point which basically plays a big role in considering whether one uses the MFC or the STL...and that is platform dependency. If I have to write software that is supposed to run on different operating systems, then the MFC does not help at all. Since STL is part of the C++ standard, it is portable without a hassle.

  15. #15
    Join Date
    May 2000
    Location
    KY, USA
    Posts
    18,652
    Originally posted by Ajay Vijay
    And what about the copilation problems with STL.
    What compilation errors?

    Originally posted by Ajay Vijay
    Illigally coded stl variable usage will raise lot of errors!
    Okay...I am assuming that you are referring to the illegal use of the STL...in this case...the same applies to the MFC or anything else. If you use something a way it was not intended to use...the result will be the same...compilation or run-time errors.

    Originally posted by Ajay Vijay
    I also do not prefer use of STL. Its performance does not seem to anyway better than equivalent than MFC.
    Well...although this depends on the specific situation...even Microsoft had to admit that the STL classes are performing better in most of the cases...

Page 1 of 19 123411 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured