By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,145 Members | 1,688 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,145 IT Pros & Developers. It's quick & easy.

Confused about learning C++

P: n/a
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.

Feb 19 '06 #1
Share this Question
Share on Google+
36 Replies


P: n/a
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.

Feb 19 '06 #2

P: n/a
utab wrote:
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
Feb 19 '06 #3

P: n/a

"utab" <um********@gmail.com> skrev i meddelandet
news:11**********************@z14g2000cwz.googlegr oups.com...
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
Feb 19 '06 #4

P: n/a
> 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
Feb 19 '06 #5

P: n/a
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
Feb 19 '06 #6

P: n/a
In article <11**********************@z14g2000cwz.googlegroups .com>,
"utab" <um********@gmail.com> wrote:
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...
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
Feb 19 '06 #7

P: n/a

"Tomás" <NU**@NULL.NULL> skrev i meddelandet
news:gG******************@news.indigo.ie...
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


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
Feb 19 '06 #8

P: n/a
On Sun, 19 Feb 2006 11:41:21 +0100, "Bo Persson" <bo*@gmb.dk> wrote:
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
Feb 19 '06 #9

P: n/a
* Roland Pibinger:
* Bo Persson:
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.


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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Feb 19 '06 #10

P: n/a

"Roland Pibinger" <rp*****@yahoo.com> skrev i meddelandet
news:43**************@news.utanet.at...
On Sun, 19 Feb 2006 11:41:21 +0100, "Bo Persson" <bo*@gmb.dk> wrote:
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.


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


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

They are saved until much later!
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.


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.
A very good idea, IMO.
I beg to differ.


You're welcome!
Bo Persson


Best wishes,
Roland Pibinger

Feb 19 '06 #11

P: n/a
On Sun, 19 Feb 2006 18:29:34 +0100, "Alf P. Steinbach"
<al***@start.no> wrote:
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
Feb 19 '06 #12

P: n/a
>>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.


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

Mirek
Feb 20 '06 #13

P: n/a

Tomás wrote:
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!


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

Feb 20 '06 #14

P: n/a
> 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
Feb 20 '06 #15

P: n/a
Tomás wrote:
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
--
I'm not just a number. To many, I'm known as a string...
Feb 20 '06 #16

P: n/a
Ben Pope posted:
Tomás wrote:
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

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
Feb 20 '06 #17

P: n/a
Tomás wrote:
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.


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
Feb 20 '06 #18

P: n/a
Tomás wrote:
Ben Pope posted:
Tomás wrote:
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

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
--
I'm not just a number. To many, I'm known as a string...
Feb 20 '06 #19

P: n/a
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.

Feb 20 '06 #20

P: n/a
In article <gG******************@news.indigo.ie>,
"Tomás" <NU**@NULL.NULL> wrote:
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.


Note, without the standard libraries, the student will be completely
unable to do *any* input/output, will not be able to do semi-advance
math calculations, and will not be able to do even simple string
processing...

Are you advocating that the student should have to build all the library
provided functionality him/herself?

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
Feb 20 '06 #21

P: n/a
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)...


If I'm ever a C++ lecturer, I will have a policy whereby students get a
whip of cane if they mention the C programming language.

In bible speak, C++ is a programming language unto itself.

If you want to learn about humans, then learn about humans. Why go
learning about homo erectus, and then proceed to learn about homo
sapiens? Just get the book called "All about Homo Sapiens".

If you want a term to describe the apsects of C++ which are common to C,
may I suggest:

Non-object orientated aspects of C++
Non-template orientated aspects of C++
Non-namespace...

-Tomás
Feb 20 '06 #22

P: n/a
utab wrote:
That is fine that my thread is the most discussed one :))) but still no
reply to the original question.
We've moved away from there.
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 :))
Well,t hats where this part of your thread has gone, feel free to ignore
it. You are allowed to start a thread, we are allowed to veer off course.
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.


IMO you should use the book you are using, Accelerated C++.

You haven't answered the questions posed to you by Daniel T., if you
feel you are missing out on something, or struggling with a particular
part of the book, then let us know.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...
Feb 20 '06 #23

P: n/a
I am not meaning not to use the std library as needed in our
applications(as needed the necessray parts can be learnt and thought)

I am just telling someone who had a good grasp of classes, operator
overloading, inheritance, polymorphism, and data structures(exercised
enough) can grasp the ideas behind the STL components better so that is
what I think the reasonable.

Thx for the replies.

Feb 20 '06 #24

P: n/a
On 2006-02-20, Tomás <NU**@NULL.NULL> wrote:
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.


