My top five most annoying things about C++

My top five most annoying things about C++

Post by llewelly.a » Wed, 26 May 2004 12:56:06


iall Douglas < XXXX@XXXXX.COM > writes:


In my experience, this has far more to do with the the multiple (and
complicated!) layers of abstraction which come with the X window
system. Note that it is generally true for staticly linked
executables as well as dynamicly linked. Also, the opposite is
generally true for non-gui applications, due to more aggressive fs
caching. I'm not saying the unecessarily visible names which
often result from the unix model (note, not always, they can be
made not visible) and GOT lookups and such have no effect on
performance; (they are a performance problem) but for most apps,
I/O overwhelms most other factors.


What do you think TC1 is, if not the better-labeled equivalent of a
point release?


It seems unimportant only becuase so few are using it. :-)

Whether or not it is useful is unknown (to most C++ users),
again, because so few are using it.


In a timely fashion? They meet twice a year. Should we be funding
them to the extent that they can work on it 40 hours/week, 50
weeks a year? That would radicly change the amount of time it
took for improvents to be written into the standard, but would it
affect how quickly implementors can move to implement what is
written. OTOH, we could then have the easiest-to-understand
standard around (modulo the sheer complexity of C++.)


IMO, 1. and 2. are serious changes. Do you think serious changes belong in
point releases? I don't. Note, I'm in favor of move constructors,
and possibly local functions (depending on semantics) as well.


A delete expression may choose the deallocation function (that's the
user-definable operator delete) dynamicly, based on the runtime
type of the deleted object. So a user-defined operator delete
within a namespace would naturally apply to all *types* declared
in said namespace, *not* to all delete-expressions in said
namespace. A desireable feature, IMO, but it potentially comes
with some difficult design work, and, most importantly, design
work that can't assume a delete-expression is just 'irregular
call syntax' - the semantics for what function is called
are also different, and a delete-expression does more than just
call the deallocation function anyway.


People in the commitee are doing good hard work to provide this to
you.


*shrug* C++ exception specifications seem broken beyond all repair,
and in any case, it seems most all C++ programmers who use
exceptions are focused on using them for non-local error
handling. Why complicate their lives with a feature designed for
local error handling? If C++ is to gain a feature to force
specified errors to be handled locally, it shouldn't have
anything to do with exceptions.

Rather, if the committee is going to spend any time on exception
specifications, they should consider deprecating them. Probably,
this either isn't feasible, or isn't worth the effort, so the
committee's time IMO seems better spent on other things.

If the committee is concerned with making exceptions *safer*, I would
aprreciate it if they would ask if the programmer can readily provide
enough information so that the implementation can diagnose simple
but common violations of exception guarantees.


What do you mean by this? Surely your compiler supports dynamic
 
 
 

My top five most annoying things about C++

Post by nesott » Thu, 27 May 2004 01:02:10


From: "llewelly" < XXXX@XXXXX.COM >

| Rather, if the committee is going to spend any time on exception
| specifications, they should consider deprecating them.

changing the semantics from runtime-checks to no runtime-check would be good IMO.

| It would be quite useful to have a complementary library of
| containers and algorithms strongly biased toward entity types.

FYI I'm working on a set of adapters that makes it possible to store
pointers in std containers without using shared_ptr. Whether this is a good idea
or not remains to be seen.

What kind of algorithms are you talking about especially for entity types?

br

Thorsten


---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]

 
 
 

My top five most annoying things about C++

Post by s_googlegr » Thu, 27 May 2004 11:02:17

n Tue, 25 May 2004 03:56:06 +0000 (UTC), llewelly
< XXXX@XXXXX.COM > wrote:


I would agree - however, the X server is strongly decoupled from the
application and is far more efficient than Windows at avoiding unnecessary
GUI work. A lot of the time in my experience the X11 application just
trundles along and its GUI gets updated some time later.

However given your point, how about doxygen? Running the same on Linux and
Win32 it's at least twice as fast on Win32. Even including that doxygen is
running in VMWare which will come with some penalty (not much for CPU
bound tasks like doxygen), there's something wrong there.

Granted though it's getting better. GCC 3.4 produces noticeably better
quality code than v3.3 and earlier. PIC binaries are much smaller (by 50%
with TnFOX). And Linux 2.4 kernels aren't fast with memory mapped i/o (as
against FreeBSD or Windows) which will affect things too.


I thought TC1 was no more than wording changes to the standard? ie; to fix
ambiguities and contradictions and no more? That isn't what I'd call a
point release, more a bugfix release.


Well, I suppose I'm basing it on my experience with GCC. Local functions
would be easy enough to add, move constructors also though I would have
difficulties with modifying the optimiser to fully make use of them. Of
course the GCC masters aren't keen on extra-specification extensions right
now.

