By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,261 Members | 1,325 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,261 IT Pros & Developers. It's quick & easy.

Most annoying aspects of C++

P: n/a


Hi all

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.

Michael
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

_/ _/ _/_/_/ Hopkins Research Ltd
_/ _/ _/ _/
_/_/_/_/ _/_/_/ http://www.hopkins-research.com/
_/ _/ _/ _/
_/ _/ _/ _/ 'touch the future'

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Jun 15 '06 #1
Share this Question
Share on Google+
52 Replies


P: n/a

Michael Hopkins wrote:
Hi all

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.

Michael
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

_/ _/ _/_/_/ Hopkins Research Ltd
_/ _/ _/ _/
_/_/_/_/ _/_/_/ http://www.hopkins-research.com/
_/ _/ _/ _/
_/ _/ _/ _/ 'touch the future'

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/


one could be the 'long time' it takes to learn/master .

Jun 15 '06 #2

P: n/a
Michael Hopkins wrote, On 15.6.2006 8:43:

Hi all

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 I don't think that either of these is true.

- make using or producing libraries inconvenient This one is arguable.

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

Michael


--
VH
Jun 15 '06 #3

P: n/a
In article <C0****************************@hopkins-research.com>,
Michael Hopkins <mi*************@hopkins-research.com> wrote:
Hi all

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.


This has the makings of a flame war. You are asking the people who love
the language most to dis it... :-)

The "feature" I most dislike is wild pointers. The fact that they can be
created, and the fact that there is no language facility to track them
down.
Jun 15 '06 #4

P: n/a

Daniel T. schrieb:
In article <C0****************************@hopkins-research.com>,
Michael Hopkins <mi*************@hopkins-research.com> wrote:
Hi all

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.
This has the makings of a flame war. You are asking the people who love
the language most to dis it... :-)


I think this *is* the right place for this question. The question is
not to say the language is bad. But how it could made better.
- make it more difficult than necessary to implement designs


Especially the 'than necessary' part. You need to know the language
well to know what is actually 'necessary'.

The "feature" I most dislike is wild pointers. The fact that they can be
created, and the fact that there is no language facility to track them
down.


What is a wild pointer? A raw pointer? Then I say: It is necessary.

It is not the language, but the programmer who uses the pointer. You
are free to define any kind of intelligent pointer, even a garbage
collection. And in fact other have done so for you already.

Actually I just realized that it is indeed difficult to answer this
question.
I have written some points, but then realized, that I proposed new
features instead of talking about disliked features. So I removed them
again.

The things I dislike are indeed syntax issues. But they are explicitly
excluded here.

So, which feature could be disliked? If I don't like a feature, who
forces me to use it???

Ingo

Jun 15 '06 #5

P: n/a
On 15/6/06 12:24, in article
da****************************@news....arthlink .net, "Daniel T."
<da******@earthlink.net> wrote:

This has the makings of a flame war. You are asking the people who love
the language most to dis it... :-)

The "feature" I most dislike is wild pointers. The fact that they can be
created, and the fact that there is no language facility to track them
down.


Not looking for flame war here but genuine & open debate from people who
already use it.

My current list, for what it's worth:

- slicing & schizophrenic polymorphism

- what compiler does 'behind the scenes' with no documentation in code

- the need for virtual destructors

- error messages from template (i.e. STL) code
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

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

_/ _/ _/_/_/ Hopkins Research Ltd
_/ _/ _/ _/
_/_/_/_/ _/_/_/ http://www.hopkins-research.com/
_/ _/ _/ _/
_/ _/ _/ _/ 'touch the future'

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Jun 15 '06 #6

P: n/a
Michael Hopkins wrote:
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


Read my seminal paper on the topic, called "Where in memory do you want to
accidentally jump today?"

http://groups.google.com/group/comp....3877533bd360d2
aka
http://tinyurl.com/k2kmy

The replies are also valid, but none of them defeat the main points. C++
sacrifices much programmer efficiency in exchange for a thin margin of CPU
efficiency...

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jun 15 '06 #7