A benefit to learning selected portions of the library before delving
into char*, is that C++ thus appears to be a language with which a
beginner can *do* interesting things. Learning it the other way around
makes it appear to be a language that is filled with strange rules and
gotchas, in which a beginner cannot even do tasks that would take
minutes with pencil and paper.
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 agree that anyone can learn it.
I frequently use arrays of "char"'s when I feel that it would be
unjustly inefficient to use an "std::string".
Have you ever been wrong in your feeling?
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.
I agree those skills must be learned eventually.
Arrays and pointers aren't hard.
But they are hard to learn. There is ample evidence of this posted
here nearly every week.
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.
How is it watered down to learn standard containers and algorithms,
along with generic programming? They are powerful mechanisms. They are
a practical selection of features to learn first.

The top-down, practical approach to learning C++ is empowering. I
suppose you might fear that a programmer thus taught will *never*
learn about pointers, <cstring>, and efficiency, thus polluting your
workplace with their ignorance. But that's as illogical as if I were
to claim that the bottom-up learner shall never learns the standard
container classes.
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.


Ridiculous.

--
Neil Cerutti
Feb 20 '06 #25

P: n/a
In article <Za******************@news.indigo.ie>,
"Tomás" <NU**@NULL.NULL> wrote:
Ben Pope posted:
Tomás wrote:
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

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!


Let's try making the code equivalent before dissing the std::string
version. The thing is, we can't make an equivalent function without
using any standard libraries. How are you going to allocate memory from
the heap without #including any library files?

The below is about as close as we can come, and it *still* doesn't do
everything that the a simple str += "Hello" does.

void AppendHello( char* block, int block_size ) {
if ( block ) {
char* p_char = block;
while ( *p_char != 0 ) {
++p_char;
}
const char* hello = "Hello";
while ( p_char - block < block_size && *hello)
*p_char++ = *hello++;
*p_char = 0;
}
}

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
Feb 20 '06 #26

P: n/a
On 2006-02-20, Tomás <NU**@NULL.NULL> wrote:
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)...
If I'm ever a C++ lecturer, I will have a policy whereby students get a
whip of cane if they mention the C programming language.


I'm glad you are not and were not then.

IMO All programmers should get a working knowledge of C so that they
understand basic computing primitives and types. it breeds confidence,
a feel for performance and a healthy respect for memory usage
(efficiency, allocation and deallocation) : all skills severely
lacking in a LOT of newer programmers.

In bible speak, C++ is a programming language unto itself.

With standard libraries maybe.
If you want to learn about humans, then learn about humans. Why go
learning about homo erectus, and then proceed to learn about homo
sapiens? Just get the book called "All about Homo Sapiens".

If you want a term to describe the apsects of C++ which are common to C,
may I suggest:

Non-object orientated aspects of C++
Non-template orientated aspects of C++
Non-namespace...

-Tomás


What does "non-namespace" mean here?
--
Remove evomer to reply
Feb 20 '06 #27

P: n/a

Tomás wrote:
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 ofa
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 wayof
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".
This is the basis of our disagreement.

Who cares about truly understanding how cout works? The point is that
by utilising the tools provided by the standard library from the outset
a C++ student can immediately be more productive in creating correct,
clear programs, which is the goal of all programming. An understanding
of what is really going on in that statement - what is cout, what is
<<, what is overloading and how is it achieved - can be left until much
later without imparing their ability to write programs. Exactly the
same argumant applies to dynamic arrays vs vectos, char* vs strings
etc.

As for recognising << as a bit shift operator, that might be the case
for someone with previous experience of C. In that case, issues like
char* vs string is not so much to do with what is easiest to learn (a C
programmer will already know how to use char arrays). The issue is what
helps you write correct code more easily that will potentially be
maintained by C++ programmers who do not have a C background.

A complete novice will not recognise << as a bit shift operator. To
them it will be the stream insertion operator, which is no bad thing,
since that is often its main use. Later they will encounter its use in
bit shifting. If operator overloading has come up already this can be
shown as an example. It's not particularly important which is the core
language meaning and which is the library overload at this stage.
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 itis
until they learn operator overloading, at which point everything will become
abundantly clear.


Operator overloading should not be mentioned unless you are teaching C
programmers who already know << to mean something else.

The real problem is one of primacy. Unless you put in concious effort
to avoid it, you will innately fall back on what you learn first.

When writing a C++ program, for clarity, correctness and robustness,
vector should always be the default preference over a dynamic array and
string should always be the default preference over char* (which is
certainly hackish). If you teach them the wrong way round, there is the
risk that the standard library components will be regarded as clever
and advanced variations. The student's natural way of thinking about
programming with strings will be char*, because that's what they learnt
first. It's certainly possible to break this backwards thinking, but
why introduce the need when it can be avoided so easily?

WIth C programmers learning C++, the primacy battle is already lost and
the only option is to break the entrenched backwards thinking. All the
more reason to hammer home the point early and hard and often.

Gavin Deane

Feb 20 '06 #28

