First to learn C if learning C++?

[JiiPee]

One person who is starting to learn C++ asked me: "There is a lot of
discussion about should one first learn C before learning C++".
Stroustrup said definite "no". But I would like to hear what are your
opinions? What is the best way to learn C++? How about learning both
ways at the same time (even like malloc()) but just always to understand
that in real code you never use malloc()?

What I said is that first learn proper C++ way, then after that C... so
the other way around :). But I guess one can learn both at the same time
when just being careful understanding that not using C ways in C++ code.

[Vincenzo Saltridge]

There is nothing to learn, but just using, whatever tool. Also, doing C++
and not knowing C is plain stupid, and should not be allowed.

[Emanuel Berg]

JiiPee <n...@notvalid.com> writes:

> One person who is starting to learn C++ asked me:
> "There is a lot of discussion about should one first
> learn C before learning C++". Stroustrup said
> definite "no".

Maybe he said that as a way of promoting C++ and OO?

No harm can come from knowing C, on the contrary.

Only if you want to specifically do C++ and OO, of
course you shouldn't do C. If you want to learn
programming in general, it is a big plus if you know
C.

> But I would like to hear what are your opinions?
> What is the best way to learn C++?

It is like with everything else. The best way to learn
C++ is to write C++ every day. The more you write
every day, the better. While you do it, think about
what you do. Always learn something new every day (it
can be just a detail) - then continue 365 days stright
every year.

> What I said is that first learn proper C++ way, then
> after that C... so the other way around :). But I
> guess one can learn both at the same time when just
> being careful understanding that not using C ways in
> C++ code.

Just learn as much of everything every day. You don't
have to be that "careful". A good C program is often a
good C++ program with minimal or zero modifications
(tho why do that if it is already good?). Just do it:
be as active as you can with all aspects of the
material - there are no tricks :)

--
underground experts united

[Emanuel Berg]

Vincenzo Saltridge <vinc...@yahoo.com> writes:

> There is nothing to learn, but just using, whatever
> tool. Also, doing C++ and not knowing C is plain
> stupid, and should not be allowed.

It is also all but impossible because if you do it you
will know C by knowing C++...

--
underground experts united

[Emanuel Berg]

JiiPee <n...@notvalid.com> writes:

> One person who is starting to learn C++ asked me:
> "There is a lot of discussion about should one first
> learn C before learning C++". Stroustrup said
> definite "no".

C++ is C plus OO. When C programmers that typically do
Unix systems and stuff express dislike of C++ it is
rather they don't like OO. It goes in the opposite way
as well: "C doesn't even have classes". Well - no.

--
underground experts united

[Vincenzo Saltridge]

Emanuel Berg wrote:

> Vincenzo Saltridge <vinc...@yahoo.com> writes:
>
>> There is nothing to learn, but just using, whatever tool. Also, doing
>> C++ and not knowing C is plain stupid, and should not be allowed.
>
> It is also all but impossible because if you do it you will know C by
> knowing C++...

Not necessary. You don't know how stupid people can be. As for instance
those using Visual Basic. They are really stupid.

[Balwinder S Dheeman]

On 10/11/2014 04:54 PM, JiiPee wrote:
> One person who is starting to learn C++ asked me: "There is a lot of
> discussion about should one first learn C before learning C++".
> Stroustrup said definite "no". But I would like to hear what are your
> opinions? What is the best way to learn C++? How about learning both
> ways at the same time (even like malloc()) but just always to understand
> that in real code you never use malloc()?

It is not mandatory to learn C and, or any other programming languages,
nonetheless learning or having knowledge of any other similar language
will definitely can useful and sometimes confusing for amateur
programmers. See, "The Art of Programming" by Donald E. Knuth
(https://en.wikipedia.org/wiki/The_Art_of_Computer_Programming) and how
he uses a pseudo language for explaining and, or develop a logic of
finding and, or refining solutions.

> What I said is that first learn proper C++ way, then after that C... so
> the other way around :). But I guess one can learn both at the same time
> when just being careful understanding that not using C ways in C++ code.

That's your opinion and, or approach and the opinions may differ and the
same is applicable to all other suggestions. Furthermore, every
individual is an individual indeed including students, amateurs and, or
teachers and all these can/will skin a cat in many ways.

