C or C++?

[Zeppe]

Your point is bullshit. And all the winkies and other emoticons don't
change that fact.

Hey guys, cool down! The point is quite easy in my opinion:

1) the difference between the languages is a difference in paradigms:
assembly is unstructured programming, C is procedural programming, and
c++ is object oriented programming, so they are all different.

2) c has got some support for unstructured programming, like goto or
labels, that are probably included to make easy for an unstructured
program like an assembly one to be ported easily to C, and not to create
a too big gap between C and previous languages. Anyway, the unstructured
programming and its constructs are clearly deprecated in C. The same is
with C++: you can use it like a C, you will find it easy because all the
C it's supported in C++, but that use of C++ is deprecated, because C++
is an OO language. From this point of view, C doesn't help too much to
learn C++ because it teaches you the wrong paradigm. Of course, if you
are already confident with functional programming, and you are able not
to be biased from that, you can take advantage of that in C++: in the
same way, if you know low-level unstructured programming, pointers,
variables and this sort of stuff from assembly, you can take advantage
of it in c.

Regards,

Zeppe

 

[Gianni Mariani]

Speak for yourself. Maybe *you* have these difficulties and prejudices,
but I certainly don't - I can adapt to different languages quite easily.

Claiming your special does not prove anything.

I think Juha's point is more correct than it is wrong. I have seen
far too many C programmers claiming to know C++ and only to find they
don't.

Quite a few things that make good C code, bad for C++ code.

e.g.

A) In C++. don't pass function pointers, pass a class pointer (or
reference) with virtual methods.
B) In C++, don't use malloc/free - use std::vector if you have to.
C) In C++, dont use char *, use std::string
D) In C++, preference is to pass const references, not by value
E) In C++, use the initializer list not the body of the function
F) In C++, creating a class or a function should be at the same design
decision point
G) In C++, your code should be exception safe, C has no exceptions
H) In C++, use RAII, C has no RAII idiom
I) In C++, avoid macros is possible, in C you use macros for too many
things
J) In C++, restrict your interface by 'public', 'private' and
'protected' members, in C everything is public.

I can go on and on. I get complaints from C programmers all the time
that some C++ idiom is too complex or that overloading the assignment
operator is a bad thing etc.

I don't know about you but I have yet to meet a pre C come C++
programmer that has not struggled loosening the knots of the C
methodologies. Actually, not even just C but Java, C# and Javascript
coders as well.

 

[Branimir Maksimovic]

There's a huge difference between being "close to the machine" and being
a "portable assembler". C++ is as close to the machine as C, but I
don't hear you calling C++ a "portable assembler".

That's right. This is because when I met C I didn't change programming
style at all. Continued to program in same way I would do
in assembler. C++ on the under hand changed my point of view
on programming from the ground up and I needed much more time
to learn new style(s).

Patch panels, machine code, assembler, C and C++ are just steps along
the evolutionary path of programming languages.

Exactly.

Greetings, Branimir.

 

[Branimir Maksimovic]

Pure and utter nonsense.

All that ugly and hackish C programs with bunch of casts
that try to do tasks which are cleanly and safely done in
assembler programs out there, speak for my word.
On the other hand you are replying to something I have quoted.
and I didn't tell that C is successful in it's task.
C++ is language done right. High level language that can actually
fulfill tasks where C failed. This is of course my opinion,
you don;t have to agree, and really I don;t care.

Your point is bullshit.

Are you sure? You didn't provide any evidence on the contrary.

Greetings, Branimir.

 

[Phlip]

All that ugly and hackish C programs with bunch of casts
that try to do tasks which are cleanly and safely done in
assembler programs out there, speak for my word.

Branimir is absolutely correct. C has always been considered "portable
assembler". You have to know how memory is laid out, and how stacks and
pointers work in hardware, even just to _avoid_ implementation-defined and
undefined behavior.

On the other hand you are replying to something I have quoted.
and I didn't tell that C is successful in it's task.
C++ is language done right. High level language that can actually
fulfill tasks where C failed. This is of course my opinion,
you don;t have to agree, and really I don;t care.

C++ only smooths over C's rougher spots, and adds some OO abstractions.
That's enough for us to program far beyond C, because OO is good. But C++
should still be considered "very high level portable assembler".

