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********@hotmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.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**@brianmielke.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.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 "intricacies" 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 "intricacies" 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).

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

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

Writing code is only part of programming. Writing perfect code is only
one possible way of implementing something. I think if you only see that
the analogy applies to writing code, you have already lost the view of the
forest for the trees. [And whatever inferences I draw don't have to be
called for. I draw them because I want to or because I feel like doing
so. No offense is intended in either case.]

I said I was sorry because I couldn't find a better (easier to understand)
analogy. Here is another one: while studying patterns of seasonal bird
migrations, there is no sense in concentrating on the shape of
a particular bird's wings, although they might play some role in how far
or how fast birds can fly... No? Missed again? I give up then.

V

[Andrew Koenig]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:lM*******************@newsread1.mlpsca01.us.t o.verio.net...

I said I was sorry because I couldn't find a better (easier to understand)
analogy. Here is another one: while studying patterns of seasonal bird
migrations, there is no sense in concentrating on the shape of
a particular bird's wings, although they might play some role in how far
or how fast birds can fly... No? Missed again? I give up then.

Here's another try: You need more than just a good vocabulary to be a good
writer. Most people will improve their writing faster by studying how to
use the words they already know than they will by learning new words.

[Victor Bazarov]

Andrew Koenig wrote:

[...] You need more than just a good vocabulary to be a good
writer. Most people will improve their writing faster by studying how to
use the words they already know than they will by learning new words.

Thanks, Andrew, that helps.

[Robbie Hatley]

"BigBrian" <wo**@brianmielke.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.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.

Ummm, yes; and I've seen a whole lot of code written by
a man who DOES understand the intricacies of C and C++,
and yet, his code is extremely brittle and hard to maintain.
I should know, because I'm the one hired to maintain it
after he was fired.

Making code non-brittle has more to do with seeing a bigger
picture, asking "what if conditions x or y change? What if...
what if... what if..." and taking steps to innoculate the
code against those contingencies.

Brittle code comes about when someone is rushed or lazy or
panicing to meet a deadline. "Contingencies?! Structure?!
Documentation?! Who has time for that $#!^! I've got to
get this @#$%&*!#$ program working!!!" Hence, code that
works, but is 650000 lines long, has no comments, has no
documentation, is full of subtle bugs, and is hard to
maintain.

Sigh.
--
Cheers,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant


----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----