P: n/a
utab wrote:
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
If you're starting from ground zero, and haven't done any programming
before at all, I'd suggest _You can do it_, by Francis Glassborrow. If
you've done some programming before, then I'd suggest skipping that and
going directly to _Accelerated C++_ (by Koenig and Moo).
C++ Primer Plus by Prata
I'm not sure, but IIRC, when I glanced through this in the book store,
it didn't impress me a lot. I wouldn't say it's a terrible book by any
means, but it didn't impress me as a particularly good one either.
Unless memory serves me even worse than usual today, it's built on the
assumption that you have some (but not necessarily much) previous
programming experience, and if that's the case, I'd say _Accelerated
C++_ is a lot better place to start.
Teach Yourself C++ in 21 days by Liberty...


If I were a better person, I wouldn't recommend this to anybody. As it
is, I might recommend it, but only to somebody I thoroughly despised.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Feb 20 '06 #29

P: n/a
In article <45************@individual.net>,
"Richard G. Riley" <rg***********@gmail.com> wrote:
On 2006-02-20, Tomás <NU**@NULL.NULL> wrote:

In bible speak, C++ is a programming language unto itself.


With standard libraries maybe.


And without the standard libraries, you can't do anything.

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
Feb 20 '06 #30

P: n/a
In article <11********************@f14g2000cwb.googlegroups.c om>,
"utab" <um********@gmail.com> wrote:
I am not meaning not to use the std library as needed in our
applications(as needed the necessray parts can be learnt and thought)
You can't write a anything useful without including at least some
library. Are you advocating using only non-standard libraries?

I am just telling someone who had a good grasp of classes, operator
overloading, inheritance, polymorphism, and data structures(exercised
enough) can grasp the ideas behind the STL components better so that is
what I think the reasonable.
What is it that you are having trouble grasping? I'm looking at the
exorcises for chapter 7 and I don't see anything where knowledge of
classes, operator overloading, inheritance, or polymorphism would help.
As for data structures, that was covered in an earlier chapter.

Maybe the book is going too fast for you? Explain the problem and we'll
try to help. (at least I will.)

However, to once again answer your original question:

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


That is exactly what "Accelerated C++" does. It assumes the reader is a
beginner at C++ (though maybe not a beginner programmer) and teaches you
the language. However, if you are having trouble grasping some of the
concepts, that's understandable, the book doesn't spend much time on any
of them, but kind of breezes over them. What concepts are you having
trouble with? I'll be happy to help out. Since you are on chapter 7, is
it something about associative containers that is giving you trouble?
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
Feb 20 '06 #31

P: n/a
On Mon, 20 Feb 2006 11:28:59 +0100, Mirek Fidler <cx*@volny.cz> wrote:

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


Well, you not only invented your own library but also your own
language (pick semantics, Moveable, PolyDeepCopyNew, ...), tailored
for your needs and ideas. What suits you well may not suit others
equally well. Anyway, the result of your effort, Ultimate++, is
respectable.

Best wishes,
Roland Pibinger
Feb 20 '06 #32

P: n/a
Not related with the exercises of chapter 7
I have not finished Chapter 7 yet and May I ask you a question, how
long have you known C++ and from where you get started.