P: n/a
Michael Hopkins wrote:
On 15/6/06 12:24, in article
da****************************@news....arthlink .net, "Daniel T."
<da******@earthlink.net> wrote:

This has the makings of a flame war. You are asking the people who
love the language most to dis it... :-)

The "feature" I most dislike is wild pointers. The fact that they
can be created, and the fact that there is no language facility to
track them down.
Not looking for flame war here but genuine & open debate from people
who already use it.


Bullshit!
My current list, for what it's worth:
Doesn't seem to be worth much...
- slicing & schizophrenic polymorphism
What's that mean? I am vaguely familiar with the term schizophrenia,
but how does it apply to polymorphism?
- what compiler does 'behind the scenes' with no documentation in code
Why do you care? And if you do care, couldn't you ask your compiler
vendor for that? You know, every compiler does different things there.
- the need for virtual destructors
Huh? What's the alternative? Virtual d-tors for every class? Or some
other RTTI mechanism to slow everything down?
- error messages from template (i.e. STL) code
What error messages? Are you confusing the language design with the
quality of the iplementation you're using?
These are more subjective but, I believe, valid and agreed with by
others:

- arcane (sometimes dangerous) semantics in some cases that seem
simple
Example, kindly please.
- when static-typing makes you 'jump thru hoops' to do something
simple
To do what, for instance?
- the need to keep so many concepts & types in mind all at once
creates unecessary complexity relative to the problem & reduces
productivity


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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 15 '06 #8

P: n/a
* Phlip:
Michael Hopkins wrote:
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


Read my seminal paper on the topic, called "Where in memory do you want to
accidentally jump today?"

http://groups.google.com/group/comp....3877533bd360d2
aka
http://tinyurl.com/k2kmy


You write about C++, "This newsgroup gets a dozen questions per month
asking how to do something that a scripting language can do".

Is it really true that they ask C++ questions in cljp?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jun 15 '06 #9

P: n/a
Michael Hopkins <mi*************@hopkins-research.com> wrote:
What I want to ask here is - what are the features that people most dislike
about it i.e. that:


The fact that exception specifications exist, but are essentially
worthless for the purposes that a reasonable programmer might attempt
to use them, is not a particularly endearing quality of the language.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Jun 15 '06 #10

P: n/a
On 15/6/06 15:15, in article e6**********@news.datemas.de, "Victor Bazarov"
<v.********@comAcast.net> wrote:

This has the makings of a flame war. You are asking the people who
love the language most to dis it... :-)

The "feature" I most dislike is wild pointers. The fact that they
can be created, and the fact that there is no language facility to
track them down.
Not looking for flame war here but genuine & open debate from people
who already use it.


Bullshit!

Looks like someone _does_ want a flame war - maybe to obscure the original
intention of uncovering and discussing the issues themselves?
My current list, for what it's worth:


Doesn't seem to be worth much...
- slicing & schizophrenic polymorphism


What's that mean? I am vaguely familiar with the term schizophrenia,
but how does it apply to polymorphism?

I'm not certain but I believe the term was coined by one Scott Meyers who
has some background in C++.
- what compiler does 'behind the scenes' with no documentation in code


Why do you care?


Because all other widely-used languages are self-documenting in this sense.
And if you do care, couldn't you ask your compiler
vendor for that? You know, every compiler does different things there.

That is missing the point, I think.
- the need for virtual destructors


Huh? What's the alternative? Virtual d-tors for every class? Or some
other RTTI mechanism to slow everything down?

Something like that, yes - to ensure no nasty surprises and allow general
derivation with an infinitessimal effect on runtime performance.
- error messages from template (i.e. STL) code


What error messages? Are you confusing the language design with the
quality of the iplementation you're using?

Possibly, but templates make it difficult to see how the situation can
improve e.g. the apparent impossibility of implementing template definitions
in .cpp files and exporting them as defined in the standard many years ago.
These are more subjective but, I believe, valid and agreed with by
others:

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


Example, kindly please.
- when static-typing makes you 'jump thru hoops' to do something
simple


