STD types vs C++ intrinsic types

[Jeremy Cowles]

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

[Victor Bazarov]

"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

[Gavin Deane]

"Jeremy Cowles" <jeremy.cowles[nosp@m]asifl.com> wrote in message news:<zi********************@twister.tampabay.rr.c om>...

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

[Bob Jacobs]

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d**************************@posting.google.c om...

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.

[Gavin Deane]

"Bob Jacobs" <ne****@robertjacobs.fsnet.co.uk> wrote in message news:<bh**********@newsg4.svr.pol.co.uk>...

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d**************************@posting.google.c om...

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

[Bob Jacobs]

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d**************************@posting.google.c om...

"Bob Jacobs" <ne****@robertjacobs.fsnet.co.uk> wrote in message news:<bh**********@newsg4.svr.pol.co.uk>...

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d**************************@posting.google.c om...

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