I got started with Teach yourself C++ in 21 days did not like it
I read also C++ primer plus until chapter 10 but most of it was known
before me so skipped that
I read some parts of C++ Programming Language it went over my head.
I got the book Deitel C++ How to Program from the library it seems fine
but many pages :((
Accelerated C++ is OK to what extent your programming knowledge is up
IMHO. Maybe it is a bit high level for me even if I did C coding for
numerical problems

This became a thread on the books about C++ not the language :((

Feb 20 '06 #33

P: n/a
Roland Pibinger wrote:
On Mon, 20 Feb 2006 11:28:59 +0100, Mirek Fidler <cx*@volny.cz> wrote:
You know, I know... What a pitty you still refuse the cooperation :)

Well, you not only invented your own library but also your own
language (pick semantics, Moveable, PolyDeepCopyNew, ...), tailored
for your needs and ideas.


Interesting point of view, however the same can be said about STL... If
you are going so solve some issues, you have to introduce some new
features and concepts... (and no, there are of course no changes to the
core language).

BTW, I have seen you have implemented your own owning container, similar
to U++ Array... How you are solving deep copy of container full of
polymorphic values? (if you allow them) (this about PolyDeepCopyNew
issue...)

Mirek
Feb 20 '06 #34

P: n/a
On Mon, 20 Feb 2006 23:01:25 +0100, Mirek Fidler <cx*@volny.cz> wrote:
Roland Pibinger wrote:
On Mon, 20 Feb 2006 11:28:59 +0100, Mirek Fidler <cx*@volny.cz> wrote:
Well, you not only invented your own library but also your own
language (pick semantics, Moveable, PolyDeepCopyNew, ...), tailored
for your needs and ideas.
Interesting point of view, however the same can be said about STL... If
you are going so solve some issues, you have to introduce some new
features and concepts... (and no, there are of course no changes to the
core language).


When the copy constructor 'picks' the the original then you change
usual language semantics. 'Copy' usually means 'duplicate'.
BTW, I have seen you have implemented your own owning container, similar
to U++ Array...
Not quite. My container owns nothing. Owning containers ("smart"
containers) that require transfer of ownership usually run into
trouble.
How you are solving deep copy of container full of
polymorphic values? (if you allow them) (this about PolyDeepCopyNew
issue...)


One needs to distinguish between 'value types' and (possibly
polymorphic) 'entity types'. The latter have state and identity and
are usually not copyable. I know, there are situations where you want
to copy (in the meaning of 'duplicate' not 'pick') entity objects. But
that should be an exception, not the rule. I would prohibit copying
for containers of polymorphic contents.

Best wishes,
Roland Pibinger
Feb 20 '06 #35

P: n/a
In article <11**********************@o13g2000cwo.googlegroups .com>,
"utab" <um********@gmail.com> wrote:
Not related with the exercises of chapter 7
I have not finished Chapter 7 yet and May I ask you a question, how
long have you known C++ and from where you get started.
I first started learning C++ back around 1993, about 2 years after I
began learning C. I probably read every "learn C++" book that existed at
the time so I couldn't really say which book(s) I got started with. I
know I owned "C++ for Dummies" at one point, it may have been one of the
first books I bought on the language, however I also read every C++ book
that I could get through inter-library loan, so it was far from the only
one I used.
I got started with Teach yourself C++ in 21 days did not like it
I read also C++ primer plus until chapter 10 but most of it was known
before me so skipped that
I skimmed through it at the library long ago, and wasn't impressed.
I read some parts of C++ Programming Language it went over my head.
That book needs to be read more than once.
I got the book Deitel C++ How to Program from the library it seems fine
but many pages :((
It's a big language...
Accelerated C++ is OK to what extent your programming knowledge is up
IMHO. Maybe it is a bit high level for me even if I did C coding for
numerical problems
I'm not sure what you mean by "high level", I figure you mean that it
makes a lot of assumptions about how quickly you can learn and what
other resources you have. IMHO, the book would work best in concert with
a teacher/tutor who is providing lots of extra examples and projects.
Most people need to be exposed to a topic multiple times before it
starts to sink in...
This became a thread on the books about C++ not the language :((


Ask a vague question and your thread is likely go all over the place.
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
Feb 20 '06 #36

P: n/a
Roland Pibinger wrote:
On Mon, 20 Feb 2006 23:01:25 +0100, Mirek Fidler <cx*@volny.cz> wrote:
Roland Pibinger wrote:
On Mon, 20 Feb 2006 11:28:59 +0100, Mirek Fidler <cx*@volny.cz> wrote:
Well, you not only invented your own library but also your own
language (pick semantics, Moveable, PolyDeepCopyNew, ...), tailored
for your needs and ideas.
Interesting point of view, however the same can be said about STL... If
you are going so solve some issues, you have to introduce some new
features and concepts... (and no, there are of course no changes to the
core language).

When the copy constructor 'picks' the the original then you change
usual language semantics. 'Copy' usually means 'duplicate'.


Same is true for auto_ptr.

Also, in U++ lingo, it is not copy-constructor but pick-constructor.

BTW, future C++ will very likely have similar functionality (r-value
references). Of course, it will change the core language so the solution
can be much more elegant (there will be "move constructor"). Without
being able to change the core language, one does best he can :)
BTW, I have seen you have implemented your own owning container, similar
to U++ Array...

Not quite. My container owns nothing.


Sorry, I reviewed it only briefly and concluded that ptr_vector_owner is
the owning variant (that would seem logical to me - safer and easier to
use - helper classes like that can get tricky).
Owning containers ("smart"
containers) that require transfer of ownership usually run into
trouble.
That is why you definitely need pick (or move) instead of (or alongside
with) copy....
How you are solving deep copy of container full of
polymorphic values? (if you allow them) (this about PolyDeepCopyNew
issue...)

One needs to distinguish between 'value types' and (possibly
polymorphic) 'entity types'. The latter have state and identity and
are usually not copyable. I know, there are situations where you want
to copy (in the meaning of 'duplicate' not 'pick') entity objects. But
that should be an exception, not the rule.


I agree, it is an exception.
I would prohibit copying
for containers of polymorphic contents.


Actually, that is not that bad solution either. In my whole code-base
(more than 20MB of C++), this feature was used just once. However, at
the time of design it seemed like the gap that should be closed.... and
the solution was possible. It is perhaps a good candidate for removal in
the next iteration....

Mirek
Feb 21 '06 #37

This discussion thread is closed

Replies have been disabled for this discussion.