To do what, for instance?
- the need to keep so many concepts & types in mind all at once
creates unecessary complexity relative to the problem & reduces
productivity


As opposed to what?

If you don't already know what I mean with these then I suspect my thoughts
are falling on deaf ears.

M
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

_/ _/ _/_/_/ Hopkins Research Ltd
_/ _/ _/ _/
_/_/_/_/ _/_/_/ http://www.hopkins-research.com/
_/ _/ _/ _/
_/ _/ _/ _/ 'touch the future'

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Jun 15 '06 #11

P: n/a
Phlip wrote:
Michael Hopkins wrote:
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


Read my seminal paper on the topic, called "Where in memory do you want to
accidentally jump today?"

http://groups.google.com/group/comp....3877533bd360d2
aka
http://tinyurl.com/k2kmy

The replies are also valid, but none of them defeat the main points. C++
sacrifices much programmer efficiency in exchange for a thin margin of CPU
efficiency...


Care to explain why the TopCoder algorithm competitions are then
completely dominated by C++ (3 of the top 20 coders use something else
than C++)?

These contests focus solely on programmer efficiency i.e. who
implements a working algorithm for a given problem in the shortest
time. Run-time performance is mostly irrelevant.

Jun 15 '06 #12

P: n/a
Michael Hopkins wrote:
- make it more difficult than necessary to implement designs
- force the developer to think in counter-intuitive ways
- make managing a software project more troublesome


Manual management of header file includes is a fine example of all three
of these weaknesses. I would like an option to have the compiler
analyze the header file and include as necessary, in the necessary order.

--
Scott McPhillips [VC++ MVP]

Jun 15 '06 #13

P: n/a
Michael Hopkins wrote:
What I want to ask here is - what are the features that people most
dislike about it i.e. that: (snip) - force the developer to think in counter-intuitive ways


I think that for a bunch of people the worse part is just "force the
developer to think".

--
Salu2

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Jun 15 '06 #14

P: n/a
Markus Schoder wrote:
Care to explain why the TopCoder algorithm competitions are then
completely dominated by C++ (3 of the top 20 coders use something else
than C++)?


That represents small unscaled programs, written using fire-and-forget
techniques, right?

In general this is a Stockholm Syndrome situation. If you have been abused
enough, you reliably blame yourself and not the abuser...

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jun 15 '06 #15

P: n/a
Julián Albo wrote:
I think that for a bunch of people the worse part is just "force the
developer to think".


Right - force them to think about things unrelated to the current task.

The best accolade a programming language could get here would be "stays out
of your way".

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jun 15 '06 #16

P: n/a
Daniel T. <da******@earthlink.net> wrote:
Michael Hopkins <mi*************@hopkins-research.com> wrote:
What I want to ask here is - what are the features that people
most dislike about it

This has the makings of a flame war. You are asking the people
who love the language most to dis it... :-) The "feature" I most dislike is wild pointers. The fact that
they can be created, and the fact that there is no language
facility to track them down.


Well, relative to C, C++ is featureful enough that you can
get by without a lot of pointer usage. The standard containers,
and all the features involving references help alot.

To answer the original question, my observation -- I can't really
call it a complaint -- is that C++ really depends on a
certain specific model of how things link, but this is abstracted
into a set of superficially unrelated language features.
It's not a bad thing however.

Steve
Jun 15 '06 #17

P: n/a
Phlip wrote:
The best accolade a programming language could get here would be "stays
out of your way".


The best will be want a programming language that have just an instruction:
do_want_i_want_now_fast

In the meantime, you can hire a programmer.

--
Salu2

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Jun 15 '06 #18

P: n/a
Phlip wrote:
Markus Schoder wrote:
Care to explain why the TopCoder algorithm competitions are then
completely dominated by C++ (3 of the top 20 coders use something else
than C++)?
That represents small unscaled programs, written using fire-and-forget
techniques, right?


Pretty much yes. It often requires modelling of fairly complex data
structures though.