--
Balwinder S "bdheeman" Dheeman (http://bdheeman.BlogSpot.in/)
"Working together, works! The proof is GNU/Linux and F/LOSS Projects;
Do you too voluntarily work on or contribute to making any difference?"

[Emanuel Berg]

Balwinder S Dheeman <bdheeman...@outlook.com>
writes:

> See, "The Art of Programming" by Donald E. Knuth
> (https://en.wikipedia.org/wiki/The_Art_of_Computer_Programming)
> and how he uses a pseudo language for explaining
> and, or develop a logic of finding and, or refining
> solutions.

I had to do "pseudo code" from the book "Introduction
to Algorithms" at the university. My gut feeling then,
and now, is that it is much better to work with a real
language. That language can actually serve as a
'pseudo language' in your mind, if need be. Problem
with pseudo code is that it is difficult to read and
write, if you compare to, for example C. Being
comfortable reading and writing code is a big thing,
perhaps the biggest, to programming. So I would prefer
C to any pseudo language, including for abstract
and/or educational purposes that perhaps can never be
implemented. Also, it is good to know from the start
that programming isn't math, it isn't perfect - what I
think, you shouldn't think of it too much as a
scientist but rather a craftsman...

--
underground experts united

[J. Clarke]

In article <Qr8_v.521092$9I4.1...@fx35.am4>, n...@notvalid.com says...

First, a question. Is the person already a programmer (by that I mean
are they comfortable with a programming language and able to make the
machine do what they want most of the time with it)? If not, they they
are going to be learning programming in addition to learning the
language. If that is the case, then I would say make things as simple
as possible for them and trying to learn two related but different
languages is going to increase their workload considerably.

[J. Clarke]

In article <871tqer...@debian.uxu>, embe...@student.uu.se says...

>
> Balwinder S Dheeman <bdheeman...@outlook.com>
> writes:
>
> > See, "The Art of Programming" by Donald E. Knuth
> > (https://en.wikipedia.org/wiki/The_Art_of_Computer_Programming)
> > and how he uses a pseudo language for explaining
> > and, or develop a logic of finding and, or refining
> > solutions.
>
> I had to do "pseudo code" from the book "Introduction
> to Algorithms" at the university. My gut feeling then,
> and now, is that it is much better to work with a real
> language. That language can actually serve as a
> 'pseudo language' in your mind, if need be. Problem
> with pseudo code is that it is difficult to read and
> write, if you compare to, for example C.

Further, since there is no standard for pseudo code, code that may make
perfect sense to the author may be gibberish to anybody else. I see
this regularly in textbooks, where the first task in successfully
reading the text is to learn how to translate the author's pseudocode.

[Bo Persson]

Why? You can easily learn italian without knowing latin first. It's the
same way with programming languages.

[Rick C. Hodgin]

I would advise learning C first, to understand
the fundamental nature of C structures, the
mechanics of the language, and without all
the rigid clutter so often inhabiting C++ code.

Once a person understands C's mechanics, the
migration to C++ will be trivially understandable.

Best regards,
Rick C. Hodgin

[Bo Persson]

On 2014-10-11 13:41, Emanuel Berg wrote:
> JiiPee <n...@notvalid.com> writes:
>
>> One person who is starting to learn C++ asked me:
>> "There is a lot of discussion about should one first
>> learn C before learning C++". Stroustrup said
>> definite "no".
>

> Just learn as much of everything every day. You don't
> have to be that "careful". A good C program is often a
> good C++ program with minimal or zero modifications

On the contrary, a good C program is often not very good C++ at all.

You miss out on the C++ standard library, massively simpler string
handling, overloaded functions, classes, and different I/O.

That's totally different from the way you write C code.


Bo Persson

[Osmium]

Yes, it has OO. It also has namespaces, templates, a large library (STL),
function overloading, operator overloading, exceptions, inheritance,
virtual functions, pure virtual functions, overriding functions, stuff I
forgot, and stuff I don't even know about,

I believe Stroustrup has his first user written class on about page 220 of
his thousand page book. You need another 800 page book to tell you how to
use the STL library. GUI and the web is extra.

K&R's book on C has only has 272 pages *total*.

This is not an easy question to answer, and about half the answers are
probably going to be wrong. Any advice, including this, IMO, is going to be
of very marginal value. C++ is "right up there" in terms of difficult
programming languages. Think of learning Spanish vs. Mandarin.

[Robert Hutchings]

I think fully-utilized C++ is quite different than C...

[Paavo Helde]

JiiPee <n...@notvalid.com> wrote in news:Qr8_v.521092$9I4.1...@fx35.am4:

IMO, learning proper C++ (strings, STL, exceptions, templates etc) should
come first, to avoid bad habits and wasting time on unneeded C hackery.
Then, to obtain deeper understanding how the things work under the hood,
one should learn some C-specific stuff and assembler + CPU architecture. I
think assembler would be more relevant than C.

OO and writing of custom classes and class hierarchies can be largely
postponed to a later stage, it is a somewhat separate and orthogonal topic,
and not very specific to C++ either (there are lots of OO languages).

Cheers
Paavo

[Wouter van Ooijen]

JiiPee schreef op 11-Oct-14 1:24 PM:

> One person who is starting to learn C++ asked me: "There is a lot of
> discussion about should one first learn C before learning C++".
> Stroustrup said definite "no". But I would like to hear what are your
> opinions? What is the best way to learn C++?

IMO one should first learn (some) procedural programming. This can be
done in the C-like subset of C++, or even in a totally different
language (for instance Python). But if the end-goal is mastering C++ I
would not advice to use plain C, because some C habits (for instance
malloc) would eventually need to be unlearned.

The next step could be OO. I am not sure C++ is the best language to
take the first OO steps (I would ate least consider Python or maybe even
Java). But C++ is one option.

Another next step could be template-based programming. Not
meta-programming, but using templates to get compile time polymorphism.
This requires classes, but not necessary objects.

Wouter van Ooijen

[Wouter van Ooijen]

Emanuel Berg schreef op 11-Oct-14 1:51 PM:

> JiiPee <n...@notvalid.com> writes:
>
>> One person who is starting to learn C++ asked me:
>> "There is a lot of discussion about should one first
>> learn C before learning C++". Stroustrup said
>> definite "no".
>
> C++ is C plus OO.

NOOOOOO

It might have started that way, but C++ is so much more than just C + OO.

just to name a few:
- exceptions
- reference parameters, default parameters, overloading
- better type system (new/delete, templated casts, bool, enum class, ... )
- constexpr
- templates

Wouter van Ooijen

[JiiPee]

On 11/10/2014 16:15, Robert Hutchings wrote:
>
>>
>>
>> Bo Persson
>>
>>
> I think fully-utilized C++ is quite different than C...

yes. On videos the top C++ people they always say the code should be as
short as possible and simple. Using C++ and classes does that. For
example for-loop becomes very short some times... with C you cannot do
such things.

[JiiPee]

But how do you manage that after C the student is not using wrong C
tecnniques when doing C++ later? C is in their mind, so they start
easily coding like that , isnt it?

[JiiPee]

On 11/10/2014 16:46, Paavo Helde wrote:
> JiiPee <n...@notvalid.com> wrote in news:Qr8_v.521092$9I4.1...@fx35.am4:
>
>> One person who is starting to learn C++ asked me: "There is a lot of
>> discussion about should one first learn C before learning C++".
>> Stroustrup said definite "no". But I would like to hear what are your
>> opinions? What is the best way to learn C++? How about learning both
>> ways at the same time (even like malloc()) but just always to understand
>> that in real code you never use malloc()?
>>
>> What I said is that first learn proper C++ way, then after that C... so
>> the other way around :). But I guess one can learn both at the same time
>> when just being careful understanding that not using C ways in C++ code.
> IMO, learning proper C++ (strings, STL, exceptions, templates etc) should
> come first, to avoid bad habits and wasting time on unneeded C hackery.
> Then, to obtain deeper understanding how the things work under the hood,
> one should learn some C-specific stuff and assembler + CPU architecture. I
> think assembler would be more relevant than C.

Thats how I saw it as well... because that makes sure that at least they
will do good programming first. And use wrong ways to do things.

>
> OO and writing of custom classes and class hierarchies can be largely
> postponed to a later stage, it is a somewhat separate and orthogonal topic,
> and not very specific to C++ either (there are lots of OO languages).

good point

>
> Cheers
> Paavo

[Ben Bacarisse]

And (though it's maybe a smaller set) C has things that C++ does not:

- different rules for const
- compound literals
- designated initialisers
- different implementation of complex numbers
- different implementation of threads
- variable length and variably modified array types
- _Generic expressions

and no doubt others...

--
Ben.

[Rick C. Hodgin]

JiiPee wrote:
> But how do you manage that after C the
> student is not using wrong C tecnniques when
> doing C++ later? C is in their mind, so they
> start easily coding like that , isnt it?

It is "C"++. There is no real requirement to code
using new features and abilities in C++. And I
would argue that maintaining C++ code is often
far more difficult and obtuse compared with
coding some, if not many, parts in std C. The
only true advantages I've seen in C++ are the
class, exceptions, and some std featutes, but all
of those can be simulated in C (in variois ways)
with a small amount of up front work.

I look at some of the C++ questions on this group,
and I think to myself ... "Whew! Seriously??"

There are other common alternatives for that
very reason ... Objective-C, C#, and my own
intended RDC. C++ is sometimes hideous, rarely
elegant, and requires far more complex compilers
and libraries to support its execution. In addition,
it is often slightly slower in execution, making it
largely undesirable in my experience.

I find C by itself to be very close to being elegant,
only lacking a few features to be very elegant. I
pray to add those features to my RDC. But, we'll
see what the Lord's plans are for my life.

[JiiPee]

are you a christian?

[Rick C. Hodgin]

I am.

I am a C.
I am a C-H.
I am a C-H-R-I-S-T-I-A-N.
And I have C-H-R-I-S-T in my H-E-A-R-T and I will
L-I-V-E
E-T-E-R-N-A-L-L-Y.

:-)

https://www.youtube.com/watch?v=yrNM-B_gg4A

[Emanuel Berg]

"J. Clarke" <jclark...@cox.net> writes:

> First, a question. Is the person already a
> programmer (by that I mean are they comfortable with
> a programming language and able to make the machine
> do what they want most of the time with it)? If not,
> they they are going to be learning programming in
> addition to learning the language. If that is the
> case, then I would say make things as simple as
> possible for them and trying to learn two related
> but different languages is going to increase their
> workload considerably.

Good point. In that case, I'd say C is much better
than C++. Because with C++ the newcomer will be all
confused with OO and classes and constructors and all.

As a beginner programmer you don't need that, you want
to assign values to variables and echo them on the
screen, and such. Not that C++ can't do that... of
course it can, looking very much like C.

So you can either do it C or do it in pretty "base
C++" (not bothering about advanced OO stuff until
later - or never...).

--
underground experts united

[Emanuel Berg]

"J. Clarke" <jclark...@cox.net> writes:

> Further, since there is no standard for pseudo code,
> code that may make perfect sense to the author may
> be gibberish to anybody else. I see this regularly
> in textbooks, where the first task in successfully
> reading the text is to learn how to translate the
> author's pseudocode.

Yeah, why should anyone have to do that? Most
programmers are kind of good at reading C or
C-like-syntax, and not just C or C++ programmers.
(There are lots of places to pick that up, besides
those languages.) I think such C should be used as the
new pseudo code: it'll make it easier for everyone
involved.

--
underground experts united

[JiiPee]

Can you give an C code example where this would be better with C than C++?

For example with C++ you assign a value to a string:

string str;
str = "Hello";

But with C its:
char str[10];
strcpy(str, "Hello");

here the C++ version looks simpler for a beginner, isnt it? Why would
you say its easier here for a beginner the C-way?

With C++ they can faster go to other things in programming and still
learning the language.

So I think with C++ its easier for them to learn programming and faster.
Plus they do not need to worry about deleting the memories etc which
must be done with C if using dynamic allocation.

[Ian Collins]

Emanuel Berg wrote:
> "J. Clarke" <jclark...@cox.net> writes:
>
>> First, a question. Is the person already a
>> programmer (by that I mean are they comfortable with
>> a programming language and able to make the machine
>> do what they want most of the time with it)? If not,
>> they they are going to be learning programming in
>> addition to learning the language. If that is the
>> case, then I would say make things as simple as
>> possible for them and trying to learn two related
>> but different languages is going to increase their
>> workload considerably.
>
> Good point. In that case, I'd say C is much better
> than C++. Because with C++ the newcomer will be all
> confused with OO and classes and constructors and all.

Have you ever read Accelerated C++ by Koenig and Moo? It teaches C++
without assuming any knowledge of C or OO. You don't need to learn OO
to learn C++.

--
Ian Collins

[JiiPee]

you mean also that using std::string is not doing OO?

[Ian Collins]

Yes.

--
Ian Collins

[JiiPee]

ok ye you can use string without much talking about OO. But there will
be a bit of OO things still there, like:

str.size();

so they have to understand that str is an object and it can call its
member functions, but yes its not too much OO there.

[David Harmon]

On Sat, 11 Oct 2014 23:33:22 +0100 in comp.lang.c++, JiiPee
<n...@notvalid.com> wrote,

>Can you give an C code example where this would be better with C than C++?
>
>For example with C++ you assign a value to a string:
>
>string str;
>str = "Hello";
>
>But with C its:
>char str[10];
>strcpy(str, "Hello");

What is that magic number 10 doing there? It's not the length of
"Hello" so presumably that array will be used to hold other strings
at other times. How do we know that none of those strings will ever
be more than nine characters? How do we know that the array needed
to be more than six bytes in the first place?

I think the "simple" version either already has a bug, or will have
as soon as that "beginner" tries to do anything with it.

[Melzzzzz]

On Sat, 11 Oct 2014 23:33:22 +0100

JiiPee <n...@notvalid.com> wrote:

> Can you give an C code example where this would be better with C than
> C++?
>
> For example with C++ you assign a value to a string:
>
> string str;
> str = "Hello";
>
> But with C its:
> char str[10];
> strcpy(str, "Hello");
>
> here the C++ version looks simpler for a beginner, isnt it? Why would
> you say its easier here for a beginner the C-way?

C is not for beginners. He didn't count that one don't have
to write classes in order to use them ;)
What about Java? In Java even "hello world" requires writing class.
And Java is supposed to be beginner friendly ...

