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?

    TIA,
    Jeremy
     
    Jeremy Cowles, Aug 18, 2003
    #1
    1. Advertising

  2. "Jeremy Cowles" <jeremy.cowles[nosp@m]asifl.com> wrote...
    > 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?)


    His name is spelled beginning with a capital 's': Stroustrup.

    > 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.


    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).

    > 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?


    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.

    > 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?


    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
     
    Victor Bazarov, Aug 18, 2003
    #2
    1. Advertising

  3. Jeremy Cowles

    Gavin Deane Guest

    "Jeremy Cowles" <jeremy.cowles[nosp@m]asifl.com> wrote in message news:<zi50b.52431$>...
    > 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"


    Dinosaurs became extinct. That attitude will do the same in due
    course.

    > 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?


    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.

    GJD
     
    Gavin Deane, Aug 18, 2003
    #3
  4. Jeremy Cowles

    Bob Jacobs Guest

    "Gavin Deane" <> wrote in message
    news:...
    >
    > 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.


    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
    #4
  5. Jeremy Cowles

    Gavin Deane Guest

    "Bob Jacobs" <> wrote in message news:<bhr4du$osk$>...
    > "Gavin Deane" <> wrote in message
    > news:...
    > >
    > > 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.

    >
    > 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.


    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."

    GJD
     
    Gavin Deane, Aug 19, 2003
    #5
  6. Jeremy Cowles

    Bob Jacobs Guest

    "Gavin Deane" <> wrote in message
    news:...
    > "Bob Jacobs" <> wrote in message

    news:<bhr4du$osk$>...
    > > "Gavin Deane" <> wrote in message
    > > news:...
    > > >
    > > > 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.

    > >
    > > 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.

    >
    > 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.


    Of course, but it's not an either-or. You should have clear understandable
    code either way.

    > The I would take that code and
    > optimise it as necessary. I think it is important to get the code
    > working first.


    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.

    > 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.


    Design /and/ have it working correctly, then optimise.

    > 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."


    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
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?R2xlbm4=?=

    trouble utilizing intrinsic objects in custom class

    =?Utf-8?B?R2xlbm4=?=, May 19, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    492
    =?Utf-8?B?R2xlbm4=?=
    May 19, 2004
  2. Alek Davis
    Replies:
    15
    Views:
    7,235
    Scott M.
    Nov 12, 2009
  3. Alan Ho

    Intrinsic objects of ASP.Net

    Alan Ho, May 9, 2005, in forum: ASP .Net
    Replies:
    5
    Views:
    2,444
    Juan T. Llibre
    May 9, 2005
  4. jason
    Replies:
    2
    Views:
    1,814
    jason
    Jan 10, 2006
  5. JKop

    Inherit from Intrinsic

    JKop, Jul 14, 2004, in forum: C++
    Replies:
    1
    Views:
    336
Loading...

Share This Page