There is also a category called marathon matches that focuses on larger
scale problems and gives participants several days for implementation.
Also completely C++ dominated.
In general this is a Stockholm Syndrome situation. If you have been abused
enough, you reliably blame yourself and not the abuser...


Given that according to the TIOBE index Java is the single most active
programming language and gaining quickly and most TopCoder participants
are students you might want to rethink your line of argumentation.

Jun 15 '06 #19

P: n/a

Michael Hopkins wrote:
What I want to ask here is - what are the features that people most dislike
about it


To me the single biggest problem is also what allowed it to get adopted
so quickly and that is C libraries.

To me, when I'm writing C++ a 'new' is just about acceptable but a
'delete' really isn't. I've had to work with too many APIs and
libraries that are designed for C and they're always a nightmare.

There are some other things I would like to see, a stronger version of
'typedef' which isn't just a synonym. And I'd like some better template
features so that I can do even more with them, but those are tiny
problems compared to interoperating with C libraries/APIs.
K

Jun 15 '06 #20

P: n/a

"For me, the most annoying aspects of C++ are:

- It's hard to spell.
- It's not Delphi (or Java, or VB).
- There's always that terrible nagging fear that, should I invoke Undefined
Behavior (TM), my hard drive might catch fire, my email system send nasty
messages to my boss, or I could accidently launch a Titan III missile at
China, starting World War 3.

Oh yeah, there's that annoying part about getting paid too much, too...

-Howard

Jun 15 '06 #21

P: n/a
Kirit Sælensminde wrote:
Michael Hopkins wrote:
What I want to ask here is - what are the features that people most dislike
about it


To me the single biggest problem is also what allowed it to get adopted
so quickly and that is C libraries.

To me, when I'm writing C++ a 'new' is just about acceptable but a
'delete' really isn't. I've had to work with too many APIs and
libraries that are designed for C and they're always a nightmare.

There are some other things I would like to see, a stronger version of
'typedef' which isn't just a synonym. And I'd like some better template
features so that I can do even more with them, but those are tiny
problems compared to interoperating with C libraries/APIs.


While I would agree that using C libraries can be a pain I fail to see
why this is a problem with C++.

Would you rather not be able to use C libraries at all? Or through some
convoluted mess as e.g. Java's JNI?

Or is this really about not enough C++ libraries being available.

Jun 15 '06 #22

P: n/a
"Kirit Sælensminde" <ki****************@gmail.com> wrote in message
news:11**********************@f6g2000cwb.googlegro ups.com...
There are some other things I would like to see, a stronger version of
'typedef' which isn't just a synonym.


check out the D language...
http://www.digitalmars.com/d/overview.html

pay attention to real typedef section
Jun 15 '06 #23

P: n/a

"Michael Hopkins" <mi*************@hopkins-research.com> wrote in message
news:C0B6C008.1A409%mi*************@hopkins-research.com...


Hi all

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.

Michael
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

_/ _/ _/_/_/ Hopkins Research Ltd
_/ _/ _/ _/
_/_/_/_/ _/_/_/ http://www.hopkins-research.com/
_/ _/ _/ _/
_/ _/ _/ _/ 'touch the future'

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/


Interesting that I didn't see this in the first few posts:

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. How many
problems discussed in this newsgroup are directly related to the weird
syntax? "That isn't a variable declaration, that is a prototype of a
function!" doh

Cy
Jun 15 '06 #24

P: n/a
Cy Edmunds <sp***************@rochester.rr.com> wrote:
There may be others. I am not talking about subjective things like
syntax,
Interesting that I didn't see this in the first few posts: The worst thing about C++ is the syntax!


Perhaps because OP was specifically not interested?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Jun 15 '06 #25

P: n/a

Markus Schoder wrote:
Kirit Sælensminde wrote:
To me the single biggest problem is also what allowed it to get adopted
so quickly and that is C libraries.

While I would agree that using C libraries can be a pain I fail to see
why this is a problem with C++.

Would you rather not be able to use C libraries at all? Or through some
convoluted mess as e.g. Java's JNI?

Or is this really about not enough C++ libraries being available.