C++ is hard to use, and hard to avoid undefined behavior. The benefit is
high performance. So if you need high performance, then you need to learn
C++'s quirks, and then you need to learn how it compiles into opcodes, so
you can reduce those and make a program faster. So the best way to use C++
is still as "portable assembler".

Are you sure?

You may want to consider using your newsreader's killfile mechanism. Some
people are not here to learn.

 

[Default User]

All that ugly and hackish C programs with bunch of casts
that try to do tasks which are cleanly and safely done in
assembler programs out there, speak for my word.

That doesn't even make sense.

On the other hand you are replying to something I have quoted.
and I didn't tell that C is successful in it's task.

What does that even mean? What task? Portable assembler? That's still a
crock.

C++ is language done right. High level language that can actually
fulfill tasks where C failed.

No, it was an attempt to introduce a new language paradigm while
retaining nearly all the features of the past. I personally like it
fine, but many others out there feel it's clunky and bloated.

This is of course my opinion,
you don;t have to agree, and really I don;t care.

Apparently you do, as you keep trying to justify your ridiculous claims.


Brian

 

[Default User]

Branimir Maksimovic wrote:

Branimir is absolutely correct.

No, he's not.

C has always been considered "portable assembler".

Yes, there have always been idiots who believe anything they're told,
even when a few minutes research would tell them that they're wrong.

You have to know how memory is laid out,

Oh? Why is that?

and how stacks

Oh, why is that?

and pointers work in hardware,

No you don't. You only need to know how pointers work in the abstract.
That's why C has typed pointers, to automatically adjust the stride of
the pointer for pointer arithmetic.

even just to avoid
implementation-defined and undefined behavior.

Give some examples.

C++ only smooths over C's rougher spots, and adds some OO
abstractions. That's enough for us to program far beyond C, because
OO is good. But C++ should still be considered "very high level
portable assembler".

Only by people you.

You may want to consider using your newsreader's killfile mechanism.
Some people are not here to learn.

Well, you are one of them, so you should know.




Brian

 

[Default User]

Gianni Mariani wrote:

I think Juha's point is more correct than it is wrong. I have seen
far too many C programmers claiming to know C++ and only to find they
don't.

That's ok, a lot of C++ programmers don't know C++ either.



Brian

 

[Branimir Maksimovic]

Branimir Maksimovic wrote:

C++ only smooths over C's rougher spots, and adds some OO abstractions.

I can't completely agree here.
C++ allow possibility to have proper string instead of assembler
string,
real array and so fort. With templates and possibilities to pass
different types through pointer/reference to single type it allows
type safe operations. For example I use event handling template
classes that can be embedded into any C event handling
system, which dispatch events to handlers (virtual or non virtual)
without single cast.

That's enough for us to program far beyond C, because OO is good.

Not just OO. OO is not enough to provide type safety.
Both OO and templates accomplish that task.

But C++

should still be considered "very high level portable assembler".

Agreed, as C++ is also built on assembler constructs.

C++ is hard to use, and hard to avoid undefined behavior.

I thought so, but then again I learned language myself.
But I had young programmers who used language to
do everyday tasks after couple of months when day first
saw language. With one experienced C++ programmer,
,there are good books too,I never saw that young programmers
produce undefined behavior programs or that they had
problems with language.
But then again, problem arises because there are lot of things
that can be done in other languages (functional, scripting,assembler),
and can't be done in C++ easily or at all.
Then fight with a language starts, but then again, I just
figured out, not to fight with a language, but to use other
ones when appropriate


The benefit is

high performance. So if you need high performance, then you need to learn
C++'s quirks, and then you need to learn how it compiles into opcodes, so
you can reduce those and make a program faster.

Not necessarily. For everyday tasks I don;t have to even think
about performance and I don;t care because I have never had
problems with performance.
But I have tried Haskell and concluded that for reasonable performance
and memory usage I have to use assembler arrays, strings, and malloc/
free with even more unsafe techniques
When I looked that I got that for free with high level constucts in C+
+,
and that C++ programs work with required performance
without any effort, but I have to be ultra guru to barely get
required performance in Haskell, I give up on that language.

So the best way to use C++

is still as "portable assembler".

C++ can be used as portable assembler,too,
but rarely as most task does not require low level programming.
But then again, when low level constructs are needed I use
real assembler more and more.