For both the infrastructure is already there (copy constructors and static
member functions of local classes). On most compilers it even has a
specific warning that local functions are not supported if you try.


I'm not sure I get you. Surely Koenig lookup takes care of finding which
operator delete to use? After that, if the type has a virtual destructor
you call that, else you generate (or call) a suitable destructor based
upon your static knowledge of the type?


I was thinking basically that if you define a "namespace Secure" and
within that namespace new & delete work with a special secure heap it
would be most useful. Interestingly I didn't know this wasn't possible
originally and it worked fine in MSVC and nearly in GCC (occasionally it
got the wrong delete). Maybe this latter problem is what you refer to?
Only ICC barfed with the correct error that this was not supported by the
standard.


I quite like the "throws nothing" specifier. It's the only one I use. All
the others from my examination of the generated assembler seem to generate
type checking code which is inefficient.


One thing I really dislike (and I should have included it in my top five,
but I forgot) is what the standard mandates if you throw an exception
while you're in the middle of handling one. That means programmer error
causes an immediate exit of the process with no chance to clean up (I
don't view terminate_handler() as a realistic way of properly cleaning up
a large multithreaded application!)!

I in TnFOX implemented a complex but efficient mechanism for nested
exception handling. If you throw while one is being handled, it's still a
fatal exception but the stack gets fully unwound and all threads get a
chance to unwind theirs too. Best of all, it gets to save information so
even in release builds a decent error report can be given detailing what
went wrong and where. I've grown so used to it that I forget this original
limitation nowadays :)

My C++ is written expecting tha
 
 
 

My top five most annoying things about C++

Post by Pavel Voze » Thu, 27 May 2004 22:04:47


He want to create STL implementation - interfaces would remain the same
but inner parts will be cleaner/faster/using advanced techniques/etc.

/Pavel


---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

My top five most annoying things about C++

Post by llewell » Fri, 28 May 2004 01:20:15

===================================== MODERATOR'S COMMENT:
Please take the VMware discussion to private email.


===================================== END OF MODERATOR'S COMMENT
XXXX@XXXXX.COM (Niall Douglas) writes:
[snip]

doxygen running in VMWare? Why? If so, it makes nonsense of your
comparison; VMWare has almost no overhead for some ops but very high
overhead for others.

[snip]

I had thought, up to this point, that point release was a synonym for
bugfix relase. Apparently, you think it is something else.


It's a major change to the standard because, in order to be useful,
it needs to be extensively used in and by the standard library.


Easy to add to the core language, maybe. Easy to add to all the
appropriate spots in the standard library? I don't think so.


Not for types with virtual destructors. See 12.5/4:

# [...] if the delete-expression is used to deallocate a class
# object whose static type has a virtual destructor, the
# deallocation function is the one found by the lookup in the
# definition of the dynamic type's virtual destructor
# (12.4). 104) [...]



The destructor is called before the deallocation function.


With GCC, the namespaced deallocation function is called if the
delete-expression is used to deallocate an object whose static
type has a virtual destructor. Otherwise, it is ignored.


True, but not the only thing that is wrong with exception
specifications.


If cleanup results in an error, can you safely clean up? The standard
assumes not.

There are surely applications for which this isn't true, but I think
they are a minority. I don't know if that minorty is important
enough to justifty the work necessary to define and implement
something smarter.

[snip]

Sorry, I misunderstood your original statement; I didn't realize you
intended to provide a new library, in addition to the existing
STL.


Obviously my biases are leading me to make false assumptions
again. :-)


An entity has identity. Even if you and I both have the same make,
year, model, and options on a car, my car is not your
car. Examples include bikes, shoes, ostreams, etc.

An entity type is a type you instantiate to get an entity.

An example of a non-entity type is an int. An int is a value type;
when dealing with ints, any two ints which have the value 5 are
the same.

[snip]

http://www.moderncppdesign.com/code/main.html

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

 
 
 

My top five most annoying things about C++

Post by franci » Fri, 28 May 2004 12:22:32

In article < XXXX@XXXXX.COM >, Niall Douglas
< XXXX@XXXXX.COM > writes


In file f1.cpp

namespace local_new {
// contains its overrider or overload of operator new and delete
}

mytype * i_ptr = new mytype;

In file f2.cpp

extern mytype * i_ptr;

namespace local_new {
delete i_ptr;
}

is just one example of a multitude of possible problems. Unlike classes
where the compiler sees all the declarations in the class definition
there is no requirement that the compiler sees all the declarations in a
namespace in any particular translation unit.

When you are annoyed by something in C++ it is usually a good idea to
discover why it is the way it is. We (I was part of the group whose
responsibility included this part of the core language) very carefully
considered issues of overloading and overriding (i.e. replacing)
operator new and operator delete at namespace scope and concluded that
with the C++ separate compilation model it was impossible to implement
which is why it is not allowed.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.yqcomputer.com/
For project ideas and contributions: http://www.yqcomputer.com/

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