As I say, I think the ability to use C libraries gave the language a
lot of possibilities at the start. I just think it's a shame that too
many libraries are still created with a C mentality when I suspect (I
have no evidence for this) that most people these days are using C++
compilers (ather than C only compilers).

I've been a big fan of the STL and the Boost libraries ever since I
started using them nearly ten years ago. These are proper C++
libraries. Even Microsoft's ATL is pretty good given the nightmare that
COM is. But look at what they did with ISAPI. It's a horror of C calls.
And then there's the examples of "proper code" they put up on web sites
which have horrid bugs in them because they've decided that exceptions
don't belong. Eugh!

Anyway, must /rant :-)

In short, C++ libraries can be done really well or they can just be "a
better C". But, the fact that you can easily use old C libraries
without too much trouble is great. I'd still prefer better C++ versions
though.

Jun 15 '06 #26

P: n/a

Victor Bazarov wrote:
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
]


LOL! Exactly!

Jun 15 '06 #27

P: n/a
> Nobody who has ever programmed in a Pascal variant language would think C++ has a decent syntax.

I've programmed in a Pascal variant language, and I think C++' has a
decent syntax. Thus what you've posted has been proven false.

-Brian

Jun 15 '06 #28

P: n/a

filox wrote:
"Kirit Sælensminde" <ki****************@gmail.com> wrote in message
news:11**********************@f6g2000cwb.googlegro ups.com...
There are some other things I would like to see, a stronger version of
'typedef' which isn't just a synonym.


check out the D language...
http://www.digitalmars.com/d/overview.html

pay attention to real typedef section


I'm not sure I'm ready to trade in my C++ for a D compiler - although I
admit to knowing nothing about D.

The committee went to all the trouble of introducing a new keyword,
typename, and then only using it in a few places. Using that for a
nonsynonymous typedef would be great (although I think the names would
be the wrong way around there's no changing that without breaking a lot
of legacy code).

Jun 15 '06 #29

P: n/a
BigBrian wrote:
Nobody who has ever programmed in a Pascal variant language would think
C++ has a decent syntax.


I've programmed in a Pascal variant language, and I think C++' has a
decent syntax. Thus what you've posted has been proven false.


I think nobody who has programmed in a language with a decent syntax would
think C++ has a decent syntax.

<a beat>

Unfalsifiability strikes again!

--
Phlip

Jun 15 '06 #30

P: n/a
On Thu, 15 Jun 2006 07:43:04 +0100, Michael Hopkins
<mi*************@hopkins-research.com> wrote:
What I want to ask here is - what are the features that people most dislike
about it i.e. that:


You guys (my fellow posters) do realize he's going to take this data
and use it to prove Java is the better language, right.

To paraphrase an old communist saying: "Don't worry about the west,
they will sell us the rope we will hang them with."

Not to mention you guys are doing his work for him.

"To perceive is to suffer." - Aristotle.
Jun 15 '06 #31

P: n/a
Kirit Sælensminde wrote:
filox wrote:
"Kirit Sælensminde" <ki****************@gmail.com> wrote in message
news:11**********************@f6g2000cwb.googlegro ups.com...
There are some other things I would like to see, a stronger version
of 'typedef' which isn't just a synonym.
[...]
The committee went to all the trouble of introducing a new keyword,
typename, and then only using it in a few places. Using that for a
nonsynonymous typedef would be great (although I think the names would
be the wrong way around there's no changing that without breaking a
lot of legacy code).


Care to start a discussion on it in 'comp.std.c++'?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 15 '06 #32

P: n/a
On 15/6/06 19:18, in article 1o********************************@4ax.com,
"JustBoo" <Ju*****@BooWho.com> wrote:
On Thu, 15 Jun 2006 07:43:04 +0100, Michael Hopkins
<mi*************@hopkins-research.com> wrote:
What I want to ask here is - what are the features that people most dislike
about it i.e. that:


You guys (my fellow posters) do realize he's going to take this data
and use it to prove Java is the better language, right.

To paraphrase an old communist saying: "Don't worry about the west,
they will sell us the rope we will hang them with."