>
> With C++ they can faster go to other things in programming and still
> learning the language.

Exactly.



--
Manjaro all the way!
http://manjaro.org/

[Balwinder S Dheeman]

On 10/11/2014 06:43 PM, J. Clarke wrote:
> In article <Qr8_v.521092$9I4.1...@fx35.am4>, n...@notvalid.com says...

>>
>> One person who is starting to learn C++ asked me: "There is a lot of
>> discussion about should one first learn C before learning C++".

>> Stroustrup said definite "no". But I would like to hear what are your
>> opinions? What is the best way to learn C++? How about learning both
>> ways at the same time (even like malloc()) but just always to understand
>> that in real code you never use malloc()?
>>
>> What I said is that first learn proper C++ way, then after that C... so
>> the other way around :). But I guess one can learn both at the same time
>> when just being careful understanding that not using C ways in C++ code.
>

> First, a question. Is the person already a programmer (by that I mean
> are they comfortable with a programming language and able to make the
> machine do what they want most of the time with it)? If not, they they
> are going to be learning programming in addition to learning the
> language. If that is the case, then I would say make things as simple
> as possible for them and trying to learn two related but different
> languages is going to increase their workload considerably.

+1

--
Balwinder S "bdheeman" Dheeman (http://bdheeman.BlogSpot.in/)
"Working together, works! The proof is GNU/Linux and F/LOSS Projects;
Do you too voluntarily work on or contribute to making any difference?"

[Balwinder S Dheeman]

[woodb...@gmail.com]

On Saturday, October 11, 2014 11:28:20 PM UTC-5, Balwinder S Dheeman wrote:
> +1
>
> --
>
> Balwinder S "bdheeman" Dheeman (http://bdheeman.BlogSpot.in/)
>
> "Working together, works! The proof is GNU/Linux and F/LOSS Projects;
>

I'm more impressed by BSD these days than Linux. These guys

http://bsdnow.tv

have some interesting material.

> Do you too voluntarily work on or contribute to making any difference?"

I have a combination of open and closed source. Some of
the open source is available here:

http://webEbenezer.net/build_integration.html


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Bo Persson]

There is no OO going on here, just some "C with classes". No new or
delete, no inheritance, no virtual functions. It just works.

Telling a new student that std::string holds a string, and that you can
get its size by calling str.size(), will surprise nobody.

Compare that to the "easy to understand" C string functions, and try to
explain the incantation

char* b = malloc(strlen(a) + 1);


Bo Persson

[Emanuel Berg]

Bo Persson <b...@gmb.dk> writes:

>> There is nothing to learn, but just using, whatever
>> tool. Also, doing C++ and not knowing C is plain
>> stupid, and should not be allowed.
>
> Why? You can easily learn italian without knowing
> latin first. It's the same way with programming
> languages.

In general: yes, but in the case of C++ and C it is
impossible from a practical perspective to learn C++
without learning C as well as C is a huge subset of
C++. (At least formally so, in reality it is probably
more correct to say that C++ is an extention of C.)

--
underground experts united

[Robert Hutchings]

I am following this discussion with keen interest. So, if one reads
"Accelerated C++" by Koenig and Moo, they are learning C++ right from
the start. Are we saying that this is the *wrong* way to learn C++?

[Emanuel Berg]

Bo Persson <b...@gmb.dk> writes:

> On the contrary, a good C program is often not very
> good C++ at all.
>
> You miss out on the C++ standard library, massively
> simpler string handling, overloaded functions,
> classes, and different I/O.
>
> That's totally different from the way you write C
> code.

Yes, I mean: if the C program was good you don't need
the C++ stuff to begin with. But if you want to you
can compile it with g++ instead of gcc and you got a
C++ program that does the same thing, probably just as
good. (But again, why do that?)

You often C the combination C/C++ in literature, ads,
and so on. Well, there *is* a "C/C++" and that is C++.
Other than that C and C++ are two different languages
with different syntax, tools, and (as you mention)
libraries. Tho the biggest difference by far is the
C++ focus on OO.

--
underground experts united

[Emanuel Berg]

JiiPee <n...@notvalid.com> writes:

> yes. On videos the top C++ people they always say
> the code should be as short as possible and simple.
> Using C++ and classes does that.

OO and programming with classes does not make the code
"shorter".

OO makes programs "simpler" only when the purpose of
the program lend itself naturally to modelling: like
simulation, games, certain abstract situations with
clear building blocks (e.g., a hierarchical
scheduler), and so on. OO is not "always better".

Also: Short code is not always an advantage. Most
often it is because it is fast to read and write. But
sometimes short code gets really cryptical and
difficult to maintain. Short code doesn't imply
execution speed. It can actually be the other way
around as there isn't any optimization of obscure
hacks.

> For example for-loop becomes very short some
> times... with C you cannot do such things.

Yes you can: for-loop is the same in C and C++ and
several other languages as well.

--
underground experts united

[Bo Persson]

On 2014-10-12 16:56, Emanuel Berg wrote:
> JiiPee <n...@notvalid.com> writes:
>
>> yes. On videos the top C++ people they always say
>> the code should be as short as possible and simple.
>> Using C++ and classes does that.
>
> OO and programming with classes does not make the code
> "shorter".
>
> OO makes programs "simpler" only when the purpose of
> the program lend itself naturally to modelling: like
> simulation, games, certain abstract situations with
> clear building blocks (e.g., a hierarchical
> scheduler), and so on. OO is not "always better".
>
> Also: Short code is not always an advantage. Most
> often it is because it is fast to read and write. But
> sometimes short code gets really cryptical and
> difficult to maintain. Short code doesn't imply
> execution speed. It can actually be the other way
> around as there isn't any optimization of obscure
> hacks.

So lets's compare. :-)

std::string a = "Sample string";
std::string b = a;

or

char a[] = "Sample string";

char* b = malloc(strlen(a) + 1);

strcpy(b, a);
/* and sometimes later: */
free(b);

>
>> For example for-loop becomes very short some
>> times... with C you cannot do such things.
>
> Yes you can: for-loop is the same in C and C++ and
> several other languages as well.
>

Newer C++ has better for loops as well, like:

for (auto x : v)
std::cout << x;

will output all elements in the sequence v, like a vector, or a string
or an array, or ...


Bo Persson

[Jorgen Grahn]

On Sun, 2014-10-12, Emanuel Berg wrote:
> Bo Persson <b...@gmb.dk> writes:
>
>>> There is nothing to learn, but just using, whatever
>>> tool. Also, doing C++ and not knowing C is plain
>>> stupid, and should not be allowed.
>>
>> Why? You can easily learn italian without knowing
>> latin first. It's the same way with programming
>> languages.
>
> In general: yes, but in the case of C++ and C it is
> impossible from a practical perspective to learn C++
> without learning C as well as C is a huge subset of
> C++.

It is, but a lot of that subset is of no use in normal C++
programming. (Perhaps more the idioms than the concrete language
constructs: you will use most C language constructs in your C++
programs over the years, but not in the way a C programmer would.)

So, a lot like latin and italian.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[JiiPee]

On 12/10/2014 15:56, Emanuel Berg wrote:
> JiiPee <n...@notvalid.com> writes:
>
>> yes. On videos the top C++ people they always say
>> the code should be as short as possible and simple.
>> Using C++ and classes does that.
> OO and programming with classes does not make the code
> "shorter".
>
> OO makes programs "simpler" only when the purpose of
> the program lend itself naturally to modelling: like
> simulation, games, certain abstract situations with
> clear building blocks (e.g., a hierarchical
> scheduler), and so on. OO is not "always better".


>
> Also: Short code is not always an advantage. Most
> often it is because it is fast to read and write. But
> sometimes short code gets really cryptical and
> difficult to maintain. Short code doesn't imply
> execution speed. It can actually be the other way
> around as there isn't any optimization of obscure
> hacks.

many times there is no difference in assembly code though. For example
c-loop:

int i;
for(i=0; i<size; ++i)

can be done in C++:
for(auto i : vec)

clearly c++ version is shorter and more elegant here. Its also easier to
see what happens in the looop. So its better readable. plus the assembly
code is the same in both, so they are equally fast

Or would you say the C code here is better? In what way?

>
>> For example for-loop becomes very short some
>> times... with C you cannot do such things.
> Yes you can: for-loop is the same in C and C++ and
> several other languages as well.

you can do:

for(auto i : vec)

in C (and lets imagine that the vector item type is very long, thus auto
makes the type short)?

>

[Jorgen Grahn]

On Sat, 2014-10-11, Emanuel Berg wrote:
> JiiPee <n...@notvalid.com> writes:
>

>> One person who is starting to learn C++ asked me:
>> "There is a lot of discussion about should one first
>> learn C before learning C++". Stroustrup said
>> definite "no".
>

> Maybe he said that as a way of promoting C++ and OO?

The context is that someone wants to learn C++ -- surely no promotion
is needed?

I think the real background to that response is too many people have
come to C++ over the years with a C background and written terrible
code, making C++ (not C) look bad.

> No harm can come from knowing C, on the contrary.
>
> Only if you want to specifically do C++ and OO, of
> course you shouldn't do C.

That's the second time in three paragraphs you mention object
orientation -- why? It was popular in the 1990s, but today noone
forces you to do it, not in C++ at least. Personally I live happily
without it[1].

[snip practical tips which I agree with]

>> What I said is that first learn proper C++ way, then
>> after that C... so the other way around :). But I
>> guess one can learn both at the same time when just
>> being careful understanding that not using C ways in
>> C++ code.
>