My top five most annoying things about C++

Post by dave » Sat, 29 May 2004 01:00:42

XXXX@XXXXX.COM (Niall Douglas) writes:


This is what you call a "fresh viewpoint?" To me it sounds
unbelievably jaded and cynical. Maybe you should break your personal
rule and come to a committee meeting to see how things actually work
before you make such judgements. Participating in the C++ committee
and in the relationships that I developed out of it has probably been
the the most rewarding professional experience of my life.


When we run across such a feature, maybe we'll have use for that
mechanism. AFAICT it hasn't happened so far. We do have technical
reports that allow us to "bless" features before officially
standardizing them.

Also, 6 months, being only the total time between committee meetings,
is a bit short to expect to give any feature full consideration, get
implementation experience, and draft appropriate specifications.
We've been working on starting a process for making progress between
meetings, similar to Boost's, but even then I think 6 months would be
too short for actually adding a new feature, no matter how much
agreement it got.


Wow, if you think that's really small, I'd hate to see a medium-sized
feature. I mean, it's not "templates" or anything, but move
constructors has lots of implications, and no universal agreement.
Note that nobody's even written a complete specification yet.


There's plenty of agreement on that, but the problem is that every
feature takes more work than you seem to think, and we only have so
much volunteer manpower at our disposal. People who "deliberately
avoid having anything to do with groups like this" but expect us to
hurry up and approve their favorite features aren't doing anything to
contribute to the solution.


There are no powers that be; just a bunch of people who get together
every 6 months to try to make progress, and spend a lot of time having
email discussions and writing proposals in between meetings. You can
either participate and make a difference or you can expect us to
handle the things we have the time, energy, and expertise to work on.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

 
 
 

My top five most annoying things about C++

Post by llewelly.a » Sat, 29 May 2004 03:02:42


XXXX@XXXXX.COM (Dietmar Kuehl) writes:


And pairs of iterators are used to represent ranges, which are
arguable a third concept.

[snip]

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

My top five most annoying things about C++

Post by llewelly.a » Sat, 29 May 2004 06:11:01


XXXX@XXXXX.COM (David Abrahams) writes:
[snip]
[snip]

Somewhat related, in some ways Boost is a way of experimenting with
potential standard library features *before* they are
standardized.

Maybe Niall should experiment with Boost, and see how well it
fullfills his requirements for a 'fast track mechanism'; does
Niall need feature availablity, or does he need features chisled
into the granite of 14882?

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

My top five most annoying things about C++

Post by s_googlegr » Sat, 29 May 2004 06:11:25

Reposted after fixing moderator's reason for rejection]

On 26 May 2004 16:20:15 GMT, llewelly < XXXX@XXXXX.COM > wrote:


Given this (I agree), why isn't the core language spec released before the
library spec? I can see of course that the library gives a good testing of
a new language feature so one can backpedel if needs be - so I'd keep
synchronised releases for major updates. Bug fix and point releases could
be done independently so end-users could get on quickly with using
desperately needed minor features.


This still doesn't seem to be a problem (if I am understanding correctly).
Does the static type have a vtable? If yes, does it have a virtual
destructor? If yes, does the vtable have an operator delete due to a
subclass defining one? If so use that, otherwise go with the usual rules
for a function lookup. None of this prevents or causes issue with the
compiler performing the usual Koenig followed by in-to-out scope search
for a suitable operator delete. The only difference between choosing which
operator delete to use as against a standard overloaded function is a
little bit of extra work must be done if the type has a vtable.


Well I don't know anything about that. If a feature seems to cost more
than it gives to me I just don't use it. If it does give more but throws
stupid hurdles in the way, then I get frustrated. In that sense exception
specifications were done right because using either "throw()" (throws
nothing) or not using them at all doesn't come with unwanted side-effects.
True they may not have achieved what people thought they might, but then
they didn't balls up other stuff either. That to me reflects good design
(is "orthogonal" the right word here?)


But that's singularly unhelpful! How can the standard possibly know what
you're doing with your classes (what if they all have trivial
destructors?)? Maybe you can or maybe you can't clean up, but the standard
just hard exits your process - like a SIGILL. I've taken the approach that
if the nested exception throw corrupts memory or fatally damages
application state, then so be it - then you get SIGILL or whatever and
your hard exit - but at least your code had some chance to wipe encryption
keys and flush files. The current standard's approach is throwing the baby
out with the bathwater.


Well, most of that work can be obviated by plucking ideas off an existing
implementation a la Boost library. I'm sure C++ gurus would risk blood
clots when examining my sloppy C++, but that code is LGPL and I freely
offer explanatory support!

My issue with how it is right now is that if you have a secure or
mission-critical app then the standard is helping attackers or
catastrophic failure respectively right now (many of course would say such
applications should not be written in C++, but that didn't work for C so
why C++?). This is surely not something we want to encourage?