Not to mention you guys are doing his work for him.


I have no interest in Java - why are you so paranoid?

M
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

_/ _/ _/_/_/ Hopkins Research Ltd
_/ _/ _/ _/
_/_/_/_/ _/_/_/ http://www.hopkins-research.com/
_/ _/ _/ _/
_/ _/ _/ _/ 'touch the future'

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Jun 15 '06 #33

P: n/a
Michael Hopkins wrote:
On 15/6/06 19:18, in article 1o********************************@4ax.com,
"JustBoo" <Ju*****@BooWho.com> wrote:
On Thu, 15 Jun 2006 07:43:04 +0100, Michael Hopkins
<mi*************@hopkins-research.com> wrote:
What I want to ask here is - what are the features that people most dislike
about it i.e. that:


You guys (my fellow posters) do realize he's going to take this data
and use it to prove Java is the better language, right.

To paraphrase an old communist saying: "Don't worry about the west,
they will sell us the rope we will hang them with."

Not to mention you guys are doing his work for him.


I have no interest in Java - why are you so paranoid?


May we then with all due respect ask what the reason for your question
is?

Jun 15 '06 #34

P: n/a
Michael Hopkins wrote:
- error messages from template (i.e. STL) code.
This is an acknowledged problem.

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


This is a result of a desire to catch errors at compile time rather
than runtime. Its an inevitable result of large complex software
systems with a high performance requirement.

Both these issues have had a bearing on what I think wil be the future
of C++... Check this out:

http://www.generic-programming.org/software/ConceptGCC/

regards
Andy Little

Jun 15 '06 #35

P: n/a
On 15/6/06 20:20, in article
11********************@r2g2000cwb.googlegroups.com, "Markus Schoder"
<a3*************@yahoo.de> wrote:

You guys (my fellow posters) do realize he's going to take this data
and use it to prove Java is the better language, right.

To paraphrase an old communist saying: "Don't worry about the west,
they will sell us the rope we will hang them with."

Not to mention you guys are doing his work for him.


I have no interest in Java - why are you so paranoid?


May we then with all due respect ask what the reason for your question
is?


Exactly what I said in my initial post - to canvas opinion from other users.
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

_/ _/ _/_/_/ Hopkins Research Ltd
_/ _/ _/ _/
_/_/_/_/ _/_/_/ http://www.hopkins-research.com/
_/ _/ _/ _/
_/ _/ _/ _/ 'touch the future'

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Jun 15 '06 #36

P: n/a
Michael Hopkins wrote:
Exactly what I said in my initial post - to canvas opinion from other
users.


We frequently get questions - often by innocent newbies - cross-posted
between here and Java, asking us to compare them. Yours fit the profile of
a recent one, despite you didn't cross-post.

Comparing C++ to Java is like shooting a fish (Java) in a barrel.

--
Phlip

Jun 15 '06 #37

P: n/a
Michael Hopkins wrote:
Hi all

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.


Most of the "failings" are in fact tradeoffs -- "fixing" them would
create
new problems that are deemed to be worse than what is being fixed.

Perhaps one true failing is that the complexity of C++ has
overwhelmed the relative informal way that ISO standards are
written. ISO needs to pick some English dictionary as a
base standard, and require that all standards define
(directly or by reference) all words or phrases or notation
used in the standard with a meaning other than the one that
appears in the annointed dictionary. And it's not good enough
to say the specific meaning you're giving to a word like
"alignment" does not conflict with the general meaning,
so you don't need to define precisely your usage of it.

Jun 15 '06 #38

P: n/a

Michael Hopkins wrote:
Hi all

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 using or producing libraries inconvenient

Producing library is feasible in C++ but requires discipline and more
coding than it should be necessary.
I think that criticisims are totally pointless without an explanation
on "how to fix it", so, I'll give ways to fix it (My ideas are probably
not flawless, so feedback is welcome).