> Just learn as much of everything every day. You don't
> have to be that "careful". A good C program is often a
> good C++ program with minimal or zero modifications
> (tho why do that if it is already good?).

Strongly disagree. Good C++ programs use RAII, type safety,
exceptions and the standard library: good C programs have to make do
with arrays or home-grown linked lists, and manual memory management.

/Jorgen

[1] I find abstract datatypes useful in every program, but rarely see
a need for run-time polymorphism, abstract interfaces, design
patterns and so on. YMMV.

[JiiPee]

yes, this would be pain for me... "lazy" programmer as I am. I really
don't like to remember doing free() at the end. I want it to be
automatic. Although maybe C-people can show how to aumatizice this?? I
guess C programmers use some helper function to do these? Doing like
that would be pain for me at least... I do not like to write code if not
necessary.

>
>
>>
>>> For example for-loop becomes very short some
>>> times... with C you cannot do such things.
>>
>> Yes you can: for-loop is the same in C and C++ and
>> several other languages as well.
>>
>
> Newer C++ has better for loops as well, like:
>
> for (auto x : v)
> std::cout << x;
>
> will output all elements in the sequence v, like a vector, or a string
> or an array, or ...
>
>

Yeps. This is a really good feature imo after learning to use it. It
takes some time to get used to this new syntax, but after familiar with
it, its very good and natural and no going back.

[Paavo Helde]

Emanuel Berg <embe...@student.uu.se> wrote in
news:87y4sll...@debian.uxu:

> Bo Persson <b...@gmb.dk> writes:
>
>>> There is nothing to learn, but just using, whatever
>>> tool. Also, doing C++ and not knowing C is plain
>>> stupid, and should not be allowed.
>>
>> Why? You can easily learn italian without knowing
>> latin first. It's the same way with programming
>> languages.
>
> In general: yes, but in the case of C++ and C it is
> impossible from a practical perspective to learn C++
> without learning C as well as C is a huge subset of
> C++.

But it is not a proper subset, and neither is it "huge". There are lots
of things in C which cannot be used or are not needed in C++ (from the
top of my head: calling undeclared functions (default types!), _Bool,
restrict, C-style casts, longjmp(), strcat() et al, malloc() et al, qsort
(), printf() et al, tables of function pointers, naming conventions (like
encoding library name or parameter types in the function name), static
free functions, most of preprocessor, most of pointer arithmetics and
sizeof, array syntax (esp tricky when passing to/from functions), error
reporting by error codes, etc., tedious cleanup in error paths, etc.).
The 'const' behavior is slightly different so some relearning is needed
if the C const is learned too well. The idiomatic use of for() loops in
C++ has variable declarations inside for(), which is not valid C syntax,
and if()/while() also support similar syntax in C++, so one would need to
learn the usage of basic looping constructs twice, first with unneeded
restrictions. Placement of variable declarations inside function also has
unnessecary and harmful restrictions in C, so learning the C way first is
actually harmful when learning C++.

To be honest, what's left in common is quite a small subset, basically
built-in datatypes and conversions plus general syntax of declaring and
defining functions. Yes, you will need these basics to learn C++, but
they do not constitute a large part of either C or C++.

Cheers
Paavo

[Richard Damon]

In learning C++, you will learn much of the syntax of C (at least C90),
but you might not know which parts of the syntax you learned are C and
which parts are C++ only.

What you are less apt to learn is the library. While basically all of
the C library is available in C++, these well might not be covered in a
basic course.

[Emanuel Berg]

"Osmium" <r124c...@comcast.net> writes:

> Yes, it has OO. It also has namespaces, templates, a
> large library (STL), function overloading, operator
> overloading, exceptions, inheritance, virtual
> functions, pure virtual functions, overriding
> functions, stuff I forgot, and stuff I don't even
> know about,

A lot of the stuff you mention (e.g, inheritance,
overloading) I include when I say OO.

C also has a library: the standard C library :)

> I believe Stroustrup has his first user written
> class on about page 220 of his thousand page book.
> You need another 800 page book to tell you how to
> use the STL library. GUI and the web is extra.
>
> K&R's book on C has only has 272 pages *total*.

I don't think counting the pages of books as a method
has any value to examine complexity but there is no
doubt in my mind that C++ is more difficult to master
- it has many more concepts than C and those are not
always implemented the way you would first think.

> This is not an easy question to answer, and about
> half the answers are probably going to be wrong. Any
> advice, including this, IMO, is going to be of very
> marginal value. C++ is "right up there" in terms of
> difficult programming languages. Think of learning
> Spanish vs. Mandarin.

Natural languages and not a good metaphor for
programming languages. If you sucked at Spanish at
school you might still be a great programmer. C++ is
not as straightforward as C but it is very possible to
do with time and effort, besides you don't need to use
all that fancy OO stuff if you don't want to.
Inheritance is a good example that is a big part of OO
(at least if you read books about it) but i real
programs usually it just makes things complicated and
difficult to overview. C++ isn't as simple and clean
as C but that doesn't matter you can't use C++, can't
use OO in a clean and simple way.

--
underground experts united

[David Brown]

str.size() is nothing more than syntactic sugar for size(&str) - it is
not object oriented programming. You could get the same effect in C by
adding nothing more than function overloading.

You can get far in programming with C++ without doing any object
oriented programming (though you will probably be using libraries that
use OO behind the scenes).

[Paavo Helde]

JiiPee <n...@notvalid.com> wrote in news:j0y_v.328690$wn1.2...@fx18.am4:

> On 12/10/2014 16:31, Bo Persson wrote:
>> char a[] = "Sample string";
>> char* b = malloc(strlen(a) + 1);
>> strcpy(b, a);
>> /* and sometimes later: */
>> free(b);
>
> yes, this would be pain for me... "lazy" programmer as I am. I really
> don't like to remember doing free() at the end. I want it to be
> automatic. Although maybe C-people can show how to aumatizice this?? I
> guess C programmers use some helper function to do these?

No, C people do not believe in "automation" AFAIK. I have understood they
think that this forces the people to be alert and pay attention to details.
The sad part is that when I have spent all my alertness to boring details
there is little left for doing something actually new.

[Emanuel Berg]

Paavo Helde <myfir...@osa.pri.ee> writes:

> IMO, learning proper C++ (strings, STL, exceptions,
> templates etc) should come first, to avoid bad
> habits and wasting time on unneeded C hackery.

Well, yeah, but are you sure the order you learn
things will have that big an influence? It is possible
to write very disciplined C.

With C++ I think it is possible to get lost with all
the stuff as a beginner. You might also be mislead by
all the OO hype thinking it is the one and only way
(instead of a model to help us think and be better
programmers, just as the equally helpful functional
programming model/paradigm).

Thing is with C there aren't nearly as much stuff and
a lot less paradigmic hysteria (now I'm talking like
books, tutorial, etc.). It is more like Lego: here are
a bunch of building blocks that a kid can understand,
just put it together any way you like.

But don't let me scare anyone off: there are a lot of
kids who did C++ :)

> Then, to obtain deeper understanding how the things
> work under the hood, one should learn some
> C-specific stuff and assembler + CPU architecture. I
> think assembler would be more relevant than C.

Well, that depends.

If you by "under the hood" mean architecture and/or
hardware (registers, caches, the clock, etc.) - then
yes, it is better to put your energy on assembler than
C. If you already know C++, and not C - again, I think
that is a contradiction in terms but OK - then it
might also be more interesting to take a shot on
assembler, because it will involve a lot more new
stuff and open new doors as the shift is so much more
radical than C++ -> C.

But "under the hood" can also mean the OS. And for
OS:s, there is no sweeter language than C, compiling
the end result into a monolithic a.out kernel.

--
underground experts united

[Paavo Helde]

