 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
llewelly
Guest
|
 Posted: Mon May 17, 2004 9:09 pm Post subject: n1496 |
 |
|
I'm unhappy with the bit in in n1496 about syntax. Specifically:
# There are three possible approaches to specifying which names in
# a translation unit refer to entities with shared linkage. First,
# names with external linkage can be non-shared by default, and the
# programmer would have to explicitly identify names that are to
# have shared linkage. This is the model that Windows programmers
# are familiar with. Second, names with external linkage can be
# shared by default, and the programmer would have to explicitly
# identify names that are not to have shared linkage. This is
# similar to the model that UNIX programmers are familiar
# with. Third, it can be implementation-defined which of the two
# preceeding models applies. This minimizes the required changes to
# existing code.
I'm unhappy with the first model because it seems to break all
existing unix code that makes use of shared libraries.
I'm unhappy with the second model becuase it changes the default on
windows; it seems to cause every declaration to undergo a silent
change in meaning.
I don't think either of the first two models should be accepted.
I think I want all of:
(a) A syntax for declaring a name to have shared linkage.
(b) A syntax for declaring a name to have non-shared linkage.
(c) If a name's declaration does not explicitly specify shared
or non-shared linkage, whether that name's linkage is shared
or non-shared shall be implementation-defined.
The first time I read the third alternative, it seemed to mean
this. On re-reading it, I'm unsure. Specifically, if an
implementation supports shared libraries, I want both (a) and
(b), regardless of the implementation-defined meaning of (c).
---
[ 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 ]
|
|
| Back to top |
|
 |
