C++: The Good and Bad

[Kevin Hall]

C++ is one of my favorite languages to work in. This is because it has
so many differrent strengths. But there is also a number of blemishes
in the language -- some could potentially be fixed, others are not
likely. I wanted to open a discussion on what people think are the
good and bad things about C++. Here are my lists:

Good things about C++
---------------------
- multi-paradigm language.
- const-specifications
- deterministic destruction
- semi-strong typed (since there are some implicit conversions allowed)
- preprocessor -- it's powerful not evil. Powerful things just often
can be used for evil purposes -- and unfortunately, the preprocessor
sometimes is used in evil ways.
- Real multiple inheritance. Again, it's powerful, not evil.
- templates -- more powerful than generics provided by other languages.
- partial template specialization.
- template meta-programming.
- SFINAE, RAII, CRTP
- Is portable to more platforms than most other languages. (This is
due in part to having fewer standard libraries.)


Bad things about C++
--------------------
- Some 'baggage': throw specifications, std::vector<bool>, 'export',
some C-baggage
- No true-typedefs; typedefs are really type aliases.
- A lot of things to learn
- Due to the way C++ has evolved, some things are more complicated than
they need to be.
- Too much undefined behavior.
- No support for properties.
- No standard for name mangling.
- No reflection capabilities.
- No garbage collection. Though, GC is often used incorrectly like the
preprocessor and multiple-inheritance. Also note that there are GC
libraries for C++ -- but there are potentially some advantages to be
gained if GC were added to the language.
- Missing libraries: (though, there are many widely available
cross-platform libraries that do fill in the gaps)
* No standardized threading model/library
* No standard GUI library. However, we should note that standard
GUI's are typically not used for state-of-the-art, fancy looking apps.
The Java standard doesn't support the newest GUI features of OSX,
Windows Vista, OpenGL, or DirectX.
* The standard libraries don't cover some very common things, like
decimal and large-integer types, the ability to handle directory
structures, etc....
* No standard way to obtain stack-traces.

 

[Victor Bazarov]

C++ is one of my favorite languages to work in. This is because it
has so many differrent strengths. But there is also a number of
blemishes in the language -- some could potentially be fixed, others
are not likely. I wanted to open a discussion on what people think
are the good and bad things about C++. Here are my lists:

Good things about C++
---------------------
- multi-paradigm language.
- const-specifications
- deterministic destruction
- semi-strong typed (since there are some implicit conversions
allowed)

Is that a good thing? If it is, why is "semi-" a good thing? Would
plain strong typing with all conversions explicit be a better thing?

- preprocessor -- it's powerful not evil. Powerful things just often
can be used for evil purposes -- and unfortunately, the preprocessor
sometimes is used in evil ways.

I don't believe the preprocessor is powerful enough.

- Real multiple inheritance. Again, it's powerful, not evil.

Is there any other kind besides "real"? What other multiple inheritance
can there be?

- templates -- more powerful than generics provided by other
languages.

Oops... Did you mean to compare languages here? Read the FAQ.

- partial template specialization.
- template meta-programming.
- SFINAE, RAII, CRTP
- Is portable to more platforms than most other languages. (This is
due in part to having fewer standard libraries.)

Not only libraries. Absence of explicitly sized types plays big part
in that too.

Bad things about C++

Hos is C baggage a bad thing? Have you any idea how much code was
possible to simply bring over, compile and never worry?

- No true-typedefs; typedefs are really type aliases.

Not sure what you mean here. What "true" typedefs do you need?

- A lot of things to learn

You don't need a lot of things to learn. See advantage #1, you only
need to learn what you're going to apply.

- Due to the way C++ has evolved, some things are more complicated
than they need to be.

Like what? Keep in mind the need to provide backward compatibility.

- Too much undefined behavior.

What would you do instead? Define it and limit the chances for
optimizers to work, or define it and limit the number of platforms
C++ would be possible to implement on?

- No support for properties.

What do you mean?

- No standard for name mangling.

Why would you need it? C++ is source-code portable. Why would you
need standard in name mangling?

- No reflection capabilities.

You mean, built-in, right? Well, how much do you need provided for
you? After all, what are the programmers for?

- No garbage collection. Though, GC is often used incorrectly like
the preprocessor and multiple-inheritance. Also note that there are
GC libraries for C++ -- but there are potentially some advantages to
be gained if GC were added to the language.

Like what, for example?

- Missing libraries: (though, there are many widely available
cross-platform libraries that do fill in the gaps)
* No standardized threading model/library

There isn't any across as many platforms as C++ covers.