Emanuel Berg <embe...@student.uu.se> wrote in

news:87iojps...@debian.uxu:

> Paavo Helde <myfir...@osa.pri.ee> writes:
>
>> IMO, learning proper C++ (strings, STL, exceptions,
>> templates etc) should come first, to avoid bad
>> habits and wasting time on unneeded C hackery.
>
> Well, yeah, but are you sure the order you learn
> things will have that big an influence? It is possible
> to write very disciplined C.

Sure, but this does not help much if your only goal is to learn C++.
Learning to do really disciplined C is pretty hard and most of the obtained
knowledge is useless in C++.

> With C++ I think it is possible to get lost with all
> the stuff as a beginner. You might also be mislead by
> all the OO hype thinking it is the one and only way

What OO hype? You sound so much like last century ;-) After the OO hype we
have had template metaprogramming hype in the last decade, not quite sure
what's the hype of this decade.

Cheers
Paavo

[JiiPee]

Me also I want to do new things and not use time making code which is
not necessary. I want the future of C++ be just like that... more and
more simple and short. There is nothing wrong in that.. just keep the
old C++ also so one can do the pointers etc I needed/wants.

[Ian Collins]

Emanuel Berg wrote:
> Paavo Helde <myfir...@osa.pri.ee> writes:
>
>> IMO, learning proper C++ (strings, STL, exceptions,
>> templates etc) should come first, to avoid bad
>> habits and wasting time on unneeded C hackery.
>
> Well, yeah, but are you sure the order you learn
> things will have that big an influence? It is possible
> to write very disciplined C.

Very disciplined C can be very poor (or at best not idiomatic) C++.

> With C++ I think it is possible to get lost with all
> the stuff as a beginner. You might also be mislead by
> all the OO hype thinking it is the one and only way
> (instead of a model to help us think and be better
> programmers, just as the equally helpful functional
> programming model/paradigm).

Repeating my earlier question, have you read Accelerated C++? It
doesn't introduce OO early on. I think you are fixated on C++ being a
strictly OO language, which is isn't.

--
Ian Collins

[woodb...@gmail.com]

On Sunday, October 12, 2014 5:12:45 PM UTC-5, Paavo Helde wrote:
>
> No, C people do not believe in "automation" AFAIK. I have understood they
> think that this forces the people to be alert and pay attention to details.
> The sad part is that when I have spent all my alertness to boring details
> there is little left for doing something actually new.

I read about a second case of Ebola in Dallas today.
A health care worker may have gotten Ebola because
she didn't follow the rules as far as taking her
protective equipment off. Maybe they should take
a shower after they take the equipment off. An ounce
of prevention ...

[Emanuel Berg]

Wouter van Ooijen <wou...@voti.nl> writes:

> But if the end-goal is mastering C++ I would not
> advice to use plain C, because some C habits (for
> instance malloc) would eventually need to be
> unlearned.

You shouldn't be afraid of that. Learning doesn't make
learning more difficult. On the contrary. Learn as
much as you can, every day, of everything! C, C++,
Java, I mean not Java exactly but..., Lisp, assembler,
just do it as much as you can.

--
underground experts united

[Emanuel Berg]

Wouter van Ooijen <wou...@voti.nl> writes:

>> C++ is C plus OO.
>
> NOOOOOO
>
> It might have started that way, but C++ is so much
> more than just C + OO.
>
> just to name a few: - exceptions - reference
> parameters, default parameters, overloading - better
> type system (new/delete, templated casts, bool, enum
> class, ... ) - constexpr - templates

Again, a lot of those things are to my mind OO. But I
don't have a problem saying C++ is C + OO + even more.
Why shouldn't it be? It is logical.

--
underground experts united

[Balwinder S Dheeman]

On 10/12/2014 11:40 AM, woodb...@gmail.com wrote:
> On Saturday, October 11, 2014 11:28:20 PM UTC-5, Balwinder S Dheeman wrote:
>> +1
>>
>> --
>>
>> Balwinder S "bdheeman" Dheeman (http://bdheeman.BlogSpot.in/)
>>
>> "Working together, works! The proof is GNU/Linux and F/LOSS Projects;
>>
>
> I'm more impressed by BSD these days than Linux. These guys
>
> http://bsdnow.tv
>
> have some interesting material.

I also deploy and, or contribute to Free/Net/DFlyBSD; these indeed
sometimes are better alternatives to Linux based distributions ;)

Please do check the *Plan 9 From Bell Labs* and *9 Front* as well; see:
https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
https://code.google.com/p/plan9front/

>> Do you too voluntarily work on or contribute to making any difference?"
>
> I have a combination of open and closed source.

There no harm in doing so; I, however, prefer, write and use Free and,
or Open Source Software only except for the Flash, Google Talk/Hangouts
plugins and DropBox.

I agree that, we can (Even I do) contribute to closed source software
projects as well, but by reporting bugs and, or feature requests ...

