STD types vs C++ intrinsic types

Discussion in 'C++' started by Jeremy Cowles, Aug 18, 2003.

  1. I have been reading a book that focuses on understanding the intrinsic types
    of C++ in depth. The author's mentality is this: "Understand the intrinsic
    types, then learn the std types as needed later", but I have been reading
    the stroustrup (spelling?) book and he says that it is much better to learn
    the standard library first as a beginner, and then worry about the intrinsic
    types afterwards.

    So there is no doubt that you need to have a full comprehension of both, but
    as a general rule, which should be relied upon more? For example, in many
    cases you can use an array to hold a data set, but you could also use a
    standard container, say the set is of a static size now, so an array would
    seem like the best choice (speed/size), but for extendibility and
    maintenance, wouldn't an object be a better choice?

    Jeremy Cowles, Aug 18, 2003
    1. Advertisements

  2. His name is spelled beginning with a capital 's': Stroustrup.
    There are intrinsic types and there are intrinsic types. Understanding
    of 'int', 'char', 'short', 'long', their unsigned equivalents, 'bool',
    'float' and 'double', is important very soon. Understanding pointers and
    references is also important, although somewhat more advanced. You may
    put arrays aside for a little bit, until you're comfortable with pointers
    and some simple standard containers (vectors and strings).
    It is not the right question to ask. Should you rely more on your legs
    or on your arms? When learning to drive, should you learn to brake first
    or to steer? Like in many other areas, both are equally important.
    The answer is extremely simple and extremely complex: it depends. What
    kind of data is the set of? Does its size change dynamically? Do you
    perform more of random look-ups or just iterate through it? Et cetera.

    Victor Bazarov, Aug 18, 2003
    1. Advertisements

  3. Jeremy Cowles

    Gavin Deane Guest

    Dinosaurs became extinct. That attitude will do the same in due
    Yes. Maintenance and clarity are always important. If your code is any
    good, at some point in the future someone will want its functionality
    extended. And it may well be some other programmer who has to do that.

    Size and speed are never an issue unless and until such time as you
    have proved that you cannot meet your (or your customer's)
    requirements without making the code faster / smaller.

    Gavin Deane, Aug 18, 2003
  4. Jeremy Cowles

    Bob Jacobs Guest

    Not necessarily. Sometimes it will be clear from the outset that for a
    particular application speed is more important than size, or size is more
    important than speed, and your design will reflect this.
    Bob Jacobs, Aug 18, 2003
  5. Jeremy Cowles

    Gavin Deane Guest

    Fair point. But I think I can wriggle out of it :)

    In such cases I would still initially concentrate on producing clear,
    understandable and correct code. The I would take that code and
    optimise it as necessary. I think it is important to get the code
    working first. If you optimise something before it works correctly,
    you run the risk of needing to make a change later that slows / bloats
    the code unacceptably. Your earlier effort is effectively wasted.

    You are quite right that there are times when design decisions will be
    influenced by speed / size requirements. But those decisions will
    probably be more fundamental that the OP's example of "should I use an
    array or container."

    Gavin Deane, Aug 19, 2003
  6. Jeremy Cowles

    Bob Jacobs Guest

    Of course, but it's not an either-or. You should have clear understandable
    code either way.
    We're talking about two different things. You're talking about optimisation
    and I'm talking design. I just felt it was worth correcting your statement
    that size and speed are never an issue until you've shown that a requirement
    can't be met. Size and/or speed are often an issue right from day one, which
    is why I said that your design will, if required, take this into account. It
    would be foolhardy to design without considering speed if speed happens to
    be important, and then to go back and rework after testing to put right what
    you should have done at the design stage anyway. And it would cripple most
    projects to do so. But this, as I said, is design not optimisation.
    Design /and/ have it working correctly, then optimise.
    Quite possibly. I suspect we're in agreement, it was the use of never in
    your original statement that I thought needed correcting ;-)
    Bob Jacobs, Aug 19, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.