Oozing poison

[Quint Rankid]

You expect us to trust your judgement?

[I've found C++ _much_ easier to write robust code in compared to C.
It is clearly no proof against incompetent coders (nothing is), but it
does offer some really good tools to help competent ones...]

Well, objective-c (and it's inherent to all c based languages, unless
you start ripping out pointers, etc) is prone to allowing a single fly-
idiot
poisoning the whole barrel, and java like languages
were designed precisely to keep idiots at bay, but c++ seems to be
especially
susceptible to providing morons with tools to automate
writing some crap code.

I think it would be helpful to know why you are posting to this
group. Can you please tell me what you hope to accomplish? I think
this would help those who would like to respond to whatever points
you're trying to make.

If you are simply trying to tell us that you don't like C++, then I
think it is clear that you have done that. So I tentatively conclude
that you must have some other purpose in mind. Please share it with
us.

TIA

 

[Wil Evers]

[I've found C++ _much_ easier to write robust code in compared to C.
It is clearly no proof against incompetent coders (nothing is), but it
does offer some really good tools to help competent ones...]

Well, objective-c (and it's inherent to all c based languages, unless
you start ripping out pointers, etc) is prone to allowing a single fly-
idiot poisoning the whole barrel, and java like languages were designed
precisely to keep idiots at bay, but c++ seems to be especially
susceptible to providing morons with tools to automate writing some crap
code.

I think it would be helpful to know why you are posting to this
group. Can you please tell me what you hope to accomplish? I think
this would help those who would like to respond to whatever points
you're trying to make.

Well, AD, whoever he is, is not alone. Wasn't it Bjarne himself who
said something like "C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do, you blow away your whole leg"?

Personally, I believe that the built-in idiot filter in C++ is a
feature: I've seen it expose quite a few problems before they could
cause any real harm. The philosophy C++ inherited from C is to
trust the programmer, who is supposed to make an informed, intelligent
choice when it comes to selecting the right tool for the right job.

Of course, that doesn't mix well with a poor management style that is
only capable of focussing on short-term labor costs.

There. Now that felt good!

- Wil

 

[Quint Rankid]

Quint Rankid wrote:

 Wasn't it Bjarne himself who
said something like "C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do, you blow away your whole leg"?

http://www2.research.att.com/~bs/bs_faq.html#really-say-that
"What people tend to miss, is that what I said there about C++ is to a
varying extent true for all powerful languages. As you protect people
from simple dangers, they get themselves into new and less obvious
problems. Someone who avoids the simple problems may simply be heading
for a not-so-simple one. One problem with very supporting and
protective environments is that the hard problems may be discovered
too late or be too hard to remedy once discovered. Also, a rare
problem is harder to find than a frequent one because you don't
suspect it."

 

[Pavel]

So, you're not coding in C++, and you come to a C++ community hangout to
complain about C++ being difficult to comprehend, and you expect what,
sympathy?<shrug>

I'm not coding in C++ ANYMORE
I could not possibly see how it can be used to write robust code

You expect us to trust your judgement?

[I've found C++ _much_ easier to write robust code in compared to C.
It is clearly no proof against incompetent coders (nothing is), but it
does offer some really good tools to help competent ones...]

Well, objective-c (and it's inherent to all c based languages, unless
you start ripping out pointers, etc) is prone to allowing a single fly-
idiot
poisoning the whole barrel, and java like languages
were designed precisely to keep idiots at bay, but c++ seems to be
especially
susceptible to providing morons with tools to automate
writing some crap code.

I guess, everyone's mileage varies. For a change, I am on AD side in this
C-vs-C++ maintenance/reviewing issue although for different reasons. Reading C++
code takes, in my experience, much longer time than C code of equivalent
complexity because there are on average more (commonly used) meanings for
identically-looking C++ code than C code. I have already given on this group an
example that, in C, you pretty much know that f(a) does not change a -- but not
in C++. Also, something like a+b can mean anything but addition (forget about a
<< b being always a shift) and getting certainty is prohibitively time-expensive
(last time I counted, operator<< had some 3 to 4 thousands overloads in my
organization; add to this potential automatic conversions and you get the picture).