--
Balwinder S "bdheeman" Dheeman (http://bdheeman.BlogSpot.in/)
"Working together, works! The proof is GNU/Linux and F/LOSS Projects;

[Emanuel Berg]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:

> It is "C"++. There is no real requirement to code
> using new features and abilities in C++. And I would
> argue that maintaining C++ code is often far more
> difficult and obtuse compared with coding some, if
> not many, parts in std C. The only true advantages
> I've seen in C++ are the class, exceptions, and some
> std featutes

Indeed.

> but all of those can be simulated in C (in variois
> ways) with a small amount of up front work.

I'd say it'd be pretty difficult to implement a system
in C that corresponds to the class in C++. And why do
that? When you want classes and OO, isn't the most
natural idea just to use C++?

--
underground experts united

[Emanuel Berg]

JiiPee <n...@notvalid.com> writes:

> Can you give an C code example where this would be
> better with C than C++?

No. Because what you do in C, you can do in C++.

> For example with C++ you assign a value to a string:
>
> string str; str = "Hello";
>
> But with C its: char str[10]; strcpy(str, "Hello");

It doesn't have to be.

char str[] = "Hello";

> here the C++ version looks simpler for a beginner,
> isnt it? Why would you say its easier here for a
> beginner the C-way?

Strings might be easier in C++ than in C. But there is
a lot more to C++ that makes it confusing. Most of
that relates to the OO stuff, because mostly the OO
stuff is what separates C++ from C.

> With C++ they can faster go to other things in
> programming and still learning the language.

No, C is as fast to learn as C++. Probably it is
faster as there is less building blocks to master so
there will be less confusion in the early stages. Also
the focus on OO may be an obstacle when you want to
learn a language, not a programming paradigm. C is
more straightforward than C++ but C++ is very possible
to master the basis of fast, as well.

> Plus they do not need to worry about deleting the
> memories etc which must be done with C if using
> dynamic allocation.

They have to worry about memory in C++ as well. If you
want to not worry about the memory there are other
languages that completely hides this, if that's what
you want.

--
underground experts united

[Ian Collins]

Emanuel Berg wrote:

>
> Strings might be easier in C++ than in C. But there is
> a lot more to C++ that makes it confusing. Most of
> that relates to the OO stuff, because mostly the OO
> stuff is what separates C++ from C.

No, it isn't.

>> With C++ they can faster go to other things in
>> programming and still learning the language.
>
> No, C is as fast to learn as C++. Probably it is
> faster as there is less building blocks to master so
> there will be less confusion in the early stages. Also
> the focus on OO may be an obstacle when you want to
> learn a language, not a programming paradigm.

What focus on OO? The one in you mind?

--
Ian Collins

[Rick C. Hodgin]

Emanuel Berg wrote:
> I'd say it'd be pretty difficult to implement a
> system in C that corresponds to the class in
> C++. And why do that? When you want classes
> and OO, isn't the most natural idea just to use
> C++?

The only real way I could imagine is with either
naming conventions or through named macros.
I agree about using C++ instead of trying to do
that in C.

Best regards,
Rick C. Hodgin

[Emanuel Berg]

Ian Collins <ian-...@hotmail.com> writes:

> Have you ever read Accelerated C++ by Koenig and
> Moo? It teaches C++ without assuming any knowledge
> of C or OO. You don't need to learn OO to learn C++.

I haven't read that book. But I absolutely agree you
don't need any prior knowledge of C or OO to learn
C++. It is good tho, for C++ and in its own right. It
is also possible to learn C and OO by way of learning
C++. I actually don't think the order by which you do
things are that important. The most important thing is
time and effort - the level of dedication and passion
you put into it... Make it work, by outworking the
opposition. Don't worry about it!

--
underground experts united

[Emanuel Berg]

JiiPee <n...@notvalid.com> writes:

> str.size();
>
> so they have to understand that str is an object and
> it can call its member functions, but yes its not
> too much OO there.

That's OO. OO is to encapsulate data and the
algorithms that modify that data, in objects. It
doesn't have to be ten levels of different-degree
inheritance to be "real OO". Actually that is not
common among the professionals, only the books and the
university people love to talk about it. The simple
OO as you just exemplified is the OO that works.

--
underground experts united

[ojack...@gmail.com]

On 2014-10-12, Balwinder S Dheeman <bdheeman...@outlook.com> wrote:
> +1

Yo, Ball Winder,

This "+1" bullshit has got to stop. This is usenet, not Facefuck. We
don't grunt our approval like fucking retards.

[Paavo Helde]

Emanuel Berg <embe...@student.uu.se> wrote in

news:874mv8h...@debian.uxu:

Well, this "simple OO" is present and heavily used already in C:

FILE* f = fopen(...);
fprintf(f, ...);
fclose(f);

Here, you have created an object which encapsulates a bunch of data
behind the scenes, and you manipulate it via a set of dedicated
functions. This is not limited to FILE, in C it is common to have structs
which are accessed only via dedicated functions. Yes, there is a
difference in how this design is enforced (by the compiler or by the
programmer himself), but the end result is pretty much the same.

Now if you talked about RAII and destructors, then this is really
something essential for C++. But I would not call this OO either. We have
different names for different things in order to tell them apart, if you
lump everything in the same cattle and call it OO, it does not help
anybody.

Cheers
Paavo

[Chris Vine]

Simple OO is trivial in C. structs are your 'class'; functions which
take a pointer to the struct as their first argument are your
non-virtual 'methods'; and virtual methods are function pointer members
of the struct. Simple inheritance can be implemented by having the
"parent" struct as the first member of the "child" struct and casting
between them, because C guarantees that the address of a struct and of
its first member is the same (as does C++ with respect to PODs) and the
cast is permitted by the strict aliasing rule (as it is also in C++).

There are very few C programs or libraries which do not include some
element of this. What is missing is data hiding: so maintaining data
encapsulation is a matter of programmer discipline rather than language
enforcement.

Your hypothesis that new programmers find data encapsulation and
object orientation in the C++ style difficult to comprehend at first,
so they need to learn C initially, is I think nonsense. The principles
behind objects map naturally to people's experience of the world. I
suspect that is one of the reasons why newcomers find python relatively
easy to learn, which many teaching institutions use as a first language.

And complex object heirarchies are so 1990s. The emphasis nowadays is
on flat heirarchies and minimisation of coupling. There are some
areas, such as GUIs, where relatively deep inheritance heirarchies
can naturally express the problem domain, but try teaching a new
programmer a C GUI as opposed to a C++ GUI and see which they prefer -
it won't be the C one as you seem to suppose.

The things that newcomers can at first find difficult are pointers
(which are a C primitive) and templates when you get beyond the
"cookie cutter" stage.

Chris

[Balwinder S Dheeman]

On 10/13/2014 06:24 AM, Emanuel Berg wrote:
> JiiPee <n...@notvalid.com> writes:
>
>> Can you give an C code example where this would be
>> better with C than C++?
>
> No. Because what you do in C, you can do in C++.
>
>> For example with C++ you assign a value to a string:
>>
>> string str; str = "Hello";
>>
>> But with C its: char str[10]; strcpy(str, "Hello");
>
> It doesn't have to be.
>
> char str[] = "Hello";
>
>> here the C++ version looks simpler for a beginner,
>> isnt it? Why would you say its easier here for a
>> beginner the C-way?
>
> Strings might be easier in C++ than in C. But there is
> a lot more to C++ that makes it confusing. Most of
> that relates to the OO stuff, because mostly the OO
> stuff is what separates C++ from C.

Please note that there are many languages which use C like syntax and
easier to learn than C, but none professed to learn any of them before
you learn C?

>> With C++ they can faster go to other things in
>> programming and still learning the language.
>
> No, C is as fast to learn as C++. Probably it is
> faster as there is less building blocks to master so
> there will be less confusion in the early stages. Also
> the focus on OO may be an obstacle when you want to
> learn a language, not a programming paradigm. C is
> more straightforward than C++ but C++ is very possible
> to master the basis of fast, as well.
>
>> Plus they do not need to worry about deleting the
>> memories etc which must be done with C if using
>> dynamic allocation.
>
> They have to worry about memory in C++ as well. If you
> want to not worry about the memory there are other
> languages that completely hides this, if that's what
> you want.

Then, why learn C along C++, which will/can create more confusion in the
minds of amateur programmers?

IMHO, the background and, or previous exposure to programming can also
be useful and sometimes critical when learn a new language; one needs
either to unlearn or differentiate many a things depending upon the
philosophy, paradigm and features of these languages.

[Balwinder S Dheeman]

Why, have I stepped on to your tail?

[Wouter van Ooijen]

Balwinder S Dheeman schreef op 13-Oct-14 11:45 AM:

> On 10/13/2014 11:04 AM, ojack...@gmail.com wrote:
>> On 2014-10-12, Balwinder S Dheeman <bdheeman...@outlook.com> wrote:
>>> +1
>>
>> Yo, Ball Winder,
>>
>> This "+1" bullshit has got to stop. This is usenet, not Facefuck. We
>> don't grunt our approval like fucking retards.
>
> Why, have I stepped on to your tail?

+1

Wouter

[Stuart]

On 10/11/14, Vincenzo Saltridge wrote:
> Emanuel Berg wrote:

>
>> Vincenzo Saltridge <vinc...@yahoo.com> writes:
>>
>>> There is nothing to learn, but just using, whatever tool. Also, doing

>>> C++ and not knowing C is plain stupid, and should not be allowed.
>>
>> It is also all but impossible because if you do it you will know C by
>> knowing C++...
>
> Not necessary. You don't know how stupid people can be. As for instance
> those using Visual Basic. They are really stupid.

Ahem ... even though I consider myself rather a C++ programmer than a
Visual Basic programmer I tend to feel offended. After having written a
120Kloc project with C++, my next project amounted to 25Kloc of Visual
Basic for Excel. I was very surprised that Visual Basic allowed a very
crude form of object orientation, so this project was actually fun. Of
course, this was standing Visual Basic on its hind legs (something that
the average Visual Basic programmer won't do, and certainly nothing I
can pride myself of having done with C++)...

Regards,
Stuart

[JiiPee]

Yes , I am also a C++ guy, but Visual Basic is top language on Excel,
best too there.

right tool to right job...

[Öö Tiib]

On Sunday, 12 October 2014 17:41:26 UTC+3, Emanuel Berg wrote:

> Bo Persson <b...@gmb.dk> writes:
>
> >> There is nothing to learn, but just using, whatever
> >> tool. Also, doing C++ and not knowing C is plain
> >> stupid, and should not be allowed.
> >

> > Why? You can easily learn italian without knowing
> > latin first. It's the same way with programming
> > languages.
>
>
> In general: yes, but in the case of C++ and C it is
> impossible from a practical perspective to learn C++
> without learning C as well as C is a huge subset of
> C++. (At least formally so, in reality it is probably
> more correct to say that C++ is an extention of C.)

C++ and C are two different languages that have common
subset. It is possible to write programs in that common
subset (and some people do it) but I do not know of good
book that teaches it.

Writing in the common subset you can not use some useful
features of C and lot of useful features of C++.

The common subset program has to contain some idioms
that are considered bad by experts of both languages.
For example you need to cast the 'void *' returned by
'malloc' in common subset. Most C experts suggest that
such cast is unneeded bloat in C. Most C++ experts
suggest to use 'new' or 'std::vector' instead of that
'malloc'.

[Rick C. Hodgin]

Öö Tiib wrote:
> Most C experts suggest that such
> cast is unneeded bloat in C.

I have found that casting malloc() is a good idea, and
typically correlates to the malloc() input in some way,
which helps reduce bugs, and aids in long term maintenance.

// myptr may be declared off-screen
myptr = (Sxyz*)malloc(sizeof(Sxyz) * count);

If the cast wasn't there, and wasn't required, you'd only have
one cue as to the true purpose of the malloc(). If you meant
Sabc, but used Sxyz, it would silently introduce the bug. With
the cast, and the cast requirement, it is more difficult
to introduce accidental bugs on malloc(), and it helps in
identifying myptr's usage should its naming convention
not explicitly convey something.

[Öö Tiib]

Yes, but that is not the idiom typically used in C. Typical
C malloc-usage idiom is that:

myptr = malloc(sizeof(*myptr) * n);

So "I want things that myptr points at, allocate me room for
n of those". There's no need to state any types here.

[Rick C. Hodgin]

Öö Tiib wrote:

> Yes, but that is not the idiom
> typically used in C. Typical C
> malloc-usage idiom is that:
>
> myptr = malloc(sizeof(*myptr) * n);
>
> So "I want things that myptr points
> at, allocate me room for n of
> those". There's no need to state
> any types here.

I've never seen or used this. It looks
dangerous to use to me, as there is
no reference to what myptr is. It must
then be sought after elsewhere to
understand the goal of that source
code line.

I do see it removing the potential bug
in the Sxyz/Sabc confusion, but it comes
at the high cost of removing the infor-
mation otherwise conveyed. For me, that
cost is too high.

[Ian Collins]

嘱 Tiib wrote:
> On Tuesday, 14 October 2014 09:57:21 UTC+3, Rick C. Hodgin wrote:

Yes, that is the idiomatic form in C.

Some consider casting the return of malloc to be wrong because it could
cause bizarre run time errors if no prototype was available and an int
return was assumed by the compiler. While possible, I doubt this would
happen in practice, but the cast is still unnecessary clutter in C.

The reason for sizeof(*ptr) rather than sizeof(T) is clearer: T (and
therefore sizeof(T)) may change, but sizeof(*ptr) will always yield the
correct size.

--
Ian Collins

[Ben Bacarisse]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:

> 嘱 Tiib wrote:
>> Most C experts suggest that such
>> cast is unneeded bloat in C.
>
> I have found that casting malloc() is a good idea,

In C++ you have to, and in most of the posting you've made to
comp.lang.c you've been actually writing C++ not C. It not surprising
that you've got used to the "wrong" idiom since you don't write much (or
any?) C code. (I put "wrong" in quote because I know it's a much
debated point.)

<snip>
--
Ben.

[Martijn Lievaart]

On Sun, 12 Oct 2014 16:47:55 +0200, Emanuel Berg wrote:

> You often C the combination C/C++ in literature, ads, and so on. Well,
> there *is* a "C/C++" and that is C++.
> Other than that C and C++ are two different languages with different
> syntax, tools, and (as you mention) libraries. Tho the biggest
> difference by far is the C++ focus on OO.

And generic programming. So the two biggest differences are by far the
focus on OO and generic programming. And the STL. So the three biggest
differences...

Never mind, I'll get my coat.

M4

[Jorgen Grahn]

On Sun, 2014-10-12, Emanuel Berg wrote:
> Wouter van Ooijen <wou...@voti.nl> writes:
>
>>> C++ is C plus OO.
>>
>> NOOOOOO
>>
>> It might have started that way, but C++ is so much
>> more than just C + OO.
>>
>> just to name a few: - exceptions - reference
>> parameters, default parameters, overloading - better
>> type system (new/delete, templated casts, bool, enum
>> class, ... ) - constexpr - templates
>
> Again, a lot of those things are to my mind OO.

According to most people's definitions, they're not. See e.g.

http://en.wikipedia.org/wiki/Object-oriented_programming

Not that I understand why polymorphism and inheritance are neccessary
parts of OOP, but Stroustrup seems to include that in his definition
too.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Emanuel Berg]

