Most annoying aspects of C++

[Victor Bazarov]

[..]
IMHO, this problem would be dramatically reduced if C++
implementations had better diagnostic messages.
For instance, compilers should do a warning when:
1) A pointer to an incomplete type (or the void type) is the static
type of the argument of a delete-expression.
Actually, the behavior is undefined if such statement is executed.
2) A pointer to an abstract class having no virtual destructor is the
static type of the argument of a delete-expression.
Since one can't have instances of an abstract class whose dynamic type
is equal to the static type, behavior is always undefined if such
statement is executed.

These two warning messages would resolve a bit number of UB.
It would also be possible to add a warning message when defining a
class having virtual functions but a public non-virtual destructor
(protected non-virtual destructor and public virtual destructor would
be accepted).

Actually, these two or three warning messages would solve all problems
related to virtual destructors except if one derive from a concrete
class, which is often a bad idea.
However, there are classes which are conceptually abstract (such as
std::binary_function). In that case, such classes should have a
protected destructor (unfortunately, it has a public destructor).
And, it would be possible, for a compiler, to emit a warning message
when deriving from a class which is neither abstract nor have a
protected destructor.
I know, that this message should be sometimes ignored... But, at
least, you know where you do dangerous things.

Well, to me it seems that you're talking about a QoI issue. Why put
the requirement about warning messages in the Standard? Choose the
compiler that gives the warnings you need, talk to the vendors of C++
implementations about what warnings you'd like to see, and you shall
receive. There is also room for PC-lint and the like. There is *no*
need to *require* those things to exist at the language level. C++
specification says "UB". That should be enough.

Besides, it's not really a solution for the "need for virtual d-tors"
problem. It's a work-around. The solution would be if the compiler
did automatic recognition of the fact that the object being destroyed
was originally created as part of a larger object. To do that you
need a virtual d-tor *or* some other mechanism. I see only two
solutions: either d-tors are always virtual or there is some other
way in *run-time* for the program to tell a complete object (so to
speak) from a part, when deleting.

V

 

[REH]

The worst thing about C++ is the syntax! Nobody who has ever programmed in a
Pascal variant language would think C++ has a decent syntax.

Really? I've been writing C++ and Ada for years, and I love C++'s
syntax.

REH

 

[SuperKoko]

Well, to me it seems that you're talking about a QoI issue. Why put
the requirement about warning messages in the Standard? Choose the
compiler that gives the warnings you need, talk to the vendors of C++
implementations about what warnings you'd like to see, and you shall
receive. There is also room for PC-lint and the like.

That was exactly my point!

 

[Luke Meyers]

These are more subjective but, I believe, valid and agreed with by others:

- arcane (sometimes dangerous) semantics in some cases that seem simple

- when static-typing makes you 'jump thru hoops' to do something simple

You should be able to provide at least one example of each of these, if
you want a genuine debate. Otherwise we won't know what you really
mean, and you will be misunderstood, and Victor will swear at you.

- the need to keep so many concepts & types in mind all at once creates
unecessary complexity relative to the problem & reduces productivity

I disagree with this, or at least think it's a proper subset of the
education problem (which I acknowledge, and grind my teeth over at
night). Once one reaches a good level of understanding of the
language, these miscellaneous little issues largely start to seem less
miscellaneous, and become facets of a more cohesive gestalt. Being
able to "think in C++" is not about maintaining a bunch of memorized
state about obscure language mis-features, and never slipping up and
forgetting one. It's about understanding why the language is the way
it is, and working with it in a natural way that causes these various
facets to reinforce each other and exist in Glorious Harmony.

Put another way: C++ is very good at allowing you to say exactly what
you mean. A lot of people get frustrated because they learn how to say
things before they understand exactly what they mean when they say
them. Once you approach the problem from a different perspective --
that is, you've got something you mean to say, you know how that
meaning relates to the way C++ works, and it's just a matter of "how do
I say it" -- it's a lot more natural and less frustrating.

Luke

 

[Ray Gardener]

Static objects, particularly in libraries, can present difficulties.
It's a long-standing catch-22: a custom memory manager can't track
static objects because it can't be guaranteed to be available before any
static objects are allocated.

Not necessarily a C++ issue; any language with globals/statics shares
this problem, unless they have a special runtime box in which to
implement memory managers.

It would be nice if C++ had standard facilities to do wrapped execution,
so I could start a tiny program A that contains the memory manager and
other useful global aspect debug facilities, which then runs huge
program B and when B wants something low-level, A has a chance to
supply/track/report/etc. the resource. I could almost do it with
threads, but it wouldn't be standard and static objects would still be
untracked. The devtool makers consider A the development system or OS,
but I would prefer to have more control over and definition of A.

It would be particularly handy in that a lot of #ifdef DEBUG ... #endif
statements and code could be deprecated. E.g., inside A I could have a
policy such as:

class my_A : public A
{
virtual void func_entrypoint_monitor(function& func)
{
// Called whenever a function in the actual program
// is entered. The code below
// asserts non-nullness for any pointer arg that is
// not indicated in standard comments that it can
// be null.

foreach(arg in func.arglist)
if(arg.type == pointer
&& !func.stdcomments_for(arg).contains(
"can be null"))
assert(arg != NULL);

}
};

This is aspect-oriented programming, and I am currently ignorant of the
current state-of-the-art of it in regards to C++, so I'll stop here.