* No standard GUI library. However, we should note that standard
GUI's are typically not used for state-of-the-art, fancy looking apps.
The Java standard doesn't support the newest GUI features of OSX,
Windows Vista, OpenGL, or DirectX.

Again, it would only be applicable to a very few platforms. Why
would you want to define something that cannot be used everywhere
where the language can be used?

* The standard libraries don't cover some very common things, like
decimal and large-integer types, the ability to handle directory
structures, etc....

What's a decimal type? Large-integer types are platform-specific,
and C++ doesn't prohibit their existence. Most implementations have
some additional types provided, and they work just fine. Making
those part of the language is simply impossible without sacrificing
the ability of the compilers to do what they need to optimize the
programs.

* No standard way to obtain stack-traces.

And why do you need that? Isn't that what the debuggers are for?

It all sounds like you've lived too much in <insert your interpreted
language here> land. Snap out of it!

V

 

[Ian Collins]

Why would you need it? C++ is source-code portable. Why would you
need standard in name mangling?

I can go along with this one, try linking library X built with compiler
A into an application built with compiler B.

<OT> As a real example, look at KDE, a great desktop, but if you want to
build something to link into its libraries, or Qt, you have to use the
same compiler that was used to build them. </OT>

 

[Kevin Hall]

If it is, why is "semi-" a good thing? Would
plain strong typing with all conversions explicit be a better thing?

There are some implicit conversions which are OK (integer to double
conversion for example). But I appreciate the strong typing elsewhere.

I don't believe the preprocessor is powerful enough.

Yes, it can be more powerful. C99 brings a tiny bit more power. But
something more powerful that is standardized would be nice.

Is there any other kind besides "real"? What other multiple inheritance
can there be?