Oh don't worry, this happens to me all the time. Partially due to how I
deliberately frame posts in a "stir things up" style which most people
take as arrogance & naivity (which is intended).


<wince> This relabelling of old concepts with new fancy names seems to get
worse every year. It's probably a good thing for teaching first year
undergraduates as we used to interchange terms inconsistently before but
it does cause some of us who don't keep up surprise. I still don't really
know w
 
 
 

My top five most annoying things about C++

Post by llewell » Sat, 29 May 2004 08:59:36

XXXX@XXXXX.COM (Niall Douglas) writes:


If wg21 is really lowest common denominator, how on earth do you
explain the STL? People claim the STL is 'popular', but in my
experience, it was *not* popular prior to about 2000 or so -
and even today, it seems it is only popular amoung programmers
whose knowledge of C++ is substantially above average, and a long
way outside of 'lowest common denominator'.


I must admit I only read one or two papers from each mailing (no, I'm
not member, but most/all of the papers have been publicly
availible for a long time.), but I have seen little evidence that
'horse-trading' has much influence on committee decisions.

Can somebody point to an example? If so, did it result in a worse
standard?


Can you cite numbers?

[snip]

Move constructors affect overloading. Overloading is one the most
complex areas of C++ (ISTR Daveed described it as 'worse than
templates')

Namespaces are a simple concept, but look at the mess that resulted
from them being introduced into the already complicated C++ name
lookup rules.

I believe there is a real danger something similar might happen with
move constructors. I am strongly in favor of move constructors,
and it would be great to get some real-world experience with them
soon, but I would prefer the comittee move cautiously in
standardizing them.


---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

 
 
 

My top five most annoying things about C++

Post by s_googlegr » Sat, 29 May 2004 11:02:20

On Thu, 27 May 2004 21:11:01 +0000 (UTC), llewelly



While I'd like to see changes to the standard library, I would hardly
consider them urgent. All the changes I originally outlined were very
substantial changes and therefore not possible in a short time. If you
remember, I was speaking of complete redesigns.

Anyway besides, if a library annoys you you can fix it yourself. Language
(mis)features you can't fix :(

See my other post to Dave Abrahams for my ideas on how to streamline ISO
C++ standardisation and involve a lot more workers.

Cheers,
Niall

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

My top five most annoying things about C++

Post by dave » Sat, 29 May 2004 11:02:46


XXXX@XXXXX.COM (tom_usenet) writes:


If you can figure out how to make use of destructive move work at all,
much less in the presence of exceptions, *and* you can prove that it
will improve efficiency, I'm all for it. Personally I have grave
doubts:

struct Foo
{
~Foo();
};

void f(Foo& x, bool y)
{
if (y) { Foo z(move(x)); }
}

int main(int argc, char**argv)
{
Foo a;
f(a, argc > 1);
// Do we generate a destructor here?
}

Ultimately you end up having to carry around an "exists" state bit
with every object. Not worth it, IMO.

--
Dave Abrahams
Boost Consulting
http://www.yqcomputer.com/

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

My top five most annoying things about C++

Post by dave » Sat, 29 May 2004 11:03:09

llewelly < XXXX@XXXXX.COM > writes:


Not quite, at least not in C++. No two lvalues are precisely
equivalent, because they have detectable addresses that may differ.
It's actually a major problem that crops up when trying to define
almost *any* formal semantics for C++ code. There's really no
difference between two ints and two bikes in this respect.

--
Dave Abrahams
Boost Consulting
http://www.yqcomputer.com/

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

My top five most annoying things about C++

Post by s_googlegr » Sat, 29 May 2004 14:00:10

On Thu, 27 May 2004 03:22:32 +0000 (UTC), Francis Glassborow



mytype's vtable:
[0]: flags (indicates vtable contents)
[1]: ptr to destructor
[2]: ptr to appropriate delete for new used to instantiate


Compiler knows mytype has vtable. Generates code which examines vtable of
i_ptr. Sees there is an operator delete in it at [2]. Calls [1] then [2]
which calls correct destructor & operator delete.


Since this dynamic calling of operator delete already requires a vtable
(as the standard requires), I still don't see this as a problem.


With respect, and I know of your name from many years ago when you
published an article of mine in ACCU, unless I have missed something your
explanation does not make any sense. As soon as a vtable is available, you
can call any operator delete anywhere at all including one completely
unknown to the current compiland. It just requires an appropriately laid
out vtable.

Indeed, if maximising code efficiency and minimising vtable size were
important, one could annotate the class to indicate if it does or doesn't
need to store a pointer to the appropriate delete to use when newed. Of
course, with the machinery that will be required by the export keyword,
the pre-linker stage could determine that on its own.

Cheers,
Niall

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]