Pete Becker
Guest
|
| Posted: Tue May 18, 2004 1:14 am Post subject: Re: n1496 |
|
|
llewelly wrote:
| Quote: |
I'm unhappy with the bit in in n1496 about syntax. Specifically:
# There are three possible approaches to specifying which names in
# a translation unit refer to entities with shared linkage. First,
# names with external linkage can be non-shared by default, and the
# programmer would have to explicitly identify names that are to
# have shared linkage. This is the model that Windows programmers
# are familiar with. Second, names with external linkage can be
# shared by default, and the programmer would have to explicitly
# identify names that are not to have shared linkage. This is
# similar to the model that UNIX programmers are familiar
# with. Third, it can be implementation-defined which of the two
# preceeding models applies. This minimizes the required changes to
# existing code.
I'm unhappy with the first model because it seems to break all
existing unix code that makes use of shared libraries.
|
It doesn't break anything. It means that such code wouldn't be portable.
It's not portable today, so that's no change.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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 ]
|
|
| Back to top |
|
|
llewelly
Guest
|
| Posted: Wed May 19, 2004 10:10 am Post subject: Re: n1496 |
|
|
[email]petebecker (AT) acm (DOT) org[/email] (Pete Becker) writes:
| Quote: | llewelly wrote:
I'm unhappy with the bit in in n1496 about syntax. Specifically:
# There are three possible approaches to specifying which names in
# a translation unit refer to entities with shared linkage. First,
# names with external linkage can be non-shared by default, and the
# programmer would have to explicitly identify names that are to
# have shared linkage. This is the model that Windows programmers
# are familiar with. Second, names with external linkage can be
# shared by default, and the programmer would have to explicitly
# identify names that are not to have shared linkage. This is
# similar to the model that UNIX programmers are familiar
# with. Third, it can be implementation-defined which of the two
# preceeding models applies. This minimizes the required changes to
# existing code.
I'm unhappy with the first model because it seems to break all
existing unix code that makes use of shared libraries.
It doesn't break anything. It means that such code wouldn't be portable.
It's not portable today, so that's no change.
|
I am sorry, but these two statements make no sense to me. Could you
please rephrase?
---
[ 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 ]
|
|
| Back to top |
|
|
Pete Becker
Guest
|
| Posted: Thu May 20, 2004 2:51 am Post subject: Re: n1496 |
|
|
llewelly wrote:
| Quote: |
[email]petebecker (AT) acm (DOT) org[/email] (Pete Becker) writes:
llewelly wrote:
I'm unhappy with the bit in in n1496 about syntax. Specifically:
# There are three possible approaches to specifying which names in
# a translation unit refer to entities with shared linkage. First,
# names with external linkage can be non-shared by default, and the
# programmer would have to explicitly identify names that are to
# have shared linkage. This is the model that Windows programmers
# are familiar with. Second, names with external linkage can be
# shared by default, and the programmer would have to explicitly
# identify names that are not to have shared linkage. This is
# similar to the model that UNIX programmers are familiar
# with. Third, it can be implementation-defined which of the two
# preceeding models applies. This minimizes the required changes to
# existing code.
I'm unhappy with the first model because it seems to break all
existing unix code that makes use of shared libraries.
It doesn't break anything. It means that such code wouldn't be portable.
It's not portable today, so that's no change.
I am sorry, but these two statements make no sense to me. Could you
please rephrase?
|
Sure. Today, Unix code that makes use of shared libraries isn't marked
up with import/export specifiers. If the standard adds some way of
saying that various functions will live in a shared library, then code
that's marked up in that way will (eventually) be portable, say between
Unix and Windows. Unix code that isn't marked up won't take advantage of
this added syntax, so it won't be portable to Windows. However, Unix
compilers will certainly still support the current style (through a
command line option), and the code will still work in all the places
where it works now.
For a less abstract example, quite a few programmers still use classic
iostreams through the header <iostream.h>, even though the standard
provides something similar but different through <iostream>.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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 ]
|
|
| Back to top |
|
|
Niall Douglas
Guest
|
| Posted: Thu May 20, 2004 2:52 am Post subject: Re: n1496 |
|
|
On Mon, 17 May 2004 21:09:47 +0000 (UTC), llewelly
<llewelly.at (AT) xmission (DOT) dot.com> wrote:
| Quote: | # There are three possible approaches to specifying which names in
# a translation unit refer to entities with shared linkage. First,
# names with external linkage can be non-shared by default, and the
# programmer would have to explicitly identify names that are to
# have shared linkage. This is the model that Windows programmers
# are familiar with. Second, names with external linkage can be
# shared by default, and the programmer would have to explicitly
# identify names that are not to have shared linkage. This is
# similar to the model that UNIX programmers are familiar
# with. Third, it can be implementation-defined which of the two
# preceeding models applies. This minimizes the required changes to
# existing code.
I'm unhappy with the first model because it seems to break all
existing unix code that makes use of shared libraries.
|
One could take the view that Unix has it wrong and it needs to change for
its own good. Irrespective of what the standard says, the implementors on
Unix will devise some transitory/interoperability strategy. It would also
hardly be the first time that existing implementations did something which
was later ruled out by the standard (I'm thinking unqualified name lookups
within templates particularly).
BTW in N1496 appendix item 4 I can confirm that the Unix mechanism cannot
be implemented on Windows. The PE binary hardcodes what symbols it looks
for from each library by name as of course under PE you can use ordinal
rather than mangled symbol resolution. The advantage of the PE system is a
substantially reduced search tree and thus improved load & link times but
it does mean you can't arbitrarily muck around with DLL contents without a
relink (not hard as ELF dynamic loaders ARE the full-strength standard
linker).
| Quote: | I'm unhappy with the second model becuase it changes the default on
windows; it seems to cause every declaration to undergo a silent
change in meaning.
|
N1496 also doesn't cover the need to use dllimport with PE for variables.
You can get away with not specifying dllimport for functions on Win32 but
you *must* specify it for variables.
| Quote: | I don't think either of the first two models should be accepted.
|
I think the first model should be mandated. Unix shared libraries emulate
static linking except that the linking is continuous in that it can be
more-done or be undone according to manual loading and unloading of
libraries. Certainly from a programmer's point of view, you are supposed
to do nothing special to use shared libraries - just tweak your build
system slightly with no source changes. However the reality is more
complex than that.
Because Unix shared libraries seek to provide this legacy appearance, they
diverge much less from not only the standard but also the spirit of static
linking. Therefore one could view that system as "enhanced static linking"
and therefore not something which needs to be borne in mind when updating
the ISO C++ standard.
In other words, what I'm saying is that a MSVC style shared library system
can coexist with the Unix shared library system whereas the opposite is
most certainly not true. Therefore be brave and go with system number 1.
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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Pete Becker
Guest
|
| Posted: Thu May 20, 2004 6:44 pm Post subject: Re: n1496 |
|
|
Niall Douglas wrote:
| Quote: |
You can get away with not specifying dllimport for functions on Win32 but
you *must* specify it for variables.
|
No. The compiler has to know to generate an indirect reference. That
doesn't depend on specifying dllimport, but simply on knowing that the
variable is imported. The marker that indicates that it's exported is
sufficient: the compiler can generate indirect references whenver it
accesses exported data (although this would mean that accesses from the
same linkage unit would be indirect as well).
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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 ]
|
|
| Back to top |
|
|
Davide Bolcioni
Guest
|
| Posted: Sun May 23, 2004 12:18 am Post subject: Re: n1496 |
|
|
Niall Douglas wrote:
| Quote: | I'm unhappy with the first model because it seems to break all
existing unix code that makes use of shared libraries.
One could take the view that Unix has it wrong and it needs to change
for its own good. Irrespective of what the standard says, the
implementors on Unix will devise some transitory/interoperability
strategy.
|
From the point of view of a programmer doing mostly maintenance work of
existing code bases, I would say that Unix had it right from the
beginning and Windows requires the programmer to pepper the code with
too much detail for his own good: the notion that shared libraries are
not something which should concern the language, only the linker, made
my job exceedingly easier. If you want metaphors, think relational
versus handcrafted database, with the linker doing the joins.
| Quote: | BTW in N1496 appendix item 4 I can confirm that the Unix mechanism
cannot be implemented on Windows.
|
Given the time scale expected of C++0x, maybe the right question is
whether it is implementable for .NET ?
| Quote: | The PE binary hardcodes what symbols
it looks for from each library by name as of course under PE you can use
ordinal rather than mangled symbol resolution. The advantage of the PE
system is a substantially reduced search tree and thus improved load &
link times but it does mean you can't arbitrarily muck around with DLL
contents without a relink (not hard as ELF dynamic loaders ARE the
full-strength standard linker).
|
This should be of interest only to people implementing a linker, in my
opinion.
| Quote: | I'm unhappy with the second model becuase it changes the default on
windows; it seems to cause every declaration to undergo a silent
change in meaning.
|
From the point of view of maintenance ... I would personally dislike that
intensely  .
| Quote: | N1496 also doesn't cover the need to use dllimport with PE for
variables. You can get away with not specifying dllimport for functions
on Win32 but you *must* specify it for variables.
|
Which is an implementation detail which I expect the linker to handle,
although the PE linker doesn't.
| Quote: | I think the first model should be mandated. Unix shared libraries
emulate static linking except that the linking is continuous in that it
can be more-done or be undone according to manual loading and unloading
of libraries.
|
Unix shared libraries implement visibility as defined in the C or C++
language, without introducing another layer of detail for the programmer
to handle (and possibly get wrong). Programmers wishing for the
additional complexity might have the option to specify it, but the
default should be implementation-defined (in the makefile) linking.
In other words: we don't tell the programmer how the program will be
cobbled together, he had better make sure it works anyway. Guidelines as
to which tricks not to pull in order to not have things break
unexpectedly would be really welcome and in my humble opinion belong in
a language standard: FORTRAN got much mileage from its rules for common
variable access, for example.
| Quote: | In other words, what I'm saying is that a MSVC style shared library
system can coexist with the Unix shared library system whereas the
opposite is most certainly not true. Therefore be brave and go with
system number 1.
|
On the contrary, I suggest leaving the language as it stands; just
acknowledge that shared libraries are a reality of current
implementations and might impose a series of restrictions which should
be observed by the programmer.
Best Regards,
Davide Bolcioni
---
[ 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 ]
|
|
| Back to top |
|
|
Niall Douglas
Guest
|
| Posted: Mon May 24, 2004 8:29 pm Post subject: My top five most annoying things about C++ (was: Re: n1496) |
|
|
On Sun, 23 May 2004 00:18:04 +0000 (UTC), Davide Bolcioni
<6805b3x001 (AT) sneakemail (DOT) com> wrote:
| Quote: | One could take the view that Unix has it wrong and it needs to change
for its own good. Irrespective of what the standard says, the
implementors on Unix will devise some transitory/interoperability
strategy.
From the point of view of a programmer doing mostly maintenance work of
existing code bases, I would say that Unix had it right from the
beginning and Windows requires the programmer to pepper the code with
too much detail for his own good: the notion that shared libraries are
not something which should concern the language, only the linker, made
my job exceedingly easier.
|
Sure, the Unix method makes your job easier to produce something which
functions. However as anyone who has ever compared real-world application
performance between Windows and Unix realises, Unix GUI applications just
go slower - and I was even comparing two applications both using Qt.
If you go the Unix route, code *quality* suffers because it's much easier
for the programmer to be lazy. If you go the Windows route, you get as
perfect quality as you can for free with slightly more work. You already
know which I prefer but I'll elaborate below.
| Quote: | BTW in N1496 appendix item 4 I can confirm that the Unix mechanism
cannot be implemented on Windows.
Given the time scale expected of C++0x, maybe the right question is
whether it is implementable for .NET ?
|
I personally feel that when producing language standards as with any
standard, the format should be big release, then point 1 release and point
2 release with point 2 released as the next big release is in preparation.
ISO C++ has not followed this, much to its detriment :(
Now we have most major compilers nearly complying with the standard (I
view "export" as not particularly useful/important if I understand the
standard correctly), we really could do with a point release of the
standard to address urgent issues in a timely fashion. My top five most
annoying features of C++ are:
1. Lack of move constructors. It really, *really* annoys me to see the
generated assembler for using say a string class and see loads of
pointless copying. With move constructors the compiler can optimise the
case when the object being copied is obviously about to get destroyed.
Also, around 5% of the classes I design operate with move semantics which
is a royal PITA when your copy constructor takes const references (either
you const_cast or use mutable).
2. Lack of local functions. I use a lot of "undoable operations" to roll
back partially completed work in case of an exception. I got the idea
originally from Alexandrescu but I've improved on his original work and
you can find them at
http://tnfox.sourceforge.net/TnFOX/html/group__rollbacks.html. Sometimes
the rollback can be quite complex and here you need local functions -
unfortunately these are not permitted, so instead you declare a local
class with a static member function but this furls up the source  . If
local classes with static member functions are possible, so are local
functions! I'd particularly love if local functions had access to the
scope in which they are defined.
3. Removal of stupid and arbitrary limits. There are lots in here but
thankfully most are obvious from reading through the standard. Off the top
of my mind, why can't you define operator new & delete within a namespace
(why aren't they just treated like normal functions with an irregular call
syntax)? Why can't you template a typedef? Why doesn't the standard
mandate marking in the mangled symbol of non-throwing functions so the
compiler can warn at compile time when a function shouldn't be
non-throwing or indeed when it could (it also helps the optimiser here)?
Why can't you initialise aggregate types with compile-time known functions
(I'm thinking compile-time variable arrays here)? Why can't you mark
virtual functions as being "once" in all subclasses (ie; if there are
virtual functions A::foo() and B::foo and class C inherits A and B in that
order, A's foo() points at B's foo() rather than there being two
(ambiguous) foo()'s) - such a feature would greatly ease mixing run-time &
compile-time polymorphism without introducing the costs of virtual base
class inheritance? Why can't templates have parameterised pieces of code
so we can finally get rid of macros? And why is the only way to determine
an unknown type is via template argument deduction via a function which
severely castrates your metaprogramming flexibility (and forces stilted
design)? I can go on, but the "D" programming language has many more good
ideas here.
4. Lack of basic tools in the STL (eg; a hash based dictionary container,
reference counting abstract base classes (preferably based on
policy-driven smart pointers), LRU caching etc. etc). This stuff is hardly
new technology - I threw together a generic hash based dictionary
container in a few hours using map, vector and list. It's really not hard.
And no, I don't like hash_map from the SGI library as it's not
configurable enough.
5. Speaking of which, the STL in general annoys me. I deliberately don't
use large sections of it and I'm hardly alone here - a large minority of
C++ programmers refuse to use the STL at all. The thing which annoys me
the most is the naming scheme - it consistently names the functions the
least likely thing you'd think of and I personally can't see why lots more
synonyms couldn't be added (eg; list<>::splice() could also be called
list<>::relink() or craziest of all, list<>::move()). It's this style
issue and it being totally contrary to how I write my own C++ which makes
me always uncomfortable using it, which is why I wrapped it with a thin
veneer to provide Qt API emulations (see
[url]http://tnfox.sourceforge.net/TnFOX/html/group___q_t_l.html)[/url].
The language itself is generally good, though it has an unfortunate habit
of requiring more keyboard typing to create better C++ which means
laziness automatically causes bad C++. However its weakest point IMHO is
the STL which if I had absolute control over the ISO standardisation
process I'd personally start most of it again from scratch and supply thin
veneers emulating the existing STL's API. My new STL would be far more
policy driven as the existing lack of same prevents usage of STL-provided
functionality (eg; searching a list when the predicate isn't fixed nor
simple).
(Note that I am aware that some of my top five most annoying things about
C++ either are being addressed or have been addressed in the next
standard. What's wrong is that none of the above five items require much
work - they are simple - and could be safely added to the standard within
months rather than years. They would also require trivial quantities of
additional work by compiler vendors. The fact they are not being applied
with haste means millions of more lines of code must be written to
circumvent them, certainly hundreds of thousands of more programmer hours
must be wasted and I think this is very irresponsible).
| Quote: | The PE binary hardcodes what symbols it looks for from each library by
name as of course under PE you can use ordinal rather than mangled
symbol resolution. The advantage of the PE system is a substantially
reduced search tree and thus improved load & link times but it does
mean you can't arbitrarily muck around with DLL contents without a
relink (not hard as ELF dynamic loaders ARE the full-strength standard
linker).
This should be of interest only to people implementing a linker, in my
opinion.
|
Though I cannot speak for them, I cannot see Microsoft up-ending the
Windows DLL mechanism just for ISO C++ compliance. DLL's are absolute core
to Windows because unlike Unix it was designed from the beginning with
them in mind. If the ISO C++ spec adopts a mechanism incompatible with
Win32, then that feature will likely be ignored on the vast majority of
the world's computers.
| Quote: | In other words: we don't tell the programmer how the program will be
cobbled together, he had better make sure it works anyway. Guidelines as
to which tricks not to pull in order to not have things break
unexpectedly would be really welcome and in my humble opinion belong in
a language standard: FORTRAN got much mileage from its rules for common
variable access, for example.
|
The trouble with this approach is that it produces sub-optimal code. If
the compiler cannot know if a symbol is local to this DSO/DLL or not, it
must assume the worst and run *every* *single* *access* through an
indirection lookup. This is why code compiled with GCC using -fPIC is
markedly slower than code compiled without and it's also more bloated.
This is partially where the speed & size differential between MSVC & GCC
compiled binaries comes from. The trouble with "default shared" is that it
encourages laziness - most programmers will do the minimum to get a
working application and then stop. If it's "default private" then
programmers must add the extra annotation to even reach a working binary -
which is good, because code quality improves substantially.
I also feel that whether something is visible outside its DSO/DLL is part
of its API spec and thus interface contract. If you disagree with this,
consider how public/protected/private relate to class design and note that
similar logic applies to both.
| Quote: | On the contrary, I suggest leaving the language as it stands; just
acknowledge that shared libraries are a reality of current
implementations and might impose a series of restrictions which should
be observed by the programmer.
|
The "stick head in sand" approach is only useful when a technology is
brand new and the consequences of misapplying it may be dangerous. Shared
libraries have been in widespread use for fifteen years - we know them
well enough now that not acting just makes things worse.
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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
llewelly
Guest
|
| Posted: Tue May 25, 2004 3:56 am Post subject: Re: My top five most annoying things about C++ |
|
|
Niall Douglas <s_googlegroups (AT) nedprod (DOT) com> writes:
| Quote: | On Sun, 23 May 2004 00:18:04 +0000 (UTC), Davide Bolcioni
[email]6805b3x001 (AT) sneakemail (DOT) com[/email]> wrote:
One could take the view that Unix has it wrong and it needs to
change for its own good. Irrespective of what the standard says,
the implementors on Unix will devise some
transitory/interoperability strategy.
From the point of view of a programmer doing mostly maintenance work of
existing code bases, I would say that Unix had it right from the
beginning and Windows requires the programmer to pepper the code with
too much detail for his own good: the notion that shared libraries are
not something which should concern the language, only the linker, made
my job exceedingly easier.
Sure, the Unix method makes your job easier to produce something which
functions. However as anyone who has ever compared real-world
application performance between Windows and Unix realises, Unix GUI
applications just go slower - and I was even comparing two
applications both using Qt.
|
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.
| Quote: | If you go the Unix route, code *quality* suffers because it's much
easier for the programmer to be lazy. If you go the Windows route, you
get as perfect quality as you can for free with slightly more
work. You already know which I prefer but I'll elaborate below.
BTW in N1496 appendix item 4 I can confirm that the Unix mechanism
cannot be implemented on Windows.
Given the time scale expected of C++0x, maybe the right question is
whether it is implementable for .NET ?
I personally feel that when producing language standards as with any
standard, the format should be big release, then point 1 release and
point 2 release with point 2 released as the next big release is in
preparation. ISO C++ has not followed this, much to its detriment
|
What do you think TC1 is, if not the better-labeled equivalent of a
point release?
| Quote: |
Now we have most major compilers nearly complying with the standard (I
view "export" as not particularly useful/important if I understand the
standard correctly),
|
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.
| Quote: | we really could do with a point release of the
standard to address urgent issues in a timely fashion.
|
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++.)
| Quote: | My top five
most annoying features of C++ are:
1. Lack of move constructors. It really, *really* annoys me to see the
generated assembler for using say a string class and see loads of
pointless copying. With move constructors the compiler can optimise
the case when the object being copied is obviously about to get
destroyed. Also, around 5% of the classes I design operate with
move semantics which is a royal PITA when your copy constructor
takes const references (either you const_cast or use mutable).
2. Lack of local functions. I use a lot of "undoable operations" to
roll back partially completed work in case of an exception. I got
the idea originally from Alexandrescu but I've improved on his
original work and you can find them at
http://tnfox.sourceforge.net/TnFOX/html/group__rollbacks.html. Sometimes
the rollback can be quite complex and here you need local functions
|
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.
| Quote: | unfortunately these are not permitted, so instead you declare a local
class with a static member function but this furls up the source
. If local classes with static member functions are possible, so are
local functions! I'd particularly love if local functions had access
to the scope in which they are defined.
3. Removal of stupid and arbitrary limits. There are lots in here but
thankfully most are obvious from reading through the standard. Off
the top of my mind, why can't you define operator new & delete
within a namespace (why aren't they just treated like normal
functions with an irregular call syntax)?
|
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.
| Quote: | Why can't you template a
typedef?
|
People in the commitee are doing good hard work to provide this to
you.
| Quote: | Why doesn't the standard mandate marking in the mangled
symbol of non-throwing functions so the compiler can warn at
compile time when a function shouldn't be non-throwing or indeed
when it could (it also helps the optimiser here)?
|
*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.
| Quote: | Why can't you
initialise aggregate types with compile-time known functions (I'm
thinking compile-time variable arrays here)?
|
What do you mean by this? Surely your compiler supports dynamic
initialization
| Quote: | Why can't you mark
virtual functions as being "once" in all subclasses (ie; if there
are virtual functions A::foo() and B::foo and class C inherits A
and B in that order, A's foo() points at B's foo() rather than
there being two (ambiguous) foo()'s) - such a feature would greatly
ease mixing run-time & compile-time polymorphism without
introducing the costs of virtual base class inheritance? Why can't
templates have parameterised pieces of code so we can finally get
rid of macros? And why is the only way to determine an unknown type
is via template argument deduction via a function which severely
castrates your metaprogramming flexibility
|
Because C++ wasn't designed with metaprogramming in mind. It was an
accident. Hopefully it will inspire a set of dedicated
metaprogramming features, either in C++ or some other
programming language, but for now, metaprogramming in C++ is like
OOP in assembler.
| Quote: | (and forces stilted
design)? I can go on, but the "D" programming language has many
more good ideas here.
|
Some good ideas, and some bad ones. The only big advantage seems to
be that D (like darn near every other programming language(*)) is
much, much easier to implement tools for.
(*) I've heard algol 68, ansi common lisp, and pl/1 where harder to
implement than C++ . I don't know what the methods behind those
judgements were, however.
| Quote: |
4. Lack of basic tools in the STL (eg; a hash based dictionary
container, reference counting abstract base classes (preferably
based on policy-driven smart pointers), LRU caching etc. etc). This
stuff is hardly new technology - I threw together a generic hash
based dictionary container in a few hours using map, vector and
list. It's really not hard. And no, I don't like hash_map from the
SGI library as it's not configurable enough.
|
Someday, you should get P.J.'s book _The Draft Standard C++ Library_,
so you can see what the STL replaced. The library described
therin (which AFAIK was the only other serious contender (*)) is
well-designed in its own way, but it was sparser than
the the library that we now have, largely due to the STL's richer
set of containers and algorithms. (The compatibility lost due to
the massive changes to the iostream library is IMO not the fault
of the STL.)
Somewhat seperatly It's easy to look at e.g. Java, and think 'my, the
C++ standard library is a desert' but it's important to remeber
(*) 'contender' in the sense that if the STL had not be voted into
the standard, we would likely have what Plauger described in that
book, though that is in most ways better described as a
predecessor.
| Quote: |
5. Speaking of which, the STL in general annoys me.
|
Maybe you are mis-using it? In truth, all interfaces annoy, and it is
human nature to best recall those aspects of an interface which
annoy.
| Quote: | I deliberately
don't use large sections of it and I'm hardly alone here - a large
minority of C++ programmers refuse to use the STL at all.
|
IMO, most of them are costing themselves time, costing their
co-workers time, and if you work with their code, costing you time.
| Quote: | The thing
which annoys me the most is the naming scheme - it consistently
names the functions the least likely thing you'd think of and I
personally can't see why lots more synonyms couldn't be added (eg;
list<>::splice() could also be called list<>::relink() or craziest
of all, list<>::move()).
|
I find splice() more natural than either relink() or move(), both of
which seem subtly wrong to me. I have to laugh at this particular
complaint of yours, because it seems to me there are many examples
(std::remove() anyone?) where almost everyone agrees the STL
picked the wrong name, but you chose a place where it picked the
right name.
It's this style issue and it being totally
| Quote: | contrary to how I write my own C++ which makes me always
uncomfortable using it, which is why I wrapped it with a thin
veneer to provide Qt API emulations (see
[url]http://tnfox.sourceforge.net/TnFOX/html/group___q_t_l.html)[/url].
|
*Not* my idea of an improvement over the STL. If you'd like to see a
serious alternative to the STL, you might try the NTL. (Search for
it on sourceforge.)
However, it should be acknowledged that the STL strongly favors value
types, which is a huge advantage for many kinds of programs, but
is largely antithetical to certain common OO styles which
overwhelming demand entity types.
It would be quite useful to have a complementary library of
containers and algorithms strongly biased toward entity types.
| Quote: |
The language itself is generally good, though it has an unfortunate
habit of requiring more keyboard typing to create better C++ which
means laziness automatically causes bad C++. However its weakest point
IMHO is the STL which if I had absolute control over the ISO
standardisation process I'd personally start most of it again from
scratch and supply thin veneers emulating the existing STL's API.
[snip] |
What would this achieve? The standard only defines an interface.
I realize that those of you who never leave the bounds of Purified
Natural Filtered Sanctified OO find the STL's favortism towards
value types bizzare, confusing, and inappropriate, but those of
us who don't have entity types falling out of ears generally
appreciate it.
Again, it would be niced to see it improved in various ways, and nice
to see it complemented by something that better supported entity
types, but it shouldn't be removed or replaced.
---
[ 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 ]
|
|
| Back to top |
|
|
Thorsten Ottosen
Guest
|
| Posted: Tue May 25, 2004 4:02 pm Post subject: Re: My top five most annoying things about C++ |
|
|
From: "llewelly" <llewelly.at (AT) xmission (DOT) dot.com>
| Quote: | 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.
| Quote: | 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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
tom_usenet
Guest
|
| Posted: Tue May 25, 2004 8:48 pm Post subject: Re: My top five most annoying things about C++ (was: Re: n14 |
|
|
On Mon, 24 May 2004 14:29:39 CST, Niall Douglas
<s_googlegroups (AT) nedprod (DOT) com> wrote:
| Quote: | I personally feel that when producing language standards as with any
standard, the format should be big release, then point 1 release and point
2 release with point 2 released as the next big release is in preparation.
ISO C++ has not followed this, much to its detriment
|
You appear to have missed the 2003 TC (or "point release"). There's
also the library TR coming out fairly soon. So you have a "bug fix"
point release and a new features point release. What more do you want?
| Quote: | Now we have most major compilers nearly complying with the standard (I
view "export" as not particularly useful/important if I understand the
standard correctly),
|
I'd like to see what EDG do with their implementation before
commenting on this. I'm hoping for template "object code", which I
think may be possible.
we really could do with a point release of the
| Quote: | standard to address urgent issues in a timely fashion. My top five most
annoying features of C++ are:
1. Lack of move constructors. It really, *really* annoys me to see the
generated assembler for using say a string class and see loads of
pointless copying. With move constructors the compiler can optimise the
case when the object being copied is obviously about to get destroyed.
Also, around 5% of the classes I design operate with move semantics which
is a royal PITA when your copy constructor takes const references (either
you const_cast or use mutable).
|
For now you have many options:
- Move objects with memcpy. This works fine when the object isn't
self-referencing (directly or indirectly), but is non-standard for
non-PODs of course. For the vast majority of "value" types (including
std::containers on implementations I know), memcpy works fine.
- Use mojo, or something similar.
- Just use the suboptimal copy/destruct.
- Implement move constructors on your favourite open source compiler.
:)
- Use default construction and std::swap.
| Quote: | 2. Lack of local functions. I use a lot of "undoable operations" to roll
back partially completed work in case of an exception. I got the idea
originally from Alexandrescu but I've improved on his original work and
you can find them at
http://tnfox.sourceforge.net/TnFOX/html/group__rollbacks.html. Sometimes
the rollback can be quite complex and here you need local functions -
unfortunately these are not permitted, so instead you declare a local
class with a static member function but this furls up the source . If
local classes with static member functions are possible, so are local
functions! I'd particularly love if local functions had access to the
scope in which they are defined.
|
This isn't too hard to do as long as the function doesn't have to
outlive the scope in which it is defined (which it doesn't in your use
case). I wonder whether there are any sample implementations out
there? I saw this:
http://people.debian.org/~aaronl/Usenix88-lexic.pdf. The problem comes
when someone tries to return a pointer to a local function from the
enclosing function...
| Quote: | 3. Removal of stupid and arbitrary limits. There are lots in here but
thankfully most are obvious from reading through the standard. Off the top
of my mind, why can't you define operator new & delete within a namespace
(why aren't they just treated like normal functions with an irregular call
syntax)?
|
They are operators, not functions. However, the name lookup of
operator new/delete could be improved, as you say.
| Quote: | Why can't you template a typedef?
|
This is actually quite complicated, and there is no (or little)
implementation experience yet. The committee isn't a design team, it's
there to standardise existing practice.
Why doesn't the standard
| Quote: | mandate marking in the mangled symbol of non-throwing functions so the
compiler can warn at compile time when a function shouldn't be
non-throwing or indeed when it could (it also helps the optimiser here)?
|
Compile time exception specification checking has been done to death.
It'll probably never happen.
| Quote: | Why can't you initialise aggregate types with compile-time known functions
(I'm thinking compile-time variable arrays here)?
|
What do you mean?
Why can't you mark
| Quote: | virtual functions as being "once" in all subclasses (ie; if there are
virtual functions A::foo() and B::foo and class C inherits A and B in that
order, A's foo() points at B's foo() rather than there being two
(ambiguous) foo()'s) - such a feature would greatly ease mixing run-time &
compile-time polymorphism without introducing the costs of virtual base
class inheritance? Why can't templates have parameterised pieces of code
so we can finally get rid of macros?
|
Such things would just be macros by another name, surely. Unless you
have some suggestions for how name-lookup, scoping, export, etc. would
work with this? Would an improved preprocessor serve the same purpose?
Do you have an example of what you want to use this for? I don't
generally use macros to parametrise "code blocks", only when I need
__LINE__ and __FILE__ in debugging/logging really.
And why is the only way to determine
| Quote: | an unknown type is via template argument deduction via a function which
severely castrates your metaprogramming flexibility (and forces stilted
design)?
|
You'll have to wait for this one, or use the "typeof" extensions that
a few compilers offer (which differs from what will be standardised).
I can go on, but the "D" programming language has many more good
| Quote: | ideas here.
4. Lack of basic tools in the STL (eg; a hash based dictionary container,
reference counting abstract base classes (preferably based on
policy-driven smart pointers), LRU caching etc. etc). This stuff is hardly
new technology - I threw together a generic hash based dictionary
container in a few hours using map, vector and list. It's really not hard.
And no, I don't like hash_map from the SGI library as it's not
configurable enough.
|
TR1 will have both of these.
| Quote: | 5. Speaking of which, the STL in general annoys me. I deliberately don't
use large sections of it and I'm hardly alone here - a large minority of
C++ programmers refuse to use the STL at all. The thing which annoys me
the most is the naming scheme - it consistently names the functions the
least likely thing you'd think of and I personally can't see why lots more
synonyms couldn't be added
|
Code bloat?
| Quote: | (eg; list<>::splice() could also be called
list<>::relink() or craziest of all, list<>::move())
|
Splice is the traditional name for the operation, isn't it? The other
two are less clear to me at least. The classic example of bad naming
is "empty", but it takes all of 10 minutes to become familiar with the
naming conventions used...
.. It's this style
| Quote: | issue and it being totally contrary to how I write my own C++ which makes
me always uncomfortable using it, which is why I wrapped it with a thin
veneer to provide Qt API emulations (see
[url]http://tnfox.sourceforge.net/TnFOX/html/group___q_t_l.html)[/url].
|
That doesn't seem to offer splice under any name that I can see.
| Quote: | The language itself is generally good, though it has an unfortunate habit
of requiring more keyboard typing to create better C++ which means
laziness automatically causes bad C++. However its weakest point IMHO is
the STL which if I had absolute control over the ISO standardisation
process I'd personally start most of it again from scratch and supply thin
veneers emulating the existing STL's API. My new STL would be far more
policy driven as the existing lack of same prevents usage of STL-provided
functionality (eg; searching a list when the predicate isn't fixed nor
simple).
|
The STL probably could do with a rewrite, but probably not for the
reasons you give. e.g. property maps, standardise segmented iterators,
etc. I think the existing policy set for the containers is generally
pretty good - I've never needed to configure them in any way not
supported.
| Quote: | (Note that I am aware that some of my top five most annoying things about
C++ either are being addressed or have been addressed in the next
standard. What's wrong is that none of the above five items require much
work - they are simple - and could be safely added to the standard within
months rather than years.
|
Really? And who is going to do the work? What is going to be
standardized? Do you have a working implementation of the features you
suggest? Have lots of people used it and given you feedback?
| Quote: | They would also require trivial quantities of
additional work by compiler vendors. The fact they are not being applied
with haste means millions of more lines of code must be written to
circumvent them, certainly hundreds of thousands of more programmer hours
must be wasted and I think this is very irresponsible).
|
Have you put any time into the standards process yourself? Do you know
the issues and processes involved in standardisation?
Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.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 ]
|
|
| Back to top |
|
|
Niall Douglas
Guest
|
| Posted: Wed May 26, 2004 2:02 am Post subject: Re: My top five most annoying things about C++ |
|
|
On Tue, 25 May 2004 03:56:06 +0000 (UTC), llewelly
<llewelly.at (AT) xmission (DOT) dot.com> wrote:
| Quote: | Sure, the Unix method makes your job easier to produce something which
functions. However as anyone who has ever compared real-world
application performance between Windows and Unix realises, Unix GUI
applications just go slower - and I was even comparing two
applications both using Qt.
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.
|
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.
| Quote: | What do you think TC1 is, if not the better-labeled equivalent of a
point release?
|
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.
| Quote: | My top five
most annoying features of C++ are:
1. Lack of move constructors. It really, *really* annoys me to see the
generated assembler for using say a string class and see loads of
pointless copying. With move constructors the compiler can optimise
the case when the object being copied is obviously about to get
destroyed. Also, around 5% of the classes I design operate with
move semantics which is a royal PITA when your copy constructor
takes const references (either you const_cast or use mutable).
2. Lack of local functions. I use a lot of "undoable operations" to
roll back partially completed work in case of an exception. I got
the idea originally from Alexandrescu but I've improved on his
original work and you can find them at
http://tnfox.sourceforge.net/TnFOX/html/group__rollbacks.html.
Sometimes
the rollback can be quite complex and here you need local functions
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.
|
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.
| Quote: | 3. Removal of stupid and arbitrary limits. There are lots in here but
thankfully most are obvious from reading through the standard. Off
the top of my mind, why can't you define operator new & delete
within a namespace (why aren't they just treated like normal
functions with an irregular call syntax)?
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.
|
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?
| Quote: | 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.
|
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.
| Quote: | Why doesn't the standard mandate marking in the mangled
symbol of non-throwing functions so the compiler can warn at
compile time when a function shouldn't be non-throwing or indeed
when it could (it also helps the optimiser here)?
*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.
|
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.
| Quote: | 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.
|
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 that any line can throw any exception unless
marked with "throw()". This I've found means you must design and write
code in quite a different fashion than without this constraint - OTOH, you
get code which correctly handles any situation no matter how esoteric.
However it does mean that my code tends to use lots of exceptions - for
indicating parameters are out of bounds for example - and my exception
base class is very "fat". And the numerous use of exceptions causes
especial problems for destructors as it's very easy to throw unwittingly
when a destructor is running higher up the call stack which can raise
fatal exit time again!
If one is to write secure & robust applications in C++ then these
misfeatures can cause you a lot of hassle - getting my nested exception
handling framework working was hard. Certainly more hassle than it could
have with slightly improved wording of the standard.
| Quote: | Why can't you
initialise aggregate types with compile-time known functions (I'm
thinking compile-time variable arrays here)?
What do you mean by this? Surely your compiler supports dynamic
initialization
|
Well I'll tell you what I was doing. I wanted a metaprogramming class
which generates a jump table for a typelist so that a run-time index into
the typelist will call code specialised for that type. I couldn't get
better than a 16 member static const array of function pointers each of
which was initialised by a template which specialised a supplied template
with that type. While another bit of metaprogramming could assemble as
many chunks of 16 as required I couldn't get them to get stored
consecutively and thus would have to have a series of if() statements
choosing which table to use (or I could have a jump table jumping into
jump tables). Ideally I'd want to generate an array of arbitrary length
initialised with an arbitrary number of function pointers but the
aggregate initialiser syntax won't help you here. Non-standard GCC (and I
think MSVC) extensions will though so it can't be hard to implement.
| Quote: | I deliberately
don't use large sections of it and I'm hardly alone here - a large
minority of C++ programmers refuse to use the STL at all.
IMO, most of them are costing themselves time, costing their
co-workers time, and if you work with their code, costing you time.
|
I agree that the benefits of everyone using the same library are
undervalued. However that said, I personally tend to use something if it
seems to me to add value. If it doesn't, I don't use it.
A good example here is choice of metaprogramming library. Dave Abrahams
tried his best to get me to use Boost but I instead went with writing my
own. It's not that I have anything against Boost apart from it
unfortunately replicating the style of the STL, but my own library is much
easier to use and less obtuse as I can mandate use of a partial template
specialisation supporting compiler.
| Quote: | The language itself is generally good, though it has an unfortunate
habit of requiring more keyboard typing to create better C++ which
means laziness automatically causes bad C++. However its weakest point
IMHO is the STL which if I had absolute control over the ISO
standardisation process I'd personally start most of it again from
scratch and supply thin veneers emulating the existing STL's API.
[snip]
What would this achieve? The standard only defines an interface.
|
It would achieve a migration path onto a better standard template library.
| Quote: | I realize that those of you who never leave the bounds of Purified
Natural Filtered Sanctified OO find the STL's favortism towards
value types bizzare, confusing, and inappropriate, but those of
us who don't have entity types falling out of ears generally
appreciate it.
|
Heh, I am one of the few programmers I know of who dislikes OO and thinks
it a bad thing.
| Quote: | Again, it would be niced to see it improved in various ways, and nice
to see it complemented by something that better supported entity
types, but it shouldn't be removed or replaced.
|
I'm afraid I don't know what an entity type is. What I would like to see
in a replacement STL is use of traits so metaprogramming can far better
optimise operation, a layered hierarchy of implementation by inheritance
(policies) so it's much easier to reuse parts of a STL container
implementation but reimplement other parts (this is hard right now) and
better genericity eg; iterators which operate the same no matter which
container they belong to (eg; list<>::iterator could be +='d and -='d just
like a vector<>::iterator). I would also redo algorithms as worker classes
rather than supposedly generic functions eg; ContainerSorter which when
instantiated with a vector<> instance provides the "perfect" stable and
non-stable sorts etc. but can also be subclassed to customise it further.
I vaguely remember Alexandrescu saying he was working on a STL
reimplementation called YASLI. Did anything ever come of that?
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.jamesd.demon.co.uk/csc/faq.html ]
|
|
| Back to top |
|
|
Wil Evers
Guest
|
| Posted: Wed May 26, 2004 2:45 am Post subject: Re: My top five most annoying things about C++ (was: Re: n14 |
|
|
In article <opr8ikyhjey9klrv (AT) news (DOT) iol.ie>, Niall Douglas wrote:
| Quote: | Though I cannot speak for them, I cannot see Microsoft up-ending the
Windows DLL mechanism just for ISO C++ compliance. DLL's are absolute core
to Windows because unlike Unix it was designed from the beginning with
them in mind. If the ISO C++ spec adopts a mechanism incompatible with
Win32, then that feature will likely be ignored on the vast majority of
the world's computers.
|
Obviously Microsoft isn't going to break the current DLL linking and loading
machinery. However, I see no reason why Microsoft wouldn't be able to
*extend* it to support other (and more C++-friendly) approaches to dynamic
linking.
- Wil
--
Wil Evers, DOOSYS R&D BV, Utrecht, Holland
[Wil underscore Evers at doosys dot 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 ]
|
|
| Back to top |
|
|
Davide Bolcioni
Guest
|
| Posted: Wed May 26, 2004 2:46 am Post subject: Re: n1496 (was: My top five most annoying things about C++) |
|
|
Niall Douglas ha scritto:
| Quote: | On Sun, 23 May 2004 00:18:04 +0000 (UTC), Davide Bolcioni wrote:
the notion that shared libraries are
not something which should concern the language, only the linker, made
my job exceedingly easier.
Sure, the Unix method makes your job easier to produce something which
functions. However as anyone who has ever compared real-world
application performance between Windows and Unix realises, Unix GUI
applications just go slower - and I was even comparing two applications
both using Qt.
|
I cannot comment on that, as my exposure to Qt was limited; my personal
impression on the old Athlon 700 I'm currently using is that Linux is
perceptibly faster, so your mileage may vary.
| Quote: | If you go the Unix route, code *quality* suffers because it's much
easier for the programmer to be lazy. If you go the Windows route, you
get as perfect quality as you can for free with slightly more work. You
already know which I prefer but I'll elaborate below.
|
I disagree, see below.
| Quote: | BTW in N1496 appendix item 4 I can confirm that the Unix mechanism
cannot be implemented on Windows.
Given the time scale expected of C++0x, maybe the right question is
whether it is implementable for .NET ?
I personally feel that when producing language standards as with any
standard, the format should be big release, then point 1 release and
point 2 release with point 2 released as the next big release is in
preparation. ISO C++ has not followed this, much to its detriment
|
Point release or major release, it is due in a few years; I expect Win32
to be legacy by then, in the sense Win16 was, and that was the point of
my remark. We might be saddling C++0x with a solution for a problem
which solved itself, and leave it unable to express a solution for a
real problem of its time. Furthermore, we have C99 which is similarly
silent on the matter and will be for a few more years.
| Quote: | Now we have most major compilers nearly complying with the standard ...
[cut] |
Interesting points, each probably deserves its own thread so I'll not
elaborate here.
| Quote: | This should be of interest only to people implementing a linker, in my
opinion.
Though I cannot speak for them, I cannot see Microsoft up-ending the
Windows DLL mechanism just for ISO C++ compliance. DLL's are absolute
core to Windows because unlike Unix it was designed from the beginning
with them in mind.
|
I agree this is unlikely. Any such matter would be addressed by the
compiler, as they're now.
| Quote: | If the ISO C++ spec adopts a mechanism incompatible
with Win32, then that feature will likely be ignored on the vast
majority of the world's computers.
|
The C++ standard currently ignores this peculiar behavior of a widespread
platform and this has not hindered its success on said platform; the
probl | | |
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