You may want to consider using your newsreader's killfile mechanism. Some
people are not here to learn.

My principle is basically not to filter anyone's messages except
spamers
that advertise products on newsgroups and are not
interested in discussion. Default user does not behaves like a
educated gentlemen, but that is his problem, not mine.
Perhaps this is because he is young and has
strong emotions about this.

Greetings, Branimir.

 

[Gianni Mariani]

STL is a mix of functional programming concepts and C idioms. A
container is an abstraction of a C array, an iterator is an
abstraction of a C pointer and algorithms are designed in C style,
e.g. std::sort has almost the same interface as qsort (sans template
obfuscation). That's pretty obvious.

I fail to see the obviousness of your argument.

.... The success of STL among 'geeks'
(and only among them) was mainly driven by the fact that it ditched
(falsely used and overused) OOP and reverted to the C programming
style in new templatized cloths.

This conclusion all because std::sort is a templated function ?

std::sort does far more than qsort would ever do mainly because of
OOP.

a) qsort operates on pointers - std::sort operates on iterators
(including pointers)
b) std::sort is type safe, qsort is not
c) std::sort can be optimized for the types it's working on, qsort
cannot (big performance gain for std::sort here)
d) std::sort compare method can be a functor which allows for much
more utility (oop wise) that qsort which only allows a comparison
func.

Because of "C"'s very limited scope for reusability, qsort is
significantly more error prone and less useful than C++'s std::sort.

 

[Phlip]

I can't completely agree here.
C++ allow possibility to have proper string instead of assembler
string

Absolutely. Most C++ code should work as a very-high level language.
However, if you need such a language, you must also ask why you think you
need the tedium of C++'s remaining rough spots. You can still run off the
end of a std::string, unless you only use its simplest functions.

So if you need a very-high level language, sometimes you should use a real
one. Not all programs need C++ speed. You get that speed by running close to
the metal.

Your remaining points are just variations on the same theme. I am not
advocating any language (unlike some folks on this thread who will remain
nameless).

But I have tried Haskell

Ouch. Try Ruby or Smalltalk. You might need more experience staying in the
problem space. C++ forces you to spend a lot of time in the solution space,
screwing with the plumbing of your design.

C++ can be used as portable assembler, too,

You are reciting the standard C++ description that "C++ is a multi-paradigm
language". I agree, but all those paradigms will all remain assembler-aware.
The portable assembler aspect is not one of the paradigms, it is the primary
motivation underlying all of them. C++ requires you to understand what the
silicon oxide is doing, to stay safe.

 

[Roland Pibinger]

I fail to see the obviousness of your argument.

Sorry, I can't help you. I just wanted to point out conceptual
similarities between STL and C programming.

std::sort does far more than qsort would ever do mainly because of
OOP.

STL has nothing in common with OOP. It is neither implemented
according to OO design principles nor does it support OO programming.
You are completely on the wrong track.

 

[Gianni Mariani]

On 13 May 2007 00:17:03 -0700, Gianni Mariani wrote: ....
STL has nothing in common with OOP. It is neither implemented
according to OO design principles nor does it support OO programming.
You are completely on the wrong track.

You seem to have a strange definition of OOP. Please elaborate why
you consider the STL to not support OO programming.

 

[Gavin Deane]

IMO, that's the "you can't teach old dogs new tricks" myth that is
employed when a new technology isn't adopted by the real world as
expected. We saw it with OOP ("nobody can learn OOP who has been
contaminated with procedural programming") and later - under different
circumstances - with STL or "generic" programming ("nobody can learn
STL who has been contaminated with procedural or OO programming").
It's just a myth.

I think that's overstating it. "Learning C is not a prerequisite to
lerning C++ and may indeed make learning C++ harder" is completely
different to "nobody can learn C++ who has been contaminated with C".
The latter is IMO nonsense and I don't think anyone is suggesting it.
On the other hand, in response to

"Is C required before learning C++?"

you said

"No in theory, yes in practice."

which is equivalent to "in practice, you can't teach a dog trick B
unless you've taught it trick A first." Whether one believes that
depends on how much one believes the ability to perform trick B is
simply a natural extension the ability to peform trick A. In my
opionion, very little. It is like trying to teach a tennis player to
play badminton. Superficially, both are very similar - they involve
hitting something back and forth with a racquet. But the techniques
(e.g. use of the arm, wrist and racquet) are completely different.
There is nothing preventing a tennis player from learning badminton,
but they will have to unlearn some instincts and habits. However, if
someone who currently plays neither game wants to learn to play
badminton, why would you teach them to play tennis, with all it's
techniques and instincts that are irrelevant or contradictory to
playing badminton, first?

But I reiterate, that argument only holds if you believe that "the
ability to program in C++" is not simply "the ability to program in C
plus some extra ability on top of that". I imagine that is where the
disagreement lies.

Gavin Deane

 

[Juha Nieminen]

What a load of crap. Seriously. Most C programmers I know are flexible
and knowledgable in multiple languages.

I have met many C "hackers" with irrational prejudices against C++
and the way of doing things there. It's not even uncommon to see the
claim that "C is better than C++", and if you ask for the reasons,
all of them are completely fallacious, based on prejudices and not
knowing how things really work in C++.

 

[Juha Nieminen]

Speak for yourself. Maybe *you* have these difficulties and prejudices,

That sentence just doesn't make sense. If I had all these prejudices
and difficulties, how come I wrote the above paragraph? The thing with
these prejudices and false information is precisely that the person
having them doesn't know they are simply prejudices and fallacies but
instead believes them to be true. If I were such a person, why would
I write the above?

but I certainly don't - I can adapt to different languages quite easily.

Right. Because you don't have prejudices then nobody has.

 

[Juha Nieminen]

J) In C++, restrict your interface by 'public', 'private' and
'protected' members, in C everything is public.

In my experience one common difficulty self-taught C programmers,
who haven't learned nor understand object-oriented programming and
the abstraction/modularity related to it, is that they often have
hard time accepting the notion of public member variables being,
in the general case, a bad thing. They just can't understand why
everything can't just be public and why information hiding and
abstraction are a good thing. It often takes long time for them
to finally understand why.

Another slightly related issue is that, for some reason, they
(and in fact many other coders too, not just C ones) have an odd
aversion towards having to write anything extra. For example, many
coders prefer putting a member variable in the public part of the
class instead of putting it in the private part and writing an
accessor method for it, which they detest. They just don't like
having to write any extra code and can't see the benefit in abstracting
that member variable away.

I often see this phenomenon in C++ code out there. One good example
of this is the PopCap library. The vast majority of member variables
in the classes of that library are public, and the only reason for
this is that the developers were lazy and wouldn't bother creating a
more abstract design.

Of course this causes some negative side-effects. For example,
certain optimizations are impossible to implement in the library
without breaking tons of existing programs which use the library
and access the member variables directly (the library itself probably
also constantly accesses the variables directly, and thus would
require a major cleanup if this was changed).

 

[Branimir Maksimovic]

Ouch. Try Ruby or Smalltalk. You might need more experience staying in the
problem space. C++ forces you to spend a lot of time in the solution space,
screwing with the plumbing of your design.

Downloaded Ruby. I'll see if it performs reasonably well, and if
it has necessary support for what I need, I'll use it.
I have to mention that I have picked Haskell for emotional reasons,
language is one of the most beautiful ones, ever saw.
Unfortunately tools are not mature yet,
optimization is bad, both on speed and memory consumption so
programmer has to leave beauty and dig into ugliness
C++ is much better and easier for that task, but I really miss
run time parametric polymorphism

Greetings, Branimir.

 

[Default User]

I have met many C "hackers" with irrational prejudices against C++
and the way of doing things there. It's not even uncommon to see the
claim that "C is better than C++", and if you ask for the reasons,
all of them are completely fallacious, based on prejudices and not
knowing how things really work in C++.

I don't doubt that you can find such people. I can find irrational
programmers in most any language. However, that's not general trend of
the programmers I know. It could well be a function of where I work, of
course, which is in software research and development at an aerospace
company.



Brian

 

[Phlip]

STL has nothing in common with OOP. It is neither implemented
according to OO design principles nor does it support OO programming.
You are completely on the wrong track.

That assessment rests on the definition of OO. If you define it strictly as
jump tables for virtual functions, STL doesn't apply.

If you define it as the ability to swap in many implementations for one
function call - many different bar() implementations for one call to
foo.bar(), based on multiple derived foo types - then STL's generic template
program qualifies. It's duck-typing in action.