First, an extensible C++ library has to use, very often, the Pimpl
idiom (i.e. the class contains a pointer to the implementation's data
structure, and then, remains binary compatible even if new private
non-static data members are added or removed).
There is, a space & runtime overhead, that's why, even if the ISO
standard is written such as an implementation is allowed implement such
idiom automatically (i.e. for all classes having non-trivial
constructor or destructor), no sensible implementation would ever do
that. Furthermore such C++ implementation would not be binary
compatible with others.

That's why a "pimpl" specifier would ease library writing:
Here is how it would work:
The pimpl specifier would be used in class definition:

class __pimpl Class1 {
public:
void Func1();
protected:
virtual void Func2();
};

Instead of requiring that all definitions of the same class have the
same definition (including all private members), a __pimpl class could
be defined with missing members (except virtual functions for whom it
would be mandatory to define them all).
Thus, it would allow the library to expose only public and protected
members to users (and no private members).
Furthermore, it would also allow the library to add new members without
changing the ABI.
Constructors of __pimpl classes may launch std::bad_alloc exceptions
(even if the user-defined constructor doesn't seem throw anything).

Perhaps, it would be possible to allow one to define a __pimpl class
without all virtual members, but only a common starting sequence with
the true definition of the class.
In that case, for binary compatibility, it would require that vtables
(if it is the way virtual functions are implemented) for each class are
built from the vtable of the base class, whose size would be stored
somewhere in the vtable, and thus, allowing the copy of "unknown
pointer to functions of the vtable" from the base vtable to the derived
vtable.

So, it is probably complex to implement, but if it is well done, it
would probably really ease the conception of libraries.

Another problem when producing libraries (but that is not a language
issue, it is an implementation issue) is the fact that on the
IA-32/Win32 platform (which is widely used), there is no well-defined
ABI, and thus, linking C++ libraries of one compiler with libraries of
others is a real pain.
It can require a compilation of the source code of the library, which
is a bad thing, because, if the library is large, a user may have twice
the memory overhead of the library if he uses two different programs,
written with two different compilers, but using the same library,
compiled once for each compiler.
That's why, it could be wise for a C++ library writer, to write a C++
library, and then, a C interface to this C++ library, and finally, a
small C++ wrapper around this C interface, designed to be statically
linked to C++ programs which use this library.

On the GNU/Linux platform, there is a well-defined unique ABI, which
evolved around version 3, but is now quite stable.

I hope that in a near future, ABI compatibility will not be a problem
under x86-64 architecture under Windows.

This point is not at all a criticism of the C++ standard comittee. The
ABI is not a matter of the WG21, it is a platform-specific matter which
should be used by a platform-specific authority or consortium (i.e.
intel+compiler vendors for IA-32).

Jun 16 '06 #39

P: n/a

Victor Bazarov wrote:
Michael Hopkins wrote:
- the need for virtual destructors


Huh? What's the alternative? Virtual d-tors for every class? Or some
other RTTI mechanism to slow everything down?

virtual destructors for every class would be a huge memory overhead for
small objects (1-byte objects for instance).
Currently, C++ allows the object-based paradigm without overhead. And
it is fine for many many things, so I don't want it to be removed.

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.

Jun 16 '06 #40

P: n/a
SuperKoko wrote:
[..]
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 16 '06 #41

P: n/a
REH

Cy Edmunds wrote:
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

Jun 16 '06 #42

P: n/a

Victor Bazarov wrote:
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!

Jun 16 '06 #43

P: n/a
Michael Hopkins wrote:
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

Jun 16 '06 #44

P: n/a
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
Jun 19 '06 #45

P: n/a
> 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>

Jun 19 '06 #46

P: n/a
ax
On 19 Jun 2006 09:01:48 -0700, "Colander" <co******@gmail.com> wrote:
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.


"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
Jun 20 '06 #47

P: n/a
ax
On Mon, 19 Jun 2006 10:33:14 GMT, Ray Gardener wrote:
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?
Jun 20 '06 #48

P: n/a
ax wrote:
"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.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Jun 20 '06 #49

P: n/a
ax wrote:
[..]
"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
Jun 20 '06 #50

52 Replies

This discussion thread is closed

Replies have been disabled for this discussion.