Yes, there are many people that say inheriting multiple interfaces is a
type of MI and is good enough (some even say it's better). I disagree.

Oops... Did you mean to compare languages here? Read the FAQ.

Not in the sense of 'what is better -- language X or C++'. But if
something can be learned from features implemented in other languages,
then so be it. (Besides, there is no 'official' FAQ for this
unmoderated group -- despite what some FAQs claim. This was discussed
not too long ago in this forum.)

Absence of explicitly sized types plays big part in that too.

Hos is C baggage a bad thing? Have you any idea how much code was
possible to simply bring over, compile and never worry?

Please note that I said 'some' -- not all. I think that backwards
compatibility with C is a wonderful thing. But as we all know, C++ is
not 100% compatible with C. '\0' is a char in C++, whereas it is a int
in C.

Anyway, I'm having trouble thinking of the examples of the top of my
head, but there are some things inherited from C that are more vexing
(to me anyway) than if that compatibility had been dropped.

Not sure what you mean here. What "true" typedefs do you need?

"true typedefs" means that a typedef and its base type are different
types in the language type-system. In otherwords: 'bar Foo(bar);' and
'int Foo(int);' describe two different functions if bar is typedef'ed
as an int.

There are many articles online and parts of books written about "true"
typedefs. Here's one online reference (look halfway down the page):
http://www.artima.com/cppsource/typesafety3.html

You don't need a lot of things to learn. See advantage #1, you only
need to learn what you're going to apply.
True.


Like what? Keep in mind the need to provide backward compatibility.

I understand backward compatibility is a good thing. Nevertheless,
there are downsides to it too. std::vector<bool>. is one such example.
As far as I can tell, it was known before the standard was finally
released that std::vector<bool> could not fully act like a container,
but it was kept anyway. And if you really need a genuine vector of
booleans then you have to jump through hoops to get one.

What would you do instead? Define it and limit the chances for
optimizers to work, or define it and limit the number of platforms
C++ would be possible to implement on?

I said 'too much', not 'C++ has UB'. Even people on the standards
comittee and other people commonly held up as C++ experts like
Alexandrescu say there is *too much* UB.

I don't argue that some UB is needed.

What do you mean?

See MS's __declspec(property):
http://msdn2.microsoft.com/en-us/library/yhfk0thd(VS.80).aspx

Again, there are many articles and chapters of books written on how to
simulate properties to C++.

Why would you need it? C++ is source-code portable. Why would you
need standard in name mangling?

To support inter-compiler libraries, a standard way for other languages
to tap into C++'s APIs. Other languages usually can only tap into
functions declared as 'extern "C"'. If there were a standard for name
mangling, then it would be easier to tap into C++ interfaces.

You mean, built-in, right? Well, how much do you need provided for
you? After all, what are the programmers for?

Yes, I meant built-in. Reflection would make some things a lot easier
-- for example finding the names of enumeration values.

Like what, for example?

COW strings (and other COW objects) would be easier to implement.

Again, it would only be applicable to a very few platforms. Why
would you want to define something that cannot be used everywhere
where the language can be used?

There are advantages to defining something that can't be used
everywhere. If you need to do something, and that something is
available, then there is a standard way to use it. The POSIX standard
is very popular, but it can't be used everywhere.

Some other languages have thrived on having standard GUIs -- even
though the look and feel of those GUIs seem quite dated.

What's a decimal type?
http://www.google.com/search?hl=en&...=0&ct=result&cd=1&q=decimal+data+type&spell=1.

Large-integer types are platform-specific,
and C++ doesn't prohibit their existence. Most implementations have
some additional types provided, and they work just fine. Making
those part of the language is simply impossible without sacrificing
the ability of the compilers to do what they need to optimize the
programs.

Why would it sacrifice the ability of compiler to do what they need to
optimize the programs?

And why do you need that? Isn't that what the debuggers are for?

*sigh*... stack-traces are very useful for logging in applications that
are released to customers. When attached to exceptions, they are also
very useful in tracking down intermittent errors customers experience.

 

[Pete Becker]

I can go along with this one, try linking library X built with compiler
A into an application built with compiler B.

Which is why having different name mangling is good. Unless, of course,
you also want to standardize object layout. That's a much bigger job.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[Cesar Rabak]

Pete Becker escreveu:

Which is why having different name mangling is good. Unless, of course,
you also want to standardize object layout.
Yes! Why not?
> That's a much bigger job.

But worth of it!

 

[Noah Roberts]

Pete Becker escreveu:
Yes! Why not?

Because, the C++ standard makes a great point of not standardizing too
much. If object layout was standardized, beyond the minimum that it is,
then first of all the standard would become much larger and it would
take longer to release. Second, and more importantly, if the object
layout was specified by the standard then that is the object layout
everyone would have to use...whether it is good for the platform or not.
With the additional time it would take to specify a standard we would
have a situation in which we're stuck with an object layout based on
obsolete understandings and hardware for 20+ years.

By specifying such details the C++ standard would quickly become rigid
and unresponsive to change. The language would become obsolete very
quickly.

 

[.rhavin grobert]

Bad things about C++

i would add the fact i can ask whether a definition is defined but
cant ask if a type is defined ... really nasty and senseless.

 

[Grizlyk]

C++ is one of my favorite languages to work in. This is because it has
so many differrent strengths.

This is because no other languages in the world, that can be used as C++ and
because it is easyer to everybody to continue apply old language instead of
new one.

But there is also a number of blemishes
in the language -- some could potentially be fixed, others are not
likely. I wanted to open a discussion on what people think are the
good and bad things about C++.

C++ has many "holes" and "bad places", and at least ten big of them known
for me. All of them can be easy eliminated.

 

[Grizlyk]

C++ has many "holes" and "bad places", and at least ten big of them known

for me. All of them can be easy eliminated.

Ñan be easy eliminated by C++ standard and compiler improvements, not by
programmers.

 

[Cesar Rabak]

Noah Roberts escreveu:

Pete Becker escreveu:

[snipped]

Yes! Why not?

Because, the C++ standard makes a great point of not standardizing too
much. If object layout was standardized, beyond the minimum that it is,
then first of all the standard would become much larger and it would
take longer to release.

Yes this is part of the price to pay.

Second, and more importantly, if the object
layout was specified by the standard then that is the object layout
everyone would have to use...whether it is good for the platform or not.

Couldn't the standard propose a way of going for a standard per
platform, then?

The present status is somewhat more awkward IMNSHO: if you want to have
any chance to supply a library written in C++ the API has to be in C
(not C++) due the non existance of an ABI for C++.

So we get to a funny situation where we have a proposal from the
Standard intended to foster portability, but that hinders code reuse!

With the additional time it would take to specify a standard we would
have a situation in which we're stuck with an object layout based on
obsolete understandings and hardware for 20+ years.

Yes. We need to have faster turn around times for the Standard, or this
argument would be forever a showstopper.

By specifying such details the C++ standard would quickly become rigid
and unresponsive to change. The language would become obsolete very
quickly.

I don't think I agree totally with this either. Newer architectures are
hard to come by. From the last issuing of the Standard, how many
_really_ new architectures have appeared to give statistical substance
to this argument?

We still have compiler vendors struggling with some aspects of the
standard¹, meanwhile a lot of vendors seem to loose interest in C++ and
produce variants which may already be a signal of the obsolescence you
mention as a thing to avoid.

Regards,

 

[Ian Collins]

Which is why having different name mangling is good. Unless, of course,
you also want to standardize object layout. That's a much bigger job.

C also lacks a standard ABI, but each platform has its own. With C++,
we don't even have that.

I guess the only contentious aspect of object layout is the virtual
dispatch mechanism.

 

[Noah Roberts]

Noah Roberts escreveu:

Couldn't the standard propose a way of going for a standard per
platform, then?

You mean per implementation? That's what we have. What you really want
isn't going to be much, if any, better. You would still have no real
way to change later if you wanted to.

The present status is somewhat more awkward IMNSHO: if you want to have
any chance to supply a library written in C++ the API has to be in C
(not C++) due the non existance of an ABI for C++.

There are several standards that do explain methods to interoperate,
including COM, CORBA, etc... The dll interface is know as well, as is
ELF on Linux. So any implementation can choose to interoperate with
other compiler writers in this regard. MinGW can use VC++ dlls and can
create them.

So we get to a funny situation where we have a proposal from the
Standard intended to foster portability, but that hinders code reuse!

If you want something that is going to be super portable, where it's all
spelled out as you are suggesting, there is C# or Java, among others,
that answer this requirement. C++ doesn't really need to as it serves a
different purpose. C++ isn't a really super portable language and is
meant to foster a more implementation specific coding style. You can
certainly write portable code, but that isn't the goal of the design of
the language, nor should it be.

 

[Greg Herlihy]

you also want to standardize object layout. That's a much bigger job.

Sharing a class interface does not require sharing the class object
layout as well. Just as long as the class implementation is
encapsulated within a single binary, the class interface can be
distributed at will. Clients of this class simply need a pointer to a
class object (obtained from the class library) and the name and
parameters of its methods. In particular, clients do not need to know
anything about how the class is laid out in memory. To its clients, a
class object pointer is "opaque." In fact, COM employs this very
strategy in order for software components to interoperate.

Greg

 

[Pete Becker]

Sharing a class interface does not require sharing the class object
layout as well. Just as long as the class implementation is
encapsulated within a single binary, the class interface can be
distributed at will. Clients of this class simply need a pointer to a
class object (obtained from the class library) and the name and
parameters of its methods. In particular, clients do not need to know
anything about how the class is laid out in memory. To its clients, a
class object pointer is "opaque." In fact, COM employs this very
strategy in order for software components to interoperate.

Yup. And COM is a C interface.

More generally, confining yourself to opaque types puts some fairly
severe constraints on what those types have to look like to users. No
inline functions, no compiler-generated member functions, no
inheritance, no templates. In fact, just about the only benefit from
providing a C++ interface instead of a C interface is that you can
overload functions. But since an interface like that is so close to C,
it's probably better to just write it in C, rather than make it unusable
to C programmers.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[u.int.32.t]

A into an application built with compiler B.

Lets all this what it is: lack of a standardized ABI for C++. Though I
*think* someone has developed one for the Linux world, which is better
than nothing. I think it would be difficult to develop one in general
for all platforms.

Windows has COM for this purpose (among others).

 

[Victor Bazarov]

[...C++: many things are amiss...]

[...Why do they need to be part of the language?...]

[...because:...]

There are advantages to defining something that can't be used
everywhere. If you need to do something, and that something is
available, then there is a standard way to use it. The POSIX standard
is very popular, but it can't be used everywhere.

Think of it for a second. Why would you need those things to be
standardised as part of C++ _language_, when they can happily live
and be used standardised _outside_ of C++. Use POSIX to explain.

[..]

V

 

[Z.Meson]

standardised as part of C++ _language_, when they can happily live
and be used standardised _outside_ of C++. Use POSIX to explain.

Let's take a look at the current C++ standard. Many parts of the
standard library:
* cannot be supported on all platforms
* but can be happily standardized elsewhere by some other standard
* yet are common enough operations that they ended up being
standardized

One example that pops in my mind is file I/O, standard out, standard
in, and standard error. There many, many embedded systems that don't
support any of those. There are also many windowing platforms that do
not support standard out nor standard error. The C++ compilers on
many of those systems are very compliant on parts of the standard that
they can implement though.

I think that there is a large set of functionality that isn't covered
by the C++ standard that also happens to fall into the same category.
Handling and navigating directories is one example. Threading
primitives (like those found in boost) are another.

If the C++ standard only covered language syntax and did not provide
useful libraries, then C++ would not be as good nor as popular
language as it is today. I just think that the number of useful
libraries can be expanded. (Incidentally, so does the C++ comittee --
they have been calling for proposals on XML, Unicode, and several
other libraries.)

- Kevin