Melzzzzz <m...@zzzzz.com> writes:

> C is not for beginners.

Why not? C can absolutely be learned as a first
language. The syntax is clear (and has influenced many
other languages) and in terms of concepts the language
has a scope that is manageable to anyone.

If you study a beginner's book on C cover-to-cover and
do all the exercises, I'd say you have a fairly good
understanding of both C and programming in general.

The next step (which is more difficult) is to stop
doing bubblesorts and the like and instead write
programs that do meaningful things, with your files,
system, or even the outside world (as in analyzing
data or whatever).

But just programming as in function calls and return
values and data types and branching (if) and iterating
(for loop and arrays), and looping in general ([do]
while), etc., for all that stuff C is a great
language, for beginners as well as veterans...

> He didn't count that one don't have to write classes
> in order to use them ;) What about Java? In Java
> even "hello world" requires writing class. And Java
> is supposed to be beginner friendly ...

Java shouldn't be used by beginners as it is to
confusing and to aesthetically unappealing it might
turn people away from programming forever.

--
underground experts united

[Emanuel Berg]

Bo Persson <b...@gmb.dk> writes:

> There is no OO going on here, just some "C with
> classes". No new or delete, no inheritance, no
> virtual functions. It just works.
>
> Telling a new student that std::string holds a
> string, and that you can get its size by calling
> str.size(), will surprise nobody.

Well... yeah? That is what OO is: making a bubble of
the string data and the functions that works on that
data. I consider that very much OO, are you saying you
are not? The inheritance part and all the fancy
polymorphism stuff is OO as well but that is the OO
part I don't like and I think it is scholastic and
only makes for confusion in a lot of
implementations...

> Compare that to the "easy to understand" C string
> functions, and try to explain the incantation
>
> char* b = malloc(strlen(a) + 1);

It should be noted that C isn't known for being
particularly good with strings, especially when it
comes to changing them on the fly. No one is saying
you should do a web-based Twitter client with C.
Strings in C are robust... Wherever you put them, they
stick. Just put a couple of them there and then forget
all about it and focus on the rest of the program.

--
underground experts united

[Emanuel Berg]

Robert Hutchings <rm.hut...@gmail.com> writes:

> I am following this discussion with keen interest.
> So, if one reads "Accelerated C++" by Koenig and
> Moo, they are learning C++ right from the start. Are
> we saying that this is the *wrong* way to learn C++?

No. The right way to learn C++ is to learn C++.

If you wish to learn programming *in general* I'd say
you can either start with C, or start with C++ and be
aware that a lot of C++ is actually (also) C. Perhaps
it is easier from a practical standpoint to first do
C, then you don't have to care about the "aware" part.
But both ways will work.

If I'm saying anything, I'm saying it doesn't matter
what order you do things. What does matter is how
much, how often, and with what focus you go about
doing it.

--
underground experts united

[Emanuel Berg]

Bo Persson <b...@gmb.dk> writes:

> So lets's compare. :-)

No, thank you :) I don't know C good enough to get
into a language war defending it. I'm actually more
into Lisp and the shell tools... But I don't see any
reason to put C and C++ against each other. There are
room for both.

> std::string a = "Sample string"; std::string b = a;
>
> or
>
> char a[] = "Sample string"; char* b = malloc(strlen(a)
> + 1); strcpy(b, a); /* and sometimes later: */

It is true that if you want to do a lot of string
stuff there are languages that are better than C (and
even C++, because you want to do it dynamically
without having to recompile all the time).

> Newer C++ has better for loops as well, like:
>
> for (auto x : v) std::cout << x;
>
> will output all elements in the sequence v, like a
> vector, or a string or an array, or ...

Cool. That looks almost like GNU parallel.

--
underground experts united

[Emanuel Berg]

JiiPee <n...@notvalid.com> writes:

> yes, this would be pain for me... "lazy" programmer
> as I am. I really don't like to remember doing
> free() at the end. I want it to be automatic.
> Although maybe C-people can show how to aumatizice
> this?? I guess C programmers use some helper
> function to do these? Doing like that would be pain
> for me at least... I do not like to write code if
> not necessary.

There is nothing that says that C++ is less
code writing than C. In general the OO model makes for
long programs, but on the other hand programs that are
easily read (unless of course too much OO overspin is
put into it).

C is more old-school, "stupid" but straightforward
computing. You don't need to solve the problem by
making a model of the problem first. You know the
problem, you know the solution, and the solution isn't
expressed as a model of the problem, it is just a
solution that hangs completely in the air, but if you
implement it it'll solve your problem nonetheless.
Dig?

--
underground experts united

[Ian Collins]

Emanuel Berg wrote:
> JiiPee <n...@notvalid.com> writes:
>
>> yes, this would be pain for me... "lazy" programmer
>> as I am. I really don't like to remember doing
>> free() at the end. I want it to be automatic.
>> Although maybe C-people can show how to aumatizice
>> this?? I guess C programmers use some helper
>> function to do these? Doing like that would be pain
>> for me at least... I do not like to write code if
>> not necessary.
>
> There is nothing that says that C++ is less
> code writing than C. In general the OO model makes for
> long programs, but on the other hand programs that are
> easily read (unless of course too much OO overspin is
> put into it).

So don't use OO. Using standard containers and algorithms does reduce
the amount of code compared to C.

--
Ian Collins

[Mel]

On Wed, 15 Oct 2014 03:05:48 +0200, Emanuel Berg
<embe...@student.uu.se> wrote:
> Melzzzzz <m...@zzzzz.com> writes:
> > C is not for beginners.