Ray

 

[Colander]

We all know that C++ is a cleverly conceived multi-paradigm language that

sacrifices very little in efficiency for what it delivers in terms of
type-safety, encapsulation and generic behaviour.

What I want to ask here is - what are the features that people most dislike
about it i.e. that:

- make it more difficult than necessary to implement designs

- introduce subtle bugs

- force the developer to think in counter-intuitive ways

- make managing a software project more troublesome

- make using or producing libraries inconvenient

There may be others. I am not talking about subjective things like syntax,
more concerned with tangible design & software engineering issues.

vector<bool>

 

[ax]

"Most annoying aspects of C++" is that c++ programmers think to be
smart in doing abstractions and "costruzioni barocche" and not see the
essential: how could be good a small obj file and how it is good
understand machine code (assembly) for doing all small and efficient

 

[ax]

Static objects, particularly in libraries, can present difficulties.
It's a long-standing catch-22: a custom memory manager can't track
static objects because it can't be guaranteed to be available before any
static objects are allocated.

Not necessarily a C++ issue; any language with globals/statics shares
this problem, unless they have a special runtime box in which to
implement memory managers.

It would be nice if C++ had standard facilities to do wrapped execution,
so I could start a tiny program A that contains the memory manager and
other useful global aspect debug facilities, which then runs huge
program B and when B wants something low-level, A has a chance to
supply/track/report/etc. the resource.

I could almost do it with
threads, but it wouldn't be standard and static objects would still be
untracked.

i had a problem like that above: free resources for file 'manager' and
memory manager i wrote (in a c++ environment) at the end of program.

But where is the end?

When it is the time that memory manager XXX has no memory for the
prog? (because it is all free and i have to free the resource of that
memory manager [or report the bug there is a memory leak])

destructors have the "track" of all static class objects and seem here
they are the last part of program to be run at end (destructors for
global objects classes).

if in all the destructors for static global objects classes there is a
function that sees if the memory manager XXX has any memory for the
program (it has to see a global int if it is 0 then there is no
memory),

when destructor free the last global class object (or it is possible
first too)(e.g. my definition for file stream cin cout cerr) if there
is not other memory for the program (allocated form memory manager
XXX), that is the time to free all the memory manager (close all the
file i forget open, free all etc)

the compiler i use seems love that above. where i'm wrong?
What i could do better?

 

[Phlip]

"Most annoying aspects of C++" is that c++ programmers think to be
smart in doing abstractions and "costruzioni barocche" and not see the
essential: how could be good a small obj file and how it is good
understand machine code (assembly) for doing all small and efficient

That's premature optimization.

To optimize programmer time, start with a softer language, and use C++ for
the parts that must perform well.

 

[Victor Bazarov]

[..]
"Most annoying aspects of C++" is that c++ programmers think to be
smart in doing abstractions and "costruzioni barocche" and not see the
essential: how could be good a small obj file and how it is good
understand machine code (assembly) for doing all small and efficient

Well, isn't that a characteristic of *any* high-level language?
At some point, in our cruel world of hard competition, time-to-market is
the defining factor. With other things relatively equal, I'd rather be
paid for my product *now* so I can feed myself and my family, and *then*
spend time making it smaller and faster, than not be paid at all because
someone sold their product before I could. It's harder to re-capture
the market than to capture it.

V

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

"Most annoying aspects of C++" is that c++ programmers think to be
smart in doing abstractions and "costruzioni barocche" and not see the
essential: how could be good a small obj file and how it is good
understand machine code (assembly) for doing all small and efficient

I understand assembly, but lacked the need to use it for years. Not
essential at all in the majority of tasks.

And is not an annoying aspect of C++ at all. Maybe the fact that assembler
is not so important as in early years of PC era is that annoys you and
other assembler enthusiasts, not C++.

 

[ax]

[..]
"Most annoying aspects of C++" is that c++ programmers think to be
smart in doing abstractions and "costruzioni barocche" and not see the
essential: how could be good a small obj file and how it is good
understand machine code (assembly) for doing all small and efficient

Well, isn't that a characteristic of *any* high-level language?
At some point, in our cruel world of hard competition, time-to-market is
the defining factor. With other things relatively equal, I'd rather be
paid for my product *now* so I can feed myself and my family, and *then*
spend time making it smaller and faster, than not be paid at all because
someone sold their product before I could. It's harder to re-capture
the market than to capture it.

yes
if not for c++, problem of optimisation is a real problem
i can see this when some program start
when i turn on my PC
when i turn on my telephone
when i turn on my DVD player etc
programs are file too big
they consume too much time for load and start, or doing something
useful.
those programs could be in c++, so optimisation could be a c++
business too.

 

[Kevin Handy]

As opposed to what?

Here is what I think of your current list
[
These are the most annoying aspects of cars, for what it's worth:
- need gas to run
- not enough room to carry all my belongings
- uncomfortable seats
- short warranty leading to expensive repairs later
- going too fast often leads to a speeding ticket
- not enough protection against crashes
- the need to keep many things in mind at once when driving
]

V

- No built-in bathroom
- Doesn't fly (was promised this in the 60's)
- No super-model in the passanger seat, like in the ads.
- No machine gun turrets, nor missle launchers, not even
a single oil-slick generator; like in the Bind films.