Announcement

Collapse
No announcement yet.

Approved: C++0x Will Be An International Standard

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by AnonymousCoward View Post
    Code:
    #include <stdint.h>
    #include <stdbool.h>
    enum { NUM_BITS = 42 };
    struct bitset {
      uint32_t bits[NUM_BITS/32];
    };
    bool get_bit(struct bitset *bits, unsigned n) {
      return bits->bits[n/32] & (1 << (n%32));
    }
    All this talk, and nobody noticed the bug? You're only getting 32 bits yet asking for 42.

    Comment


    • #42
      Good point. It should be uint32_t bits[NUM_BITS/32 + (NUM_BITS%32 != 0)];

      Comment


      • #43
        AnonymousCoward,

        Let me chime in.
        You really need to understand that even if STL is just as fast as hand written C implementation (and in my experience, implementation performance and usage cases tend to vary, a-lot, across different platforms and compilers), the lack of control over what the compiler is doing one one hand, and the inability to debug STL application when something really-really-really-nasty happens make it a deal break in many C++ projects.

        If your code heavily relays on vectors, and you experience a crash in release mode deep within the vector implementation, you're more or less done for. An STL code is extremely hard to understand / debug by reading the code due to the excessive use of... well... templates.
        E.g. If you get a trace of you code, the crashed in a line deep within STL, that says A = B + C(X), and A, B, C are templates... you are screwed.

        - Gilboa
        DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX1080, F27/x86_64, Dell UP3216Q 4K.
        SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F27/x86_64, Dell U2711..
        BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F27/x86-64.
        LAP: ASUS Strix GL502V, i7-6700HQ, 32GB, 1TB+256GB, 1070M, F27/x86_64.

        Comment


        • #44
          I don't buy that argument. Common STL implementation tend to be very well optimized, debugged and tested, simply because they're used to much all around the world, so you're extremely unlikely to hit a bug in them. Of course, you may be using it the wrong way (i. e. accessing invalid iterators etc.), but good STL implementations offer a debug mode that will check for such errors. And if you actually run into Heisenbugs that disappear when you enable these things, well, that's life. Programming is hard, get used to it.

          Besides, what would be the alternative? Using non-template containers such as those from glib? There's no way in hell I'll give up type safety for my containers. Rolling your own template containers? There's no doubt it'll be slow and riddled with bugs compared to the STL. It may make sense to use other template containers like those from Q which offer different tradeoffs than the STL ones, but if you think that templates are generally hard to debug (which, by the way, I also don't buy, as long as no template metaprogramming is involved), they won't be any easier to debug than those from the STL.

          Comment


          • #45
            Originally posted by AnonymousCoward View Post
            I don't buy that argument. Common STL implementation tend to be very well optimized, debugged and tested, simply because they're used to much all around the world, so you're extremely unlikely to hit a bug in them. Of course, you may be using it the wrong way (i. e. accessing invalid iterators etc.), but good STL implementations offer a debug mode that will check for such errors. And if you actually run into Heisenbugs that disappear when you enable these things, well, that's life. Programming is hard, get used to it.
            I didn't imply that STL is buggy, I *did* imply the user generated bugs (E.g. memory overruns, deleted object access, etc) are -very- hard to debug, once the crash happens inside STL due to the excessive use of templates.

            Besides, what would be the alternative? Using non-template containers such as those from glib? There's no way in hell I'll give up type safety for my containers. Rolling your own template containers? There's no doubt it'll be slow and riddled with bugs compared to the STL. It may make sense to use other template containers like those from Q which offer different tradeoffs than the STL ones, but if you think that templates are generally hard to debug (which, by the way, I also don't buy, as long as no template metaprogramming is involved), they won't be any easier to debug than those from the STL.
            I'm a strong believer in developing your own containers, but that's personal preference (Plus, I need code that's portable across different environments and/or execution modes that not necessarily support STL or C++).
            In general, I'm not saying the STL is bad or should be avoided, but I would suggest anyone that plans on using STL to well aware of the issues and possible pit-falls.

            - Gilboa
            DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX1080, F27/x86_64, Dell UP3216Q 4K.
            SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F27/x86_64, Dell U2711..
            BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F27/x86-64.
            LAP: ASUS Strix GL502V, i7-6700HQ, 32GB, 1TB+256GB, 1070M, F27/x86_64.

            Comment


            • #46
              Originally posted by gilboa View Post
              I didn't imply that STL is buggy, I *did* imply the user generated bugs (E.g. memory overruns, deleted object access, etc) are -very- hard to debug, once the crash happens inside STL due to the excessive use of templates.
              The STL doesn't use templates "excessively", it uses them in just the way they were meant to be used. And really, what's so hard about template code? The hard things to understand about containers are the underlying data structures like Hash Tables, Balanced Trees, Heaps etc., and they're just as hard as in non-generic code.
              Also, I think that the debugging modes modern STL implementations generally offer are actually much more helpful in detecting bugs than having you own containers that don't have such facilities, at least not with the degree of maturity common STL implementations provide.

              Originally posted by gilboa View Post
              I'm a strong believer in developing your own containers, but that's personal preference
              Sorry for being blunt, but it's not just personal preference, it's also a pretty dumb idea in the vast majority of cases. There's no reason at all to reinvent the wheel, when you have a fast, flexible, well-known and debugged wheel at your disposal for free. Or actually multiple such wheels. After all, the STL isn't the only generic container library around.

              Comment


              • #47
                Originally posted by AnonymousCoward View Post
                The STL doesn't use templates "excessively", it uses them in just the way they were meant to be used. And really, what's so hard about template code? The hard things to understand about containers are the underlying data structures like Hash Tables, Balanced Trees, Heaps etc., and they're just as hard as in non-generic code.
                About the containers: sure. But about templates: have you ever tried using boost::spirit and seen the kind of errors gcc spits out if you make a little mistake in the parser code? Have you noticed the enormous compile-times and memory usage (1GB+) during compilation?

                Sorry for being blunt, but it's not just personal preference, it's also a pretty dumb idea in the vast majority of cases. There's no reason at all to reinvent the wheel, when you have a fast, flexible, well-known and debugged wheel at your disposal for free. Or actually multiple such wheels. After all, the STL isn't the only generic container library around.
                Agreed. If you're writing the code from-scratch containers are extra work and an extra opportunity for bugs. If someone else is trying to read your code it's extra wheels he/she has to get his/her head around.

                Comment


                • #48
                  Originally posted by AnonymousCoward View Post
                  Sorry for being blunt, but it's not just personal preference, it's also a pretty dumb idea in the vast majority of cases. There's no reason at all to reinvent the wheel, when you have a fast, flexible, well-known and debugged wheel at your disposal for free. Or actually multiple such wheels. After all, the STL isn't the only generic container library around.
                  You might want to check who you were talking to; he's got a fair bit of experience to back up his statements. His ending statement was pretty much: know your tool. Know what it does well, what it doesn't do well, and then decide if you're going to use it or not. It's a dumb idea to use STL blindly - this is absolutely nothing to do with STL, it just means you haven't looked at the problem at hand properly.

                  Comment


                  • #49
                    Originally posted by Cyborg16 View Post
                    About the containers: sure. But about templates: have you ever tried using boost::spirit and seen the kind of errors gcc spits out if you make a little mistake in the parser code? Have you noticed the enormous compile-times and memory usage (1GB+) during compilation?
                    This is why I said "as long as no template metaprogramming is involved".

                    Originally posted by mirv View Post
                    You might want to check who you were talking to; he's got a fair bit of experience to back up his statements. His ending statement was pretty much: know your tool. Know what it does well, what it doesn't do well, and then decide if you're going to use it or not. It's a dumb idea to use STL blindly - this is absolutely nothing to do with STL, it just means you haven't looked at the problem at hand properly.
                    Well, duh. Doesn't that apply to any tool? Of course, if you have a good reason to not use the STL, fine, go ahead and use something else. But my experience is that more often than not, the reasons that people cite are based on ignorance and superstition.

                    Comment


                    • #50
                      Originally posted by AnonymousCoward View Post
                      Well, duh. Doesn't that apply to any tool? Of course, if you have a good reason to not use the STL, fine, go ahead and use something else. But my experience is that more often than not, the reasons that people cite are based on ignorance and superstition.
                      Sadly, I've just as often seen people use STL where something else would be much more suitable - for much the same reason.

                      Comment

                      Working...
                      X