Announcement

Collapse
No announcement yet.

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

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

  • #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


            • #51
              Originally posted by AnonymousCoward View Post
              No you didn't. You made some argument about keeping stuff in registers as opposed to loading it from RAM etc.. But this can be trivially optimized away by the compiler. This is exactly what compiler optimizations are for. The fact that you don't believe it's possible reveals more about your (lack of) knowledge about modern compilers than about C++ or std::bitset.
              Of course, you may still prove me wrong. Just provide some code that proves your point, that is, code that will run faster using manual bit-fiddling instead of a std::bitset. The fact that you still didn't do this suggests that you can't though.


              Oh well, I must have misunderstood that bit.


              I care about how easy it is to read for other programmers. I don't care about non-programmers, as they will by definition not be able to understand it anyway.


              Um, actually it's not an example at all, because C++11 does have binary literals. As I said earlier, user-defined literals are there for just that.
              Oh my, you're not understanding the concept of a standard.

              Let me explain to you Mr AC that a standard STANDARDIZE the way to do things.
              Being able to specif things in a standard way allows automatic compatibility from everything that implements the standard with anything else that implements it.

              Standardizing the way of making user-defined literals is not the same as having a standard way of having a particular kind of literal.
              Try to think about this: 'Everything you didn't specify will fall/fail/won't work at some point'.

              It's already being done with other programming languages. (Java 7 comes to mind)
              It doesn't require a large addition of the standard and can make life easier for people making software.

              Comment


              • #52
                Originally posted by plonoma View Post
                Let me explain to you Mr AC that a standard STANDARDIZE the way to do things.
                Being able to specif things in a standard way allows automatic compatibility from everything that implements the standard with anything else that implements it.

                Standardizing the way of making user-defined literals is not the same as having a standard way of having a particular kind of literal.
                Try to think about this: 'Everything you didn't specify will fall/fail/won't work at some point'.
                Slow down a bit. User-defined literals are part of the standard, so they should work wherever the standard is supported. If you say "but X is bound to introduce compiler C which has a small bug there preventing that custom-literal from working as expected" then you're talking about a non-compliant compiler and you should ask X to fix it rather than complaining about the standard.

                I expect the real reason binary literals weren't added, if they were even considered, was because "it's just another feature", and Mr Stroustrap's been trying to keep the language as managable as possible. That Java now has it is no argument; you could never design one language which has every feature popular in any other language. Admitted it's not a difficult feature to add, but it's still another feature without a major user-base.

                Personally I think binary is a lot more useful than octal, but that's beside the point.

                Comment


                • #53
                  Originally posted by plonoma View Post
                  Oh my, you're not understanding the concept of a standard.
                  Everything I needed to know about standards I learned from xkcd :


                  Comment


                  • #54
                    Originally posted by Cyborg16 View Post
                    Slow down a bit. User-defined literals are part of the standard, so they should work wherever the standard is supported. If you say "but X is bound to introduce compiler C which has a small bug there preventing that custom-literal from working as expected" then you're talking about a non-compliant compiler and you should ask X to fix it rather than complaining about the standard.

                    I expect the real reason binary literals weren't added, if they were even considered, was because "it's just another feature", and Mr Stroustrap's been trying to keep the language as managable as possible. That Java now has it is no argument; you could never design one language which has every feature popular in any other language. Admitted it's not a difficult feature to add, but it's still another feature without a major user-base.

                    Personally I think binary is a lot more useful than octal, but that's beside the point.
                    NOPE i'm not talking about that. I'm not talking about bugs but different softwares doing things on a different way because the standard did NOT specified that.

                    The thing is that two people, organizations would have made the 'same' custom-literal which is written differently.
                    And would not be universal and stuff written from one wouldn't work on stuff written from another one.
                    The software would be perfectly fine but adapting all software for all things from all parties would be an impossible task.

                    Your user-defined literals don't tell you what the literals stand for.
                    That's not a bug in software. That's unspecified because we are talking about custom literals.
                    Universally usable binary literals would be very welcome in many places.

                    Comment


                    • #55
                      Seriously?

                      1. Most likely boost will get an implementation and it will become pretty standard.
                      2. If not, at worst it'll be a search-and-replace job.

                      Comment

                      Working...
                      X