> Why not? C can absolutely be learned as a first
> language. The syntax is clear (and has influenced many

Problem is that it is low level language requiring to pay attention
to things one normally don't need to. Not having ptoper arrays and
strings is great burden on novice...

--
Press any key to continue or any other to quit

[Paavo Helde]

Emanuel Berg <embe...@student.uu.se> wrote in

news:87mw8yw...@debian.uxu:

> Bo Persson <b...@gmb.dk> writes:
>
>> There is no OO going on here, just some "C with
>> classes". No new or delete, no inheritance, no
>> virtual functions. It just works.
>>
>> Telling a new student that std::string holds a
>> string, and that you can get its size by calling
>> str.size(), will surprise nobody.
>
> Well... yeah? That is what OO is: making a bubble of
> the string data and the functions that works on that
> data. I consider that very much OO, are you saying you
> are not?

So let's compare again (leaving out error checking for brevity):

In C:

#include <stdio.h>
FILE* f = fopen("abc.txt", "w");
fprintf(f, "%d", 12);
fclose(f);

In C++:

#include <fstream>
std::ofstream f("abc.txt");
f << 12;

In both cases a dedicated file object is created (of type FILE in C, if
you haven't noticed). In both cases it is manipulated exclusively by
functions which work on its data. In both cases this is not relevant for
the programmer at all. Yet you say that one of these examples is OO and
the other is not. On what ground do you make this assertion?

Let me tell you: this is because you have already decided in advance how
the things must be, and now you are bending everything to fit your mental
model.

For me, the OO content of those snippets is exactly the same. It does not
matter how these things are implemented in the standard library of the
relevant languages (I guess one could write also the C runtime library in
C++ or whatever), this does not make my code more or less OO.

The only difference is that one solution is much more complex to write
than the other (requiring explicit release of the resource, with a
specialized function; requiring knowledge of printf minilanguage inside
the language; requiring extra care for getting and keeping the types
correct as the minilanguage is not type-safe). All these aspects are
cured in C++ thanks to the features which are not OO-related: RAII,
function overloading and templates.

> The inheritance part and all the fancy
> polymorphism stuff is OO as well but that is the OO
> part I don't like and I think it is scholastic and
> only makes for confusion in a lot of
> implementations...

You might have some point here, but this is exactly what all other people
are talking about under the term "OO". Your much broader definition does
not make sense, because then also the C language (and many more) must be
called object-oriented, as demonstrated by the above snippets.

Cheers
Paavo

[J. Clarke]

In article <XnsA3C754D1FD1A3m...@216.196.109.131>,
myfir...@osa.pri.ee says...

You seem to be conflating the existence of a particular kind of object
in the language with being an object oriented language. If you work
hard enough you can make something that works like an object in assembly
language, but that doesn't make assembly language object oriented.

An object oriented language is one which has facilities for creating new
kinds of object and their associated methods and properties. Does C
have these other than doing it by brute force and awfulness?

[Ian Collins]

J. Clarke wrote:
>
> You seem to be conflating the existence of a particular kind of object
> in the language with being an object oriented language. If you work
> hard enough you can make something that works like an object in assembly
> language, but that doesn't make assembly language object oriented.
>
> An object oriented language is one which has facilities for creating new
> kinds of object and their associated methods and properties. Does C
> have these other than doing it by brute force and awfulness?

Yes it does, people have been writing OO code in C for decades.
Certainly before C++ came into the world.

--
Ian Collins

[David Brown]

Paavo did not claim that C was an object oriented language - he claimed
that snippets like the ones he gave are as much "object oriented" in C
and C++.

His point (I believe) is that /neither/ code snippet makes use of real
OO coding - they just make use of an object. It is not until you are
using more powerful features of classes, such as inheritance and
polymorphism, that the term "object oriented" becomes relevant.

And yes, C /does/ support object oriented development. It is certainly
easy to make use of objects in C, as shown by Paavo's snippets. But C++
makes OO development easier and more efficient for the developer, more
efficient at run-time, and has it as an integrated part of its standard
library - /that's/ what makes C++ an "object oriented language".

[Paavo Helde]

"J. Clarke" <jclark...@cox.net> wrote in
news:MPG.2ea7e6a6b...@news.newsguy.com:

> In article <XnsA3C754D1FD1A3m...@216.196.109.131>,
> myfir...@osa.pri.ee says...

>> In C:
>>
>> #include <stdio.h>
>> FILE* f = fopen("abc.txt", "w");
>> fprintf(f, "%d", 12);
>> fclose(f);
>>
>> In C++:
>>
>> #include <fstream>
>> std::ofstream f("abc.txt");
>> f << 12;

> You seem to be conflating the existence of a particular kind of object
> in the language with being an object oriented language. If you work
> hard enough you can make something that works like an object in
> assembly language, but that doesn't make assembly language object
> oriented.
> An object oriented language is one which has facilities for creating
> new kinds of object and their associated methods and properties. Does
> C have these other than doing it by brute force and awfulness?

Not sure who you are exactly responding to, but I agree with you fully.
The presense of a std::ofstream object in the above C++ snippet does not
make the snippet code to be particularly object-oriented, as it does not
create new classes nor their associated methods or properties.

Cheers
Paavo

[David Harmon]

On 14 Oct 2014 21:16:49 GMT in comp.lang.c++, Jorgen Grahn
<grahn...@snipabacken.se> wrote,

>Not that I understand why polymorphism and inheritance are neccessary
>parts of OOP, but Stroustrup seems to include that in his definition
>too.

It's just terminology. Without them, it's called "object based".

[Tobias Müller]

Bo Persson <b...@gmb.dk> wrote:
> Compare that to the "easy to understand" C string functions, and try to
> explain the incantation
>

> char* b = malloc(strlen(a) + 1);

char* b = strdup(a);

Tobi

[Chris Vine]

To the best of my knowledge (it may have been recently added), strdup()
is not C. It is POSIX.

Chris

[Tobias Müller]

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> To the best of my knowledge (it may have been recently added), strdup()
> is not C. It is POSIX.

Strictly speaking you are probably right, but in practice it's present on
virtually every platform.
And if not, it's trivial to implement it yourself.

Tobi

[Emanuel Berg]

Jorgen Grahn <grahn...@snipabacken.se> writes:

> It is, but a lot of that subset is of no use in
> normal C++ programming. (Perhaps more the idioms
> than the concrete language constructs: you will use
> most C language constructs in your C++ programs over
> the years, but not in the way a C programmer would.)

Well, now you are introducing the "C programmer". Some
guy who did almost nothing but C for decades and
during this time acquired all the good habits as well
as all the hacks. And those are the exact same that
some other guy acquired from doing C (almost nothing
but C) at some other facility. And then when they
switch to C++...

There might certainly be some common culture and some
common methods to deal with particular problems within
a group that does one piece of technology - but it is
too schematic for me. Most people didn't do C at AT&T
porting UNIX from B...

I don't think you will be a worse C++ programmer from
doing C. On the contrary, I think you will be a better
C++ programmer the more you do C. And I think you'll
be a better C programmer the more you do C++. The more
you do it, the better, and those are fairly close, all
things considered.

But: although learing Latin will make it easier for
you to learn Italian (not just words, morphology, and
theory terminology as in grammar, etc.) but also
work-habits - how to learn a foreign language - you
will *not* be that much helped if you do tons of Latin
and then go to Italy and try to communicate or read
the paper. (Or you will be, but it won't be
proportional by far, like in far-far.) Compare this to
a guy who is fluent in the C syntax and very familiar
with the libraries and stuff. OK, take this person to
C++. Oh, mama, it'll tear down the tower of Pisa - and
con estilo at that.

--
underground experts united

[Emanuel Berg]

JiiPee <n...@notvalid.com> writes:

> int i; for(i=0; i<size; ++i)

That looks even better this way:

for (int i = 0; i < size; i++)

++i (instead of i++) looks backward and it is
confusing as it doesn't serve a clear purpose (or
any?).

You can put the declaration of i within the for loop
if you pass either of -std=c99, -std=gnu99, -std=c11
or -std=gnu11 to gcc.

> can be done in C++: for(auto i : vec)
>
> clearly c++ version is shorter and more elegant
> here. Its also easier to see what happens in the
> looop.

No, I think the traditional for-loop is much more
clear and, well, "elegant" is perhaps not the word I'd
pick but OK. That new C++ version looks like Java and
it isn't self contained or explicitly typed.

> So its better readable. plus the assembly code is
> the same in both, so they are equally fast

You don't need to worry about speed with for-loops
unless you nest them in crazy ways, which you
shouldn't do. Don't worry about speed. C, and C++, are
fast enough. Worry about clarity and the
restricted-but-efficient use of modularization and the
use of proper data structures and algorithms (sounds
fancy, but really it comes down to what has proven to
work, which is equally down-to-earth). If you do the
small things right, speed will come automatically.

> Or would you say the C code here is better? In what
> way?

It is not about better or worse. The definition of a
good program is a program that does its task. Often,
the choice language is secondary. The most important
thing is the choice of programmer, and his
understanding of the task and the techno-setting that
the problem-solver (the program) will interact with.
Being fluent in the syntax of C and C++, as well as
the workings of an editor (e.g., Emacs, vim), is an
advantage because then less brain-power has to be
allocated to the process of writing code. Being fluent
with the C and C++ libraries is a big advantage
because of the above reason (again), but also because
those libraries are themselves interfaces to the
system and computer beneath. If you understand all
this, you can focus all your mental and physical
strength to the actual problem and only think about
that, never what to type, how to kill or yank, what
library to use, etc., but instead it'll be all about
the problem at hand. If you know all that and still
can't solve the problem, perhaps you should find
another profession/hobby :) But seriously that has
never happened - and how could it?

> in C (and lets imagine that the vector item type is
> very long, thus auto makes the type short)?

Don't be afraid of typing! Put your hands in the
correct position: asdf for the left, jkl; for the
right, master all the keystrokes of a professional
editor (like get it into your muscle memory), set the
keyboard layout to US (to get all the /[]{}; close and
tight, never use the mouse, and then type, type, and
type!

--
underground experts united