To be on schedule, a reviewer/maintainer needs to assume; but because there are
always more than one way to skin a cat in C++, any (and I mean *any*) assumption
one developer will find reasonable will be broken not too often in another
person's code that the unfortunate first developer has to review.

Writing C++ code is a different story.. I often call C++ code I am getting for
reviews or maintenance "write-only" because it takes longer to understand what
some code does (forget about "supposed to do") than to write the equivalent
code. (yeah, I know there shall be specs that say what code shall do; the only
thing is, often there are none).

I think that's why I noticed trend about C++ developers (and related managers)
to switch roles: you code if you can, no matter how high is your level in an
organization, and leave reviewing to underlings. I think this trend is
C++-specific, because the situation with Java is opposite, in my experience:
more senior people commonly review the code. I was too late to catch this trend
timely; now trying to reposition myself back to writing.. hopefully not
write-only code.


-Pavel

 

[Ian Collins]

Writing C++ code is a different story.. I often call C++ code I am getting for
reviews or maintenance "write-only" because it takes longer to understand what
some code does (forget about "supposed to do") than to write the equivalent
code. (yeah, I know there shall be specs that say what code shall do; the only
thing is, often there are none).

That should be "there shall be tests that so exactly what the code
does". I certainly rely on mine when modifying my own code that's more
than a couple of projects old.

 

[Pavel]

That should be "there shall be tests that so exactly what the code does". I
certainly rely on mine when modifying my own code that's more than a couple of
projects old.

Test results can be helpful in understanding some aspects of the code but,
paroding Murphy laws: "A reliable test of a feature of your current interest is
always missing". Also, the OP's (and oftentimes mine) issue is that we did not
write the code (or tests) we need to understand.

-Pavel

 

[Jorgen Grahn]

.

I guess, everyone's mileage varies. For a change, I am on AD side in this
C-vs-C++ maintenance/reviewing issue although for different reasons. Reading C++
code takes, in my experience, much longer time than C code of equivalent
complexity because there are on average more (commonly used) meanings for
identically-looking C++ code than C code. I have already given on this group an
example that, in C, you pretty much know that f(a) does not change a -- but not
in C++.

I don't see the problem. You review f(A&), and immediately see that it
can modify its apparent argument. So you ask yourself "will this be
obvious in the calling code, based on the name of f and so on?" If the
answer is "no", you fail the code.

Also, something like a+b can mean anything but addition (forget about a
<< b being always a shift) and getting certainty is prohibitively time-expensive

I don't get this part of your complaint. You must review the code with
the types of objects in mind. In the expression 'a+b' a and b have
certain types, and if you know these and still cannot think of one
reasonable meaning for the expression ... well, that's a reason to
fail the code right there!

(I assume there is no deep interitance hierarchy with run-time
polymorphism involved. I can't read such code, either.)

(last time I counted, operator<< had some 3 to 4 thousands overloads in my
organization; add to this potential automatic conversions and you get the picture).

And how many of these were not on the form ostream << const T& ?
I find it hard to believe that standard stream output can be a problem
in this context.

/Jorgen

 

[gwowen]

On Sun, 2012-01-22, Pavel wrote:

...


I don't see the problem. You review f(A&), and immediately see that it
can modify its apparent argument. So you ask yourself "will this be
obvious in the calling code, based on the name of f and so on?" If the
answer is "no", you fail the code.

quite.


#define f(x) modify_x(&x)

// You can write terrible code in any except Haskell
f(a);

 

[Gernot Frisch]

I could not possibly see how it can be used to write robust code

Am I feeding a troll now? :S

You can write perfectly robust code in C++ if you don't use pointers at all.
There's usually no need to do this, as other languages don't even have them.
Use references if you pass byref, and use containers if you want to allocate
to be safe.

 

[Victor Bazarov]

I could not possibly see how it can be used to write robust code

Am I feeding a troll now? :S
[..]

You are. Please don't. Thanks.

V

 

[Pavel]

I don't see the problem. You review f(A&), and immediately see that it
can modify its apparent argument. So you ask yourself "will this be
obvious in the calling code, based on the name of f and so on?" If the
answer is "no", you fail the code.

Even letting alone that failing all such code you encounter prevents you from
staying on schedule:

If you do not review but maintain it as in OP case -- what do you do then?

I don't get this part of your complaint. You must review the code with
the types of objects in mind. In the expression 'a+b' a and b have
certain types, and if you know these and still cannot think of one
reasonable meaning for the expression ... well, that's a reason to
fail the code right there!

Same question as above.

(I assume there is no deep interitance hierarchy with run-time
polymorphism involved. I can't read such code, either.)


And how many of these were not on the form ostream<< const T& ?

More than a half. People create other classes than standard streams, most of
them having stream-like (but not quite) semantics, for example for IPC purpose,
some with different semantics. An example of the issue is that something like
somestream << "abc" can lead to very different serializations for different
types of the stream depending on whether there is an operator<< with const char
* or some conversion is to be called. And of course it is not clear from the
call site whether such operator is defined (sometimes it matters, too, whether
it is defined as a member of the stream-like class or free-standing function).

I find it hard to believe that standard stream output can be a problem
in this context.

Well, believe it or not, it takes more time, sometimes many times so, to read
this code with complete understanding of whether there is bug there (let alone
what exactly will be in the output) even for ostream-like first arguments (which
is, as I mentioned earlier, is not always the case) than something printf-like
and this is a problem.

/Jorgen

-Pavel

 

[AD]

[I've found C++ _much_ easier to write robust code in compared to C.
It is clearly no proof against incompetent coders (nothing is), but it
does offer some really good tools to help competent ones...]
Well, objective-c (and it's inherent to all c based languages, unless
you start ripping out pointers, etc) is prone to allowing a single fly-
idiot poisoning the whole barrel, and java like languages were designed
precisely to keep idiots at bay, but c++ seems to be especially
susceptible to providing morons with tools to automate writing some crap
code.

I think it would be helpful to know why you are posting to this
group.  Can you please tell me what you hope to accomplish?  I think
this would help those who would like to respond to whatever points
you're trying to make.

Well, AD, whoever he is, is not alone.  Wasn't it Bjarne himself who
said something like "C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do, you blow away your whole leg"?

Personally, I believe that the built-in idiot filter in C++ is a
feature: I've seen it expose quite a few problems before they could
cause any real harm.  The philosophy C++ inherited from C is to
trust the programmer, who is supposed to make an informed, intelligent
choice when it comes to selecting the right tool for the right job.

Of course, that doesn't mix well with a poor management style that is
only capable of focussing on short-term labor costs.

I don't see how you could maintain any reasonable quality of c++
project
even if you keep the team in the git jail and have the subproject
stakeholders
responsible for their parts.
As I said linux kernel dev tried and failed miserably: c++(compilers)
were not as bloated
with features back then.

But I guess I'm preaching here in vain.

 

[AD]

http://www2.research.att.com/~bs/bs_faq.html#really-say-that
"What people tend to miss, is that what I said there about C++ is to a
varying extent true for all powerful languages. As you protect people
from simple dangers, they get themselves into new and less obvious
problems. Someone who avoids the simple problems may simply be heading
for a not-so-simple one. One problem with very supporting and
protective environments is that the hard problems may be discovered
too late or be too hard to remedy once discovered. Also, a rare
problem is harder to find than a frequent one because you don't
suspect it."

that's a very blanket and vague statement

he should try to get into senate -> being there is all about
saving face and never utter anything remotely resembling
"yes, i fucked up big time: but look at all the suckers
who followed me in my footsteps!"

 

[Victor Bazarov]

[..]
But I guess I'm preaching here in vain.

Stop preaching then and start doing something useful. It's *you* who's
"oozing poison"; the sooner you realize that, the better.

V

 

[Ian Collins]

I don't see how you could maintain any reasonable quality of c++
project

Just because you lack the skills to manage a quality C++ project,
doesn't assume others can't.

But I guess I'm preaching here in vain.

Preaching in ignorance more like.

 

[Rui Maciel]

I'm not coding in C++ ANYMORE
I could not possibly see how it can be used to write robust code

I could not possibly see how matter can consist of arrangements of a dozen
types of sub-atomic particles.

Then again, I'm no particle physicist. So that explains it.

linux kernel developers at one point tried (and failed),
primirily because of the buggy g++ frontend to gcc
and you can really count on your palm c++ compilers that work okay.

Taken from the linux kernel mailing list FAQ:

Why don't we rewrite the Linux kernel in C++?
http://www.tux.org/lkml/#s15-3

They didn't actually failed to write the linux kernel with C++. They only
opted to discontinue to write code that compiled under g++ due to
performance issues.

If you take the time to discover the reasons behind the decision by the
linux kernel team not to use C++ to write kernel code, you will notice that
every single reason they point out is related to the use of C++ to write
kernel code. The keyword here is "kernel code".

Having said that, I'll point out what they state regarding the C++
programming language:

<quote>
My personal view is that C++ has its merits, and makes object-oriented
programming easier. However, it is a more complex language and is less
mature than C. The greatest danger with C++ is in fact its power. It seduces
the programmer, making it much easier to write bloatware. The kernel is a
critical piece of code, and must be lean and fast. We cannot afford bloat. I
think it is fair to say that it takes more skill to write efficient C++ code
than C code. Not every contributer to the linux kernel is an uber-guru, and
thus will not know the various tricks and traps for producing efficient C++
code.
</quote>


Rui Maciel

 

[Jorgen Grahn]

Even letting alone that failing all such code you encounter prevents you from
staying on schedule:

If you do not review but maintain it as in OP case -- what do you do then?

I commented only on your claims about the difficulty of reviewing C++
code (and I seem to have missed that you talked about "reviewing and
maintenance").

I still don't see your argument about reviewing though. If it really
was "it's hard to usefully review changes in code which is already
unreadable" then that's trivially true in any language.

(I decline to discuss the "maintenance" part, not because I agree with
you but because I cannot come up with brief, good arguments at the
moment.)

....

More than a half. People create other classes than standard streams, most of
them having stream-like (but not quite) semantics, for example for IPC purpose,
some with different semantics.

That's a bit unusual, and I don't think I would like it.

An example of the issue is that something like
somestream << "abc" can lead to very different serializations for different
types of the stream depending on whether there is an operator<< with const char
* or some conversion is to be called.

You mentioned these conversions in your earlier posting, too. If you
have a lot those, you have my sympathies. My basic assumption is that
a Foo::Foo(T) which isn't marked 'explicit' is broken. Same with
function overloads with very similar types.

/Jorgen

 

[Ian Collins]

Even letting alone that failing all such code you encounter prevents you from
staying on schedule:

It sounds to me like you have a process problem rather than a language
one. I don't thank anyone can do a thorough job of reviewing anything
other than small sections of unfamiliar code without the involvement of
the authour or someone else familiar with the code.

 

[88888 Dihedral]

Programming in C++ code costs more to maintain. Maybe this is good for offering
more programming positions for the employees. Also problems in C are inherited
in C++ such as the non-closure integer arithmetics and the lousy sort trap
and the famous non-checking for array boundaries in any read/write.
The vetctor part just covers up some traps but it slows down as expected.
The operator reloading and the copy constructor part of derived classes introduce
more problems in any operation that needs a new object in the RHS to be
assigned to the LHS. Of course there are people using C++ without deriving
new classses and just use those libraries in trivial programs.
Then in this cas C++ is easy to mantain.

 

[Jorgen Grahn]

AD wrote: .... ....

Having said that, I'll point out what they state regarding the C++
programming language:

<quote>
My personal view is that C++ has its merits, and makes object-oriented
programming easier. However, it is a more complex language and is less
mature than C. The greatest danger with C++ is in fact its power. It seduces
the programmer, making it much easier to write bloatware. The kernel is a
critical piece of code, and must be lean and fast. We cannot afford bloat. I
think it is fair to say that it takes more skill to write efficient C++ code
than C code. Not every contributer to the linux kernel is an uber-guru, and
thus will not know the various tricks and traps for producing efficient C++
code.
</quote>

That's what the LKLM FAQ maintainer wrote. When /Linus/ writes about
C++, he sounds almost exactly like "AD". That's probably the the first
thing that prevents C++ in the Linux kernel.

/Jorgen