Confused about learning C++

[utab]

Dear,

I have experince in C( numerical projects, like engineering problems,
scientific applications) I have the basic notion of C++ also, I have
read Accelerated C++ until Chapter 7, however it seems that it
discusses the std and the other part of the language with your own
abstractions. Is that better to read a book first on the basic concepts
of C++ language (but not the C part) that gives the basics as if the
reader is a beginner such as

C++ Primer Plus by Prata
Teach Yourself C++ in 21 days by Liberty...

or any other book that you would recommend for first step reading. I am
a bit confused how to proceed.

Thx in advance.

Regards.

 

[Hiker Hauk]

Hi there,

I suggest that you should do plenty of practice before you move to
senior topics.
When you've done enough practice, you'll understand it naturally.

Reagrds.

 

[Kai-Uwe Bux]

Dear,

I have experince in C( numerical projects, like engineering problems,
scientific applications) I have the basic notion of C++ also, I have
read Accelerated C++ until Chapter 7, however it seems that it
discusses the std and the other part of the language with your own
abstractions. Is that better to read a book first on the basic concepts
of C++ language (but not the C part) that gives the basics as if the
reader is a beginner such as

C++ Primer Plus by Prata
Teach Yourself C++ in 21 days by Liberty...

or any other book that you would recommend for first step reading. I am
a bit confused how to proceed.

I have no book recommendations, however, I would suggest to learn C++
concepts in the following order:

* standard library: containers, iterators, algorithms, streams.
* classes.
* function objects.
* exceptions and flow control via throw/catch.
* templates.
* smart pointers (e.g., tr1::shared_ptr<> )
* raw pointers and arrays.

I didn't do it in that order; and I feel that, as a consequence, it took me
quite some time before simple and straight forward solutions to common
problems came to me naturally.


Best

Kai-Uwe Bux

 

[Bo Persson]

Dear,

I have experince in C( numerical projects, like engineering
problems,
scientific applications) I have the basic notion of C++ also, I have
read Accelerated C++ until Chapter 7, however it seems that it
discusses the std and the other part of the language with your own
abstractions. Is that better to read a book first on the basic
concepts
of C++ language (but not the C part) that gives the basics as if the

The point of this book is that the standard library *is* an integral
part of the C++ language. It is a clear intention that you should
learn to use the library classes, and build your own abstractions from
that.

Part of your confusion might be that this book treats C++ a language
totally different from C. A very good idea, IMO.


Bo Persson

 

[benben]

I have no book recommendations, however, I would suggest to learn C++

concepts in the following order:

* standard library: containers, iterators, algorithms, streams.
* classes.
* function objects.
* exceptions and flow control via throw/catch.
* templates.
* smart pointers (e.g., tr1::shared_ptr<> )
* raw pointers and arrays.

I didn't do it in that order; and I feel that, as a consequence, it took me
quite some time before simple and straight forward solutions to common
problems came to me naturally.

I don't suggest learning C++ concepts with any particular order.
Instead, swallow the basics of everything then come back and revisit all
of those and come back...the iteration never quite ends for me.

Ben

 

[Tomás]

I have no book recommendations, however, I would suggest to learn C++
concepts in the following order:

* standard library: containers, iterators, algorithms, streams.
* classes.
* function objects.
* exceptions and flow control via throw/catch.
* templates.
* smart pointers (e.g., tr1::shared_ptr<> )
* raw pointers and arrays.

I practically learned it all the other way round!

I would always advocate teaching the actual language itself before moving
on to its Standard Libraries.

For instance, I would teach:

+ Variables
+ Pointers
+ Arrays
+ Functions
+ Structures
+ Exceptions
+ Templates
+ Classes

After that, I'd show them the Standard Library.

-Tomás

 

[Daniel T.]

Dear,

I have experince in C( numerical projects, like engineering problems,
scientific applications) I have the basic notion of C++ also, I have
read Accelerated C++ until Chapter 7, however it seems that it
discusses the std and the other part of the language with your own
abstractions. Is that better to read a book first on the basic concepts
of C++ language (but not the C part) that gives the basics as if the
reader is a beginner such as

I'm not sure what "the basic parts of C++ (but not the C part)" is. Are
you talking about things like keywords that are in C++ but not C?

I don't have the book, but in looking over the source code from the web
site, I'd say they are doing a pretty good job of it.

What is it that you feel you are missing out on? You'll be writing your
own classes soon (about chapter 9 it looks like) and you already are
using structs...

C++ Primer Plus by Prata
Teach Yourself C++ in 21 days by Liberty...

or any other book that you would recommend for first step reading. I am
a bit confused how to proceed.

I suggest you continue with the book you have. Do all the exorcises in
it. Ask us questions is you have problems, and/or find a tutor in your
area who is willing to work with you...

 

[Bo Persson]

I practically learned it all the other way round!

I would always advocate teaching the actual language itself before
moving
on to its Standard Libraries.

For instance, I would teach:

+ Variables
+ Pointers
+ Arrays
+ Functions
+ Structures
+ Exceptions
+ Templates
+ Classes

That's exactly what the "Accelerated C++" book is trying to avoid.


By introducing streams and strings in chapter 1, and pointers (as "a
kind of random access iterators") in chapter 10, the book is teaching
C++ as a language of its own. Not some kind of C-language.

The focus is on std::string, not C style strings, on using what is
already in the library, like algorithms and containers, introducing
the iterator concept while you go. It then goes on to introduce
generic functions (write your own templates!), class types,
constructors and destructors.

Only then, and mostly to be able to explain what the 'const char*'
type means for a string literal, does it mention pointers and arrays.
Reluctantly!

Then, in chapters 11 and 12, we go on the define abstract data types,
and classes that behave like values. Much more useful, and important
in C++!


If you haven't tried it, you really should. I had great fun reading
it!



Bo Persson

 

[Roland Pibinger]

The point of this book is that the standard library *is* an integral
part of the C++ language.

No, a language is a language and a library is just a library, even
though it's the Standard library.

It is a clear intention that you should
learn to use the library classes, and build your own abstractions from
that.

According to Stroustrup, C++ is a 'Multiparadigm Language'. I don't
see the point in learning the most difficult and unser unfriendly
paradigm first or even solely.

Part of your confusion might be that this book treats C++ a language
totally different from C.

The OO paradigm is much more different from procedural C programming
than the moderately functional STL/generic programming paradigm. The
main difference is template instead of preprocessor obfuscation. A
good C programmer can understand the basics of STL in 10 minutes.

A very good idea, IMO.

I beg to differ.

Best wishes,
Roland Pibinger

 

[Alf P. Steinbach]

* Roland Pibinger:

* Bo Persson:

No, a language is a language and a library is just a library, even
though it's the Standard library.

Reality check: the built in language feature operator new throws a
std::bad_alloc exception, which comes from the library. nothrow, which
is part of the core syntax, also comes from the library. There isn't a
clear demarcation between core language and library.

Many features that are integral parts of other languages have been left
out in the C++ core language because they could be implemented as
library solutions.

Thus, in comparision with other languages, one must include at least
those parts of the standard library (vector, string, and the upcoming
array, tuple and shared_ptr classes), and the question is where one
subjectively draws the line between core language support and pure
"added value". The authors of Accelerated C++ seemingly think most of
the library belongs with the language proper. I think less of it
belongs with the language proper (I especially hate iostreams!), but
nevertheless I agree with the viewpoint that using the library is the
only good way to introduce C++ -- because raw pointers and arrays and
C i/o and the like is just too error-prone, and stands in the way.

 

[Bo Persson]

No, a language is a language and a library is just a library, even
though it's the Standard library.

The standard says that by using

#include <string>

you have access to the std::string type. That's what is taught in
chapter 1 of the book.

The fact that the std::string type can optionally be built into the
compiler, or implemented in a library is NOT mentioned in the
introduction. Pretty good I think!

According to Stroustrup, C++ is a 'Multiparadigm Language'. I don't
see the point in learning the most difficult and unser unfriendly
paradigm first or even solely.

You mean like pointers, and arrays, and malloc, and strcpy?

They are saved until much later!

The OO paradigm is much more different from procedural C programming
than the moderately functional STL/generic programming paradigm. The
main difference is template instead of preprocessor obfuscation. A
good C programmer can understand the basics of STL in 10 minutes.

It has nothing to do with OO (like in everything is dynamic and
virtual). It's about using what is in the standard. The C++ language
has a lot more to offer than C has. So the book starts with that!

Many C programmers never seem to understand the standard library, but
see it as difficult, and user unfriendly, and templates as some kind
of macros. And code bloat, of course.

This book teaches templates first, without confusing the student with
macros! It teaches generic functions first, without doing some other
kind first. It teaches iterators, algorithms, and classes, without
mentioning void* or pointer arithmetic or the C library.

A very good idea, IMO.

I beg to differ.

You're welcome!


Bo Persson

 

[Roland Pibinger]

Reality check: the built in language feature operator new throws a
std::bad_alloc exception, which comes from the library. nothrow, which
is part of the core syntax, also comes from the library. There isn't a
clear demarcation between core language and library.

This is a language lawyer's point of view.

Many features that are integral parts of other languages have been left
out in the C++ core language because they could be implemented as
library solutions.

Thus, in comparision with other languages, one must include at least
those parts of the standard library (vector, string, and the upcoming
array, tuple and shared_ptr classes), and the question is where one
subjectively draws the line between core language support and pure
"added value".

A real reality check: The C++ world is highly fragmented. When people
speak of C++ they usually mean one of the C++ 'communities' gathering
around a framework (MFC/VC++, Qt, Gnome, wxWidgets, ..., some internal
framework) or a domain (embedded programming, game programming, ...).
AFAIK, non of these communities has adopted the C++ Standard library
(iostreams, string, STL). They usually have kept their own solutions.

The authors of Accelerated C++ seemingly think most of
the library belongs with the language proper. I think less of it
belongs with the language proper (I especially hate iostreams!),

But why STL and string?

but
nevertheless I agree with the viewpoint that using the library is the
only good way to introduce C++ -- because raw pointers and arrays and
C i/o and the like is just too error-prone, and stands in the way.

Ha, a push_back() invalidates an iterator, no difference to raw
pointers and realloc-ed dynamic arrays. People copy and paste 'while
(cin >> i)' without having an idea of its meaning. All of the Standard
libraries produce heavily obfuscated error messages from (failed)
template instantiation on the slightest error, even string. If you
want to drive students away from C++ learn them C++ with the Standard
library.

Best regards,
Roland Pibinger

 

[Mirek Fidler]

only good way to introduce C++ -- because raw pointers and arrays and

Ha, a push_back() invalidates an iterator, no difference to raw
pointers and realloc-ed dynamic arrays. People copy and paste 'while
(cin >> i)' without having an idea of its meaning. All of the Standard
libraries produce heavily obfuscated error messages from (failed)
template instantiation on the slightest error, even string. If you
want to drive students away from C++ learn them C++ with the Standard
library.

You know, I know... What a pitty you still refuse the cooperation

Mirek

 

[Gavin Deane]

I practically learned it all the other way round!

That's no reason to inflict your misfotune on others.

I would always advocate teaching the actual language itself before moving
on to its Standard Libraries.

To write a Hello World program then modify the greeting to use their
own name, a C++ student will use stream IO and strings. I would suggest
this is a widespread and appropriate first programming task. Surely you
aren't suggesting that students must spend time learning the entire
core language before writing their first program?

There is a difference between knowing how to use strings, containers,
algorithms etc. and knowing how to implement them and how they work
internally.

There is also a difference between teaching C++ to someone who has
never programmed before and teaching, for example, an experienced C
programmer. The former should be shown std::string before char* because
arrays are hard. The latter should be shown std::string before char* to
emphasise from the outset that C++ is not C with classes.

For instance, I would teach:

+ Variables
+ Pointers
+ Arrays
+ Functions
+ Structures
+ Exceptions
+ Templates
+ Classes

After that, I'd show them the Standard Library.

You think any of them would hang around long enough for you to get to
that?

Gavin Deane

 

[Tomás]

The former should be shown std::string before char* because

arrays are hard.

This is the basis of our disagreement.

I don't see arrays and pointers as "difficult". People learning the
Polish language may find it difficult, but the natives just yap away
without a second thought.

You might stutter and stammer with arrays and pointers during the
learning process, but if you've any aptitude for this stuff at all,
you'll get the hang of it in no time.

I frequently use arrays of "char"'s when I feel that it would be unjustly
inefficient to use an "std::string".

I exert minimal effort in using these "char" arrays, and I don't find
them difficult -- this is because I have a firm understanding of what's
going on.

Arrays and pointers aren't hard. Don't water-down C++ tutorials just
because a few learners aren't bothered doing some real learning. It's
good to separate the apt people from the not-so-apt early on. Not all of
us have the aptitude to be an exemplary programmer. If you don't, then it
is futile to pursue it. Maybe you're a good sculptor or pianist or
gymnast?

Arrays of "char"'s aren't "hackery" or "hardcore". To describe them as
such just indicates one's inaptitude.

That's my opinion.

-Tomás

 

[Ben Pope]

Arrays of "char"'s aren't "hackery" or "hardcore". To describe them as
such just indicates one's inaptitude.

That's my opinion.

Perhaps. But compare a correct program for reading in the users name
and displaying it with C style char* strings and then with std::string.
Preventing buffer overrun, managing memory and everything else that
goes along with that makes it much more difficult to learn. You need to
introduce pointers, arrays, memory management etc. etc. just to write
hello world. It detracts from the relatively simple problem at hand.

Ben Pope

 

[Kai-Uwe Bux]

This is the basis of our disagreement.

I don't see arrays and pointers as "difficult". People learning the
Polish language may find it difficult, but the natives just yap away
without a second thought.

You might stutter and stammer with arrays and pointers during the
learning process, but if you've any aptitude for this stuff at all,
you'll get the hang of it in no time.

I frequently use arrays of "char"'s when I feel that it would be unjustly
inefficient to use an "std::string".

I exert minimal effort in using these "char" arrays, and I don't find
them difficult -- this is because I have a firm understanding of what's
going on.

Arrays and pointers aren't hard. Don't water-down C++ tutorials just
because a few learners aren't bothered doing some real learning.

Pointers are inherently hard in C++. The reason is that the programmer has
to ensure that along *every* possible path of flow control an allocated
pointer be deleted once and only once. This requires more than local
knowledge of your program and is hard even in comparatively simple
languages. In C++, life is even more complicated since other features of
the language interfere with flow control: templates and exceptions. When
writing templated code, you have to be prepared to deal with the quirks of
user supplied types. Since any (copy) constructor can result in the
creation of an arbitrarily complicated data structure, the only correct
attitude toward your code is: every line may throw, in fact, every
evaluation of an expression may throw without any guarantees which side
effects have taken place and which have not. This leads to innocent looking
code being leaky:

template < typename T >
class foo {

T* data;

public:

foo ( T const & t ) {
data = new T;
*data = t;
}

~foo () {
delete data;
}

};

If you want to be able to discuss those issues rationally with your
students, I strongly recommend that they know exceptions and templates
before diving into raw pointers. The problem with teaching pointers first
is that the students are likely to develop a coding style that becomes
inherently unsafe when templates and exceptions enter the picture.

It's
good to separate the apt people from the not-so-apt early on. Not all of
us have the aptitude to be an exemplary programmer. If you don't, then it
is futile to pursue it. Maybe you're a good sculptor or pianist or
gymnast?

Arrays of "char"'s aren't "hackery" or "hardcore". To describe them as
such just indicates one's inaptitude.

Arrays of char are, admittedly, not as hard as pointers in general. However,
they are hard enough to avoid them before the more important issues of
exception safety have been discussed.


Best

Kai-Uwe Bux

 

[Tomás]

Ben Pope posted:

Perhaps. But compare a correct program for reading in the users name
and displaying it with C style char* strings and then with std::string.
Preventing buffer overrun, managing memory and everything else that
goes along with that makes it much more difficult to learn. You need to
introduce pointers, arrays, memory management etc. etc. just to write
hello world. It detracts from the relatively simple problem at hand.

Ben Pope

Valid point.

I conceed that one cannot deny the simplicity of:

void AppendHello(std::string &str)
{
str += "Hello";
}

over:

void AppendHello(char* p_char)
{
p_char += std::strlen(p_char);

*p_char = 'H';
*(++p_char) = 'e';
*(++p_char) = 'l';
*(++p_char) = 'l';
*(++p_char) = 'o';
*(++p_char) = 0;
}

I'd even use a template if possible:

template<std::size_t len>
void AppendHello(char p_char[len])
{
p_char += len;
--p_char;

*p_char = 'H';
*(++p_char) = 'e';
*(++p_char) = 'l';
*(++p_char) = 'l';
*(++p_char) = 'o';
*(++p_char) = 0;
}


If I can think in my head the way I want to manipulate a string, and can
produce the necessary code, then I'll use pointers and arrays. Yes it's more
efficient... but I also find it downright fun!

If, however, things get too complicated, then I'll go with an "std::string".
Maybe if I was writing a program, and wanted to get on to more exciting
parts of it, I'd just use "std::string"'s, and later go back over it and
optimise it with arrays of "char"'s.

Looking at the "Hello World" example:

#include <iostream>

int main()
{
std::cout << "Hello World!";
}


I've always thought this was a horific piece of code to throw in front of a
beginner. I started out programming in Visual Basic when I was about twelve,
and then when I moved on to C++, I was greeted with this really weird way of
printing things to the screen. I hadn't a clue what the craic was with the
"<<".

To trully understand how "cout" works, one has to understand operator
overloading. Only then can one realise, "Oh yeah, they overloaded the bit-
shift operator to make it look like you're putting things toward cout".

When I first saw the statement, I hadn't a bull's notion what "cout" was. Is
it an object? Is it a class? Is it Superman?

I'd re-assure learners that the whole "cout <<" thing should *indeed* appear
very strange to them, but that they should just accept that that's how it is
until they learn operator overloading, at which point everything will become
abundantly clear.

-Tomás

 

[Ben Pope]

Ben Pope posted:



Valid point.

I conceed that one cannot deny the simplicity of:

void AppendHello(std::string &str)
{
str += "Hello";
}

Easy and safe.

over:

void AppendHello(char* p_char)
{
p_char += std::strlen(p_char);

*p_char = 'H';

// Ouch I hope p_char points to a buffer long enough.

*(++p_char) = 'e';
*(++p_char) = 'l';
*(++p_char) = 'l';
*(++p_char) = 'o';
*(++p_char) = 0;
}

I'd even use a template if possible:

template<std::size_t len>
void AppendHello(char p_char[len])
{
p_char += len;
--p_char;

*p_char = 'H';
*(++p_char) = 'e';
*(++p_char) = 'l';
*(++p_char) = 'l';
*(++p_char) = 'o';
*(++p_char) = 0;
}

Again, no check that the buffer is long enough! That could easily be
checked with your template, yet it is not.

If I can think in my head the way I want to manipulate a string, and can
produce the necessary code, then I'll use pointers and arrays. Yes it's more
efficient... but I also find it downright fun!

Well, you've already demonstrated how much fun buffer overruns are. I
prefer not to track down them problems. For me, solving problems is
fun, not creating them.

If, however, things get too complicated, then I'll go with an "std::string".

Too complicated? I thought you "exert minimal effort in using these
"char" arrays, and [you] don't find them difficult".

Maybe if I was writing a program, and wanted to get on to more exciting
parts of it, I'd just use "std::string"'s, and later go back over it and
optimise it with arrays of "char"'s.

Yeah, always optimise after you have a working implementation with test
cases, and a profiler tells you that the code requires optimisation.

Looking at the "Hello World" example:

#include <iostream>

int main()
{
std::cout << "Hello World!";
}


I've always thought this was a horific piece of code to throw in front of a
beginner. I started out programming in Visual Basic when I was about twelve,
and then when I moved on to C++, I was greeted with this really weird way of
printing things to the screen. I hadn't a clue what the craic was with the
"<<".

...along with many other things, if you're a beginner.

To trully understand how "cout" works, one has to understand operator
overloading.

Not really. just think of it as "magic" or the standard syntax.

Only then can one realise, "Oh yeah, they overloaded the bit-
shift operator to make it look like you're putting things toward cout".

Oh, so "<<" innately means bit-shift? Why would it mean bit shift
rather than "stream formatter" to a learner?

When I first saw the statement, I hadn't a bull's notion what "cout" was. Is
it an object? Is it a class? Is it Superman?

....because you learnt backwards. I'm pretty sure it wouldn't have taken
you long to figure it out. Besides, "cout" is much short than "printf".
And what the hell does:

double d = 4.0;
printf("%#4.2lf", d);

Actually mean?

I'm cheating of course, because such a statement can be a PITA to
implement with iostreams, but even printf("%lf", d); is cryptic enough.

I'd re-assure learners that the whole "cout <<" thing should *indeed* appear
very strange to them, but that they should just accept that that's how it is
until they learn operator overloading, at which point everything will become
abundantly clear.

Of course. I'm pretty sure much syntax appears strange to newcomers.
But that's the challenge. I don't see << as such a special case.

Ben Pope

 

[utab]

That is fine that my thread is the most discussed one )) but still no
reply to the original question.

please can anyone tell me mostly the better way to follow to grasp
ideas behind the language. This was not a question for experts to
discuss their knowledge on the language )

Is that better to read a book first on the basic concepts
of C++ language (but not the C part and not the stl part) that gives
the basics as if the
reader is a beginner such as

C++ Primer Plus by Prata
Teach Yourself C++ in 21 days by Liberty...

or any other book that you would recommend for first step reading.