Bjarne Stroustrup says

[Teddy]

Hello all

Bjarne Stroustrup says "The most important thing to do when learning
C++ is to focus on concepts and not get lost in language-technical
details" and "Focus on programming techniques, not on language
features" in his book <The C++ Programming Language>.

I don't follow these.
What does Bjarne Stroustrup actually mean?

[Jason Heyes]

"Teddy" <du********@hot mail.com> wrote in message
news:11******** **************@ g44g2000cwa.goo glegroups.com.. .

Hello all

Bjarne Stroustrup says "The most important thing to do when learning
C++ is to focus on concepts and not get lost in language-technical
details" and "Focus on programming techniques, not on language
features" in his book <The C++ Programming Language>.

I don't follow these.
What does Bjarne Stroustrup actually mean?

When you learn C++, rely on simple concepts rather than a technical
understanding of the language. For example, think of std::vector as a
sequence and not a class template.

Focus on the useful aspects of C++ and not the features. For example, think
of >> as a read operation instead of an overloaded operator.

Hope this helps.

[Victor Bazarov]

Teddy wrote:

Bjarne Stroustrup says "The most important thing to do when learning
C++ is to focus on concepts and not get lost in language-technical
details" and "Focus on programming techniques, not on language
features" in his book <The C++ Programming Language>.

I don't follow these.
What does Bjarne Stroustrup actually mean?

He means, don't lose the sight of the forest looking at the trees.
Don't spend all your time learning the intricacies of the language
instead of seeing the big picture and actually doing your work.
You don't have to know all the minute details of the implementation
to get the design right and achieve your goals.

V

[BigBrian]

This might be true when learning, but its definately NOT true in
general. I've seen alot of code written by people who didn't
understand the intricacies of the language and it tends to be brittle
and hard to maintain.

[Aerodyne]

BigBrian wrote:

This might be true when learning, but its definately NOT true in
general. I've seen alot of code written by people who didn't
understand the intricacies of the language and it tends to be brittle
and hard to maintain.

Yeah ... I second that.

When you start off don't worry about all the complex issues with the
C++ language, so you don't need to know the in's-&-outs of the C++ core
langauge yet... but down the line you'll need to know it, plus the std
lib ... etc.
You'll know how to optimize your code & get the best out of it once
you've become more familiar w/ it.
Other folks suggest not thinking about C when you learn C++, I think
that's a good tip as well.

[Peter Julian]

"BigBrian" <wo**@brianmiel ke.com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

This might be true when learning, but its definately NOT true in
general. I've seen alot of code written by people who didn't
understand the intricacies of the language and it tends to be brittle
and hard to maintain.

And the principle reason that the "intricacie s" or features are misused or
mis-implemented is due to an erroneous overview of the concept at hand. This
occurs precisely because the coder has focused on the details instead of the
abstract concept.

Why use feature X, for example, if you don't know *when* to use X and what
its goals are. Thats much more important than *how* to code X correctly in
your design.

To emphasize the forest analogy: Concentrating on the tree only generates a
nice tree. The problem is that the forest is then populated by that tree
only. The first infection then jeopardizes the entire forest.

[Default User]

BigBrian wrote:

This might be true when learning, but its definately NOT true in
general.

Please quote a relevant portion of the previous message when replying.
To do so from the Google interface, don't use the Reply at the bottom
of the message. Instead, click "show options" and use the Reply shown
in the expanded headers.

Brian

[BigBrian]

> > This might be true when learning, but its definately NOT true in

general. I've seen alot of code written by people who didn't
understand the intricacies of the language and it tends to be brittle
and hard to maintain.

And the principle reason that the "intricacie s" or features are misused or
mis-implemented is due to an erroneous overview of the concept at hand. This
occurs precisely because the coder has focused on the details instead of the
abstract concept.

The intricacies of the language were misused because the coder was too
focused on the details of the language??? This makes no sense
whatsoever! Most software engineering practices advocate separating
out designing and coding. I suggest until you're good enough to
combined the two, keep them separate.
Why use feature X, for example, if you don't know *when* to use X and what
its goals are.
I never suggested using features of the language that you don't
understand. But my initial point was, unless you are detailed
oriented, and patient enough , you'll never understand the intricacies.

Thats much more important than *how* to code X correctly in
your design.
But, if you don't understand the intricacies of the language, how do
you know you've coded X correctly? If you don't know that it's coded
correctly, what good is it? I may as well be thrown in the trash.
To emphasize the forest analogy: Concentrating on the tree only generates a
nice tree. The problem is that the forest is then populated by that tree
only. The first infection then jeopardizes the entire forest.

Yes, this analogy may sound good, but in reality it has no relavence to
software. Software is not a forest. A beautiful forest can be made up
of trees which have flaws ( grouping trees together can hide the
individual flaws of each tree. ) But if a software system is built
upon components that are flawed by a coder not understanding the
language, the flaws don't cancel themselves out, but interact to create
more flaws and you end up with a very ugly system.

-Brian

[Victor Bazarov]

BigBrian wrote:

To emphasize the forest analogy: Concentrating on the tree only generates a
nice tree. The problem is that the forest is then populated by that tree
only. The first infection then jeopardizes the entire forest.

Yes, this analogy may sound good, but in reality [...]

I think that analogy is lost on you. Sorry I couldn't find anything
better.

[BigBrian]

> >>To emphasize the forest analogy: Concentrating on the tree only generates a

nice tree. The problem is that the forest is then populated by that tree
only. The first infection then jeopardizes the entire forest.

Yes, this analogy may sound good, but in reality [...]

I think that analogy is lost on you. Sorry I couldn't find anything
better.

So, since I don't agree that this analogy appiles to writting code, you
infer that I just don't understand. I gave my reasons, you can
disagree with them if you like ( but your inference is not called for).