C++0x
Francis Glassborow
Copenhagen listening to an evening presentation by Bjarne Stroustrup
launching his view of the next stage in the ongoing development of C++.
We have had a number of years (three or more) of stability with an ISO
Standard for C++ and failure to consider change will tend to move from
stability (good for many reasons) to stagnation (put your own spin on
that)
BS has just suggested that we should focus on a few major topics while
considering minor changes that will increase language and standard
library consistency.
He is floating the idea that the overall goals should include making C++
a better language for systems programming and library building. A second
major goal should be to make it easier to teach and learn (aside from me
-- we would still have the problem of getting those teaching to actually
know what they are doing)
Directions:
Minimise incompatibilities with C++98 but we should face reality and
accept that some changes will break exiting code (like the move form C
to C++)
Keep the zero overhead principle
Maintain or increase type safety
Avoid major extensions to the language
make rules more general and uniform
improve support for low level embedded programming (note BS explicitly
does not want to see C++ become an exclusively high level language)
Increase library support for platform independence
support distributed programming (actually, programming for distributed
systems)
He says that if we are ambitious in library development (something he is
advocating) we need to accept that some developments will not be
supportable on all platforms.
At this stage he is beginning to explore specific ideas for library
development. I will leave the specifics for later contributors to add.
The intention of this posting is to alert the serious C++ community to
the fact that the C++ standards committees are now willing to listen
(after a long day of working on defects in the current standard) to the
originator of C++ make suggestions for ways in which we might move
forward. You should not get the idea that we are about to launch a
basket of changes and destabilise what we have. What we are sitting on
is a watershed when we move from purely correcting and clarifying what
we have already done to considering how we might make the good even
better.
I am sure that BS's current presentation will be heard and refined many
times over the next few years. If you are responsible for organising
meetings, conferences or write for journals and magazines take the
opportunity to invite BS to contribute his vision of the future of C++.
But remember that this should be a shared vision. The readers of this
posting (here and copied to clc++m) are those that should be adding
clarity to the vision. We each have our own pet ideas, but we should
listen as well as talk. Change should come from a consensus of the C++
programming community in the large rather than just that of the
Standards Committees. That consensus requires an investment of time, any
time you find yourself muttering 'someone ought to do something about
that' remember that you are someone.
This writer can see a danger in some enthusiasts being so determined to
get their pet item into C++0x that they will be blind to the larger
picture.
I think that is enough for now apart from drawing your attention to the
fact that you read this here first and it was ACCU that brought it to
you attention.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Dennis Yelle
Let's start a list:
1. typeof()
2. using Base;
Example:
class Derived : private Base {
public:
using Base; // expose the entire public interface of Base.
// ...
};
3. explicit operator.
Example:
class My_class {
public:
// ...
// allow int(My_class()), but not int i = My_class();
explicit operator int();
};
4. Zero sized objects.
This would require lengthof() because the standard idiom would break:
#define lengthof(x) (sizeof(x)/sizeof((x)[0]))
On the other hand, who puts zero sized objects in an array?
5. Require the "empty base class optimization".
6. Abolish trigraphs,
or at least depreciate trigraphs.
What else?
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
Howard Gardner
> I am writing this sitting in a room at the Danish Standards in
> Copenhagen listening to an evening presentation by Bjarne Stroustrup
> launching his view of the next stage in the ongoing development of C++.
> Keep the zero overhead principle
For the love of humanity, define the value of a "default" constructed builtin!
James Dennett
>
> Francis Glassborow wrote:
>
> > I am writing this sitting in a room at the Danish Standards in
> > Copenhagen listening to an evening presentation by Bjarne Stroustrup
> > launching his view of the next stage in the ongoing development of C++.
>
> > Keep the zero overhead principle
>
> For the love of humanity, define the value of a "default" constructed builtin!
Compilers are free to do so, if you choose the overhead. Right
now they/you have the choice between safety and efficiency. If
the Standard mandates safety, efficiency will be impossible.
-- James Dennett
Ron Natalie
Dennis Yelle wrote:
> 2. using Base;
> Example:
>
> class Derived : private Base {
> public:
> using Base; // expose the entire public interface of Base.
> // ...
> };
This is really clunky. "using" brings names forward which have no
bearing on access control. I'm at a loss as to what this does that
just inheriting Base publically doesn't.
>
> 3. explicit operator.
> Example:
>
> class My_class {
> public:
> // ...
> // allow int(My_class()), but not int i = My_class();
> explicit operator int();
> };
Ugh...why not just add an explicit method.
> 4. Zero sized objects.
> This would require lengthof() because the standard idiom would break:
>
> #define lengthof(x) (sizeof(x)/sizeof((x)[0]))
>
> On the other hand, who puts zero sized objects in an array?
I think it would break far more than ad-hoc size macros. Why do you need
zero sized objects.
> 5. Require the "empty base class optimization".
Why?
>
> 6. Abolish trigraphs,
> or at least depreciate trigraphs.
>
Why? (and the word is deprecate).
Hans Aberg
<fran...@robinton.demon.co.uk> wrote:
>...Bjarne Stroustrup
>launching his view of the next stage in the ongoing development of C++.
>BS has just suggested that we should focus on a few major topics while
>considering minor changes that will increase language and standard
>library consistency.
>
>He is floating the idea that the overall goals should include making C++
>a better language for systems programming and library building. A second
>major goal should be to make it easier to teach and learn (aside from me
>-- we would still have the problem of getting those teaching to actually
>know what they are doing)
Amiss (even though mentioned below) in this general picture is support for
distributed programming.
Also amiss is support for dynamic programming, like support for the hooks
that enables the efficient implementation of a conservative GC (like a way
to get access to the root system.
One will need some such additions in order to be able to build good libraries.
As for the teaching aspect, I think this must be always secondary to the
aspect of C++ as a language designed to get things done. To me, it is OK
that C++ is a behemoth and an encyclopaedia one never bother learning in
its completeness: When one needs a feature.
If I should compare with Haskell, the standardization into a language
Haskell 98 which will never change was in itself enough for providing the
educational aspect.
One should warn against that looking too much on this educational aspect
one complicate the language: For example, the class std::list did not get
operator plus, because it was felt that less experienced programmers one
use that. Real programmers should use a profiler to determine what and how
to optimize. So in this case, the educational aspect made the language
more complicated and less based on general principles, the latter which
C++ is in the need of more.
>Directions:
>
>Minimise incompatibilities with C++98 but we should face reality and
>accept that some changes will break exiting code (like the move form C
>to C++)
>
>Keep the zero overhead principle
>Maintain or increase type safety
>
>Avoid major extensions to the language
>make rules more general and uniform
>improve support for low level embedded programming (note BS explicitly
>does not want to see C++ become an exclusively high level language)
>
>Increase library support for platform independence
>support distributed programming (actually, programming for distributed
>systems)
>
>He says that if we are ambitious in library development (something he is
>advocating) we need to accept that some developments will not be
>supportable on all platforms.
>
>At this stage he is beginning to explore specific ideas for library
>development.
In this support for distributed programming, there is hidden a C/C++
principle that one must depart from, namely that they are written so that
one from compiler to compiler never can specify the underlying binary
model: Even a byte, even though nowadays always a standard 8 bit, one
cannot rely on.
This problem shows up in other contexts: For example, if one tries to a
functional language style boxed/unboxed elements, that is screwed up by
the fact that when deriving one can never get ensurance where on the
object the class pointer is. Therefore, in principle, self-mutation of
unboxed elements into another type in the same memory location may screw
up.
The support for low level embedded programming is good: I expect embedded
programmers to be transformed into what is now regular C++ programmers as
the computers become more powerful. When this discussed in the C++
newsgroups, there was this joke about the bread machine with its own
WWW-site. But there is a fact that there is a standard to connect
household appliances to the Internet via the electrical cord. And if
memory doubles every year, then a bread machine that a few years had 50 kB
in its memory 10 years later will have 50 MB, and yet ten years later 50
GB, at which point it will be cheaper to let it have its own WWW site than
building a electro-mechanical interface on it.
Also, I think there is a connection between dynamic programming and low
level programming: In order to take an easy example, if one wants to build
a multi-precision number library, one needs to do a lot of low level
optimizations. As matters now stand, such things must be implemented
platform to platform in assembler. The implementation of functional
languages really need such low level optimizations in order to be
competitive with more static languages.
The more static C++ programmers of today will surely gradually become more
dynamic programmers when computers become more powerful, as dynamic
programming is requires less programming time. So for that reason, it will
be important to start to incorporate such features at this point in time.
So it would be great if such things could be done more directly in C++.
Perhaps ideas form a language like C-- should be integrated into C++.
Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <remove...@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
Markus Schaaf
> Howard Gardner wrote:
>>
>> For the love of humanity, define the value of a "default" constructed builtin!
>
> If the Standard mandates safety, efficiency will be impossible.
I'm not even sure, if what you would get is safety. If you've
forgotten to initialize variables, why would zero be the _safe_
choice?
Most often I became aware of failure to set variables, in release
builds, when the compiler had omitted zero-initialization, and all
my programme's output was rubbish. Unfortunally there is a difference
between plausibility and correctness.
Just my 2 cents.
Scott Robert Ladd
impressed with Bjarne's recent efforts.
A few preliminary thoughts...
First, we need to look at the current standard and refine it, *before*
adding new features. Certainly we need to address all defect reports -- but
we also need to consider inconsistencies. My recent topic about openmode is
an example: It should be possible to interrogate the state of that property
for a stream. Is that a defect? Probably not. Is such a feature simple and
useful, leading to more reliable code? Yes.
Second: The more hands we get into the process, the more difficult it will
be to find a consensus. I know, I've been part of standards processes
before... everyone has a pet feature they'd love to have in the language,
and we don't want to lose focus. C++ should *not* try to be everything to
everyone; that's Java's job :-). Instead of adding anything and everything
to the language, I'd rather see a few new, well-conceived features. I want
concurrency, for example -- but if we can't find a clean, logical way to
include it in C++, I'll live without it.
Third: I strongly urge that we move beyond a poorly-formatted rigid document
to a hyperlinked, well-formatted, easy-to-read publication. Contrast the C++
Standard with W3C documents, and you'll see what I mean. A lot of confusion
and frustration could be solved simply by organizing and formatting the
document better.
Fourth: While I understand how standards committees work, most programmers
don't. The Standards process would do well to use the web actively in
keeping the community well-informed as to its activities. If we're going to
ask people to participate, they need to feel included, even if they can't
afford to travel. That is the strength of the Internet -- bringing people
together. Let's do it.
As for *my* personal laundry list of goodies -- give me a day or two here...
:-)
--
Scott Robert Ladd
Master of Complexity, Destroyer of Order & Chaos
http://www.coyotegulch.com
Howard Gardner
>>> For the love of humanity, define the value of a "default" constructed builtin!
>>
>> If the Standard mandates safety, efficiency will be impossible.
>
> I'm not even sure, if what you would get is safety. If you've
> forgotten to initialize variables, why would zero be the _safe_
> choice?
It doesn't make the program correct (unless 0 really was the right value), it makes the resulting disaster easier to reproduce. That, in turn, makes the error easier to find.
I can't count the hours I've spent tracking down uninitialized variable bugs (sometimes even my own) of one form or another.
As for the choice between efficiency and safety, you could add syntax to say "don't initialize."
int a = uninitialized;
or
uninitialized int a;
So it's really a choice between adding syntax and unreproducible bugs.
The way it sits many of us are paying for a feature (efficiency) that we don't use.
I bet instructors would like to get rid of the whole topic too, for that matter.
James Dennett
>
> "James Dennett" <jden...@acm.org> wrote:
>
> > Howard Gardner wrote:
> >>
> >> For the love of humanity, define the value of a "default" constructed builtin!
> >
> > If the Standard mandates safety, efficiency will be impossible.
>
> I'm not even sure, if what you would get is safety. If you've
> forgotten to initialize variables, why would zero be the _safe_
> choice?
Safe as in reproducible, at least. I'm not an advocate
of making this change globally, but I can understand those
who want something like it.
> Most often I became aware of failure to set variables, in release
> builds, when the compiler had omitted zero-initialization, and all
> my programme's output was rubbish. Unfortunally there is a difference
> between plausibility and correctness.
>
> Just my 2 cents.
You can have 2 of mine to go with them. I don't want to
globally mandate that
{
int i;
// ...
}
has the run-time overhead of initializing i.
-- James Dennett
Robert FISHER
>
> So, what do we want?
>
> Let's start a list:
>
[...good suggestions edited for brevity...]
>
> What else?
>
Finally: I understand that some think that everyone everywhere should
always, without exception (pun intended), use "resource acquisition is
initialization". Personally, however, I like the fact that C++ is a
multiparadigm language, and there are times when I'd find a finally
block extremely useful.
How about being able to place some restrictions on a class that are
enforced by the compiler. Non-derivable classes. Classes that can't be
placed on the stack/heap. Etc. Sure, there are some idioms that allow
some of these things to be done within the existing language, but they
are often verbose, inelegant, or both. (I want to say what I mean,
rather than say something that coincidentally has the side effect of
what I mean.)
How about a way to say that all of a class's member functions (and all
of its subclasses' member functions) should be virtual by default.
How about a (good, simple, portable, safe, efficient) way to tell
whether an object was allocated with new and can be safely deleted? (In
other words, not one of the kludges that have been created using the
existing language.) Imagine objects that can actually tell whether it is
safe to delete themselves or not. This might be the one thing I'd most
like to see.
(Also, a way to tell whether you should use delete or delete[] might be
useful. How about a way to find the size of an array allocated by new[].
Presumably the runtime has to keep track of such information anyway so
that delete[] works properly.)
The honorable Mr. Stroustrup has mentioned eliminating the default copy
constructor and assignment operator for classes with destructors and
making base classes with virtual member functions have a virtual
destructor by default. These will be very welcome changes.
Any remaining fix necessary to ensure that smart pointers can be
completely safe needs to be made. (I know there used to be some issues
about this.)
I'd ask anyone who has implemented an automatic garbage collector for
C++ what could be done to make C++ more garbage collector friendly.
(Last I looked into it, there was an issue or two.) Even better, ensure
that the major automatic garbage collection techniques can be
implemented in pure, portable C++. (Of course, such garbage collectors
would only be expected to collect C++ objects.)
Am I the only one that hates the standard library? The blatant, violent
abuse of operator overloading by the I/O streams has kept me from EVER
using them. I respect and admire the STL classes, but I hate using them
for reasons I haven't quite completely identified yet. Sure, it's too
late to make any radical changes, but I'd sure like to see an
"alternative standard library".
I also applaud Mr. Stroustrup's thoughts that the standard library
should address such common modern issues as concurrency. (And any holes
in the language that might make addressing such issues difficult.)
--
Robert FISHER
rfi...@my-deja.com
Dennis Yelle
>
> Markus Schaaf wrote:
>
> >>> For the love of humanity, define the value of a "default" constructed builtin!
> >>
> >> If the Standard mandates safety, efficiency will be impossible.
> >
> > I'm not even sure, if what you would get is safety. If you've
> > forgotten to initialize variables, why would zero be the _safe_
> > choice?
>
> It doesn't make the program correct (unless 0 really was the right value), it makes the resulting disaster easier to reproduce. That, in turn, makes the error easier to find.
>
> I can't count the hours I've spent tracking down uninitialized variable bugs (sometimes even my own) of one form or another.
What compiler are you using?
Have you turned on all of the warnings?
For this program:
===================
int main()
{
int i;
return i;
}
=================
MSVC++ 6.0 says:
test.cpp(4) : warning C4700: local variable 'i' used without having
been initialized
and gcc version 2.95.3 20010315/djgpp (release) says:
test.cpp:3: warning: `int i' might be used uninitialized in this
function
If you are using a compiler that cannot produce a warning for this,
I think you should change to a better compiler.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
---
James Dennett
>
> Markus Schaaf wrote:
>
> >>> For the love of humanity, define the value of a "default" constructed builtin!
> >>
> >> If the Standard mandates safety, efficiency will be impossible.
> >
> > I'm not even sure, if what you would get is safety. If you've
> > forgotten to initialize variables, why would zero be the _safe_
> > choice?
>
> It doesn't make the program correct (unless 0 really was the
> right value), it makes the resulting disaster easier to reproduce.
> That, in turn, makes the error easier to find.
I agree with that.
>
> I can't count the hours I've spent tracking down uninitialized
> variable bugs (sometimes even my own) of one form or another.
I spent several hours a couple of weeks ago tracking down an
uninitialized pointer bug in some third-party code. A waste
of time, but it probably would have been no easier (maybe
even less easy) if the pointer value was 0 rather than garbage.
>
> As for the choice between efficiency and safety, you
> could add syntax to say "don't initialize."
>
> int a = uninitialized;
>
> or
>
> uninitialized int a;
>
> So it's really a choice between adding syntax and unreproducible bugs.
That's a "quiet change" though, in the sense that
int a;
changes meaning to become less efficient, and so billions of
lines of existing code become less efficient.
I'd prefer something like a Standard pragma (though historically
pragmas have been a pain) such as
#pragram STDC++ always-initialize
> The way it sits many of us are paying for a feature (efficiency) that we don't use.
And many of us don't want to pay for a feature (possibly more
easily reproducible bugs) that we don't use at the expense of
code which runs more slowly.
> I bet instructors would like to get rid of the whole topic too, for that matter.
That may well be true.
-- James Dennett
Stephen Howe
Dennis Yelle <denn...@jps.net> wrote in message
news:3AEF1353...@jps.net...
> 4. Zero sized objects.
> This would require lengthof() because the standard idiom would break:
> #define lengthof(x) (sizeof(x)/sizeof((x)[0]))
> On the other hand, who puts zero sized objects in an array?
For what benefit? I could imagine that disadvantages of it breaking code
outweighs any benefits.
> 5. Require the "empty base class optimization".
Currently, I cannot find examples where "optimisations" are a requirement of
the standard. Another example might be the requirement for return value copy
constructor optimisations. I don't think the standard should set a precedent
for compiler vendors to meet "optimisations" however desireable they are.
Stephen Howe
Ron Natalie
Dennis Yelle wrote:
>
> So, what do we want?
>
My favorites, but unlikely to be implemented:
1. Make arrays real types.
2. Prohibit freebie const lossage on string literals.
3. Initialize POD's consistantly.
Niklas Matthies
> So, what do we want?
>
> Let's start a list:
> 4. Zero sized objects.
> This would require lengthof() because the standard idiom would break:
>
> #define lengthof(x) (sizeof(x)/sizeof((x)[0]))
>
> On the other hand, who puts zero sized objects in an array?
Could you elaborate how exactly you think that zero-sized objects should
be implemented? In particular, what layout would an array of zero-sized
objects have, and how would pointers to zero-sized objects behave?
-- Niklas Matthies
Radoslav Getov
>
> Let's start a list:
>
> 1. typeof()
>
> 2. using Base;
> Example:
>
> class Derived : private Base {
> public:
> using Base; // expose the entire public interface of Base.
> // ...
> };
>
> 3. explicit operator.
> Example:
>
> class My_class {
> public:
> // ...
> // allow int(My_class()), but not int i = My_class();
> explicit operator int();
> };
>
> 4. Zero sized objects.
> This would require lengthof() because the standard idiom would break:
>
> #define lengthof(x) (sizeof(x)/sizeof((x)[0]))
>
> On the other hand, who puts zero sized objects in an array?
>
> 5. Require the "empty base class optimization".
>
> 6. Abolish trigraphs,
> or at least depreciate trigraphs.
>
> What else?
>
- typeof
- some multithreading support (more order of evaluation garanties)
- final (disabling farther overriding of a virtual function)
- sized (int8 etc) or templated std::int<128> integers
- did I mention 'typeof'?
Radoslav Getov
Daniel Frey
>
> Dennis Yelle wrote:
>
> > 3. explicit operator.
> > Example:
> >
> > class My_class {
> > public:
> > // ...
> > // allow int(My_class()), but not int i = My_class();
> > explicit operator int();
> > };
>
> Ugh...why not just add an explicit method.
No. An explicit method has a name like asXyz, toXyt, convertToXyZ,
conv2Xyz, as_xyz, to_xyz, convert_xyz and whatever comes to peoples
crazy minds. When working with templates, this is completely useless.
Also, asString() could return std::string, char*, RWCString or whatever
people think is *their* standard. We need explicit operators to allow
templates to use these functions. OTOH you cannot use cast-operators
without explicit because it's far too dangerous for most cases.
While we are at it, this could be used for other parameters too: void
hello( explicit const std::string& s ) could means: Don't convert
anything to string by creating a temporary object to call this function.
explicit for an operator is just like the explicit here but for '*this'.
Hope you get the idea, I'm not very good in expressing myself clearly in
english :)
Regards, Daniel
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: danie...@aixigo.de, web: http://www.aixigo.de
Dennis Yelle
[...]
> Am I the only one that hates the standard library? The blatant, violent
> abuse of operator overloading by the I/O streams has kept me from EVER
> using them. I respect and admire the STL classes, but I hate using them
> for reasons I haven't quite completely identified yet. Sure, it's too
> late to make any radical changes, but I'd sure like to see an
> "alternative standard library".
What are you looking for?
That is, how will you recognize it when you see it?
Is it just that the STL is too large?
The STL definitely has some warts.
Like, why does vector have all of:
size(), resize(), reserve(), and capacity()?
we could instead have:
size_t size();
void size( size_t);
size_t capacity();
void capacity( size_t);
And, to me, this would be easier to explain, learn, and remember.
But, I am not sure that it is worth changing at this stage.
But, then again, maybe it is.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
---
Hans Aberg
Robert Ladd" <sc...@coyotegulch.com> wrote:
> Instead of adding anything and everything
>to the language, I'd rather see a few new, well-conceived features. I want
>concurrency, for example -- but if we can't find a clean, logical way to
>include it in C++, I'll live without it.
This is also one thing that I think should be named in the general
picture: Concurrency support, not only for locks, but also for atomic
code.
But perhaps, if one adds support for distributed programming, concurrency
support must be a part of that.
>Third: I strongly urge that we move beyond a poorly-formatted rigid document
>to a hyperlinked, well-formatted, easy-to-read publication.
Actually, when I bought my copy I suggested the ANSI people just that. I
g惠igure that this has something to do with the obsolete software used by
the ISO/ANSI staff, because hyperlinks ought to be automatic with the
right kind of authoring software.
Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <remove...@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
Andrei Alexandrescu
news:3AEF68FD...@acm.org...
> Howard Gardner wrote:
> > For the love of humanity, define the value of a "default" constructed
builtin!
>
> Compilers are free to do so, if you choose the overhead. Right
> now they/you have the choice between safety and efficiency. If
> the Standard mandates safety, efficiency will be impossible.
Efficiency is not always the enemy of safety. Imagine C++ had a keyword
'uninitialized' that you could use like so:
void Fun()
{
int i = uninitialized;
int j; // initialized with zero
...
}
There are multiple advantages to this approach - defaults to safe, and
allows you to optimize when you need.
Andrei
Ron Natalie
James Dennett wrote:
>
> I'd prefer something like a Standard pragma (though historically
> pragmas have been a pain) such as
>
> #pragram STDC++ always-initialize
Only if it is REQUIRED to be impelemented is this useful. If it's
optional, the feature suddenly becomes VERY VERY DANGEROUS. I suggest
that if we're going to have compile standardized compile controls that
they NOT be called PRAGMA.
Ron Natalie
Dennis Yelle wrote:
>
> Howard Gardner wrote:
> >
> > Markus Schaaf wrote:
> >
> > >>> For the love of humanity, define the value of a "default" constructed builtin!
> > >>
> > >> If the Standard mandates safety, efficiency will be impossible.
> > >
> > > I'm not even sure, if what you would get is safety. If you've
> > > forgotten to initialize variables, why would zero be the _safe_
> > > choice?
> >
> > It doesn't make the program correct (unless 0 really was the right value), it makes the resulting disaster easier to reproduce. That, in turn, makes the error easier to find.
> >
> > I can't count the hours I've spent tracking down uninitialized variable bugs (sometimes even my own) of one form or another.
>
> What compiler are you using?
> Have you turned on all of the warnings?
>
> For this program:
> ===================
> int main()
> {
> int i;
> return i;
> }
> =================
\
Because this is a trivial instantiation of the problem.
How about
int* i = new i;
and
struct x {
int i;
};
The compiler will warn you of neither of these, typically.
Rene
programming language!! I am new to C++ so I don't want to open my mouth too
much, but as far as I know its been 3 years since the language settled, and
it looks like it will take 3 more to make changes. Then after the changes
had been decide on, we have to wait another year for the compiler people to
do their part and make it stable. In the mean time there are other
programming languages being created that are very innovating.
I don't mean to piss anybody off with this email; I just find it frustrating
to see technology advancing so fast and C++ just crawling.
Thank you.
John Potter
wrote:
> No. An explicit method has a name like asXyz, toXyt, convertToXyZ,
> conv2Xyz, as_xyz, to_xyz, convert_xyz and whatever comes to peoples
> crazy minds. When working with templates, this is completely useless.
> Also, asString() could return std::string, char*, RWCString or whatever
> people think is *their* standard. We need explicit operators to allow
> templates to use these functions. OTOH you cannot use cast-operators
> without explicit because it's far too dangerous for most cases.
Writing templates is no problem. Note that the standard library did
not write an explicit cast in copy to allow conversions. It wrote
transform to accept a named conversion.
Can you give a concrete example to support your claim?
John
James Dennett
>
> James Dennett wrote:
> >
> > I'd prefer something like a Standard pragma (though historically
> > pragmas have been a pain) such as
> >
> > #pragram STDC++ always-initialize
(Oops, I see that can't type pragma. Lack of practice.)
>
> Only if it is REQUIRED to be impelemented is this useful.
Absolutely. (And that's a good reason not to call it pragma.)
> If it's
> optional, the feature suddenly becomes VERY VERY DANGEROUS. I suggest
> that if we're going to have compile standardized compile controls that
> they NOT be called PRAGMA.
Well, as we like over-using existing keyword, how about
"auto intialize;" at namespace scope?
That's a joke: I would like to see a Standard mechanism
to allow evolution, such that a compiler which fails to
support feature X can be detected at compile-time even if
only by the fact that it aborts compilation with an
"unsupported feature requested" message.
-- James Dennett
Dennis Yelle
>
> "James Dennett" <jden...@acm.org> wrote in message
> news:3AEF68FD...@acm.org...
> > Howard Gardner wrote:
> > > For the love of humanity, define the value of a "default" constructed
> builtin!
> >
> > Compilers are free to do so, if you choose the overhead. Right
> > now they/you have the choice between safety and efficiency. If
> > the Standard mandates safety, efficiency will be impossible.
>
> Efficiency is not always the enemy of safety. Imagine C++ had a keyword
> 'uninitialized' that you could use like so:
>
> void Fun()
> {
> int i = uninitialized;
> int j; // initialized with zero
> ...
> }
>
> There are multiple advantages to this approach - defaults to safe, and
> allows you to optimize when you need.
Yes, I think you are right.
It is time to do this.
Compilers are already doing the analysis to determine that
most variables are already initialized before being used.
The only time that this would add runtime overhead is when
that compile time analysis fails, which is fairly rare.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
---
Dennis Yelle
>
> On Tue, 1 May 2001 22:27:12 GMT, Dennis Yelle <denn...@jps.net> wrote:
> > So, what do we want?
> >
> > Let's start a list:
> [···]
> > 4. Zero sized objects.
> > This would require lengthof() because the standard idiom would break:
> >
> > #define lengthof(x) (sizeof(x)/sizeof((x)[0]))
> >
> > On the other hand, who puts zero sized objects in an array?
>
> Could you elaborate how exactly you think that zero-sized objects should
> be implemented? In particular, what layout would an array of zero-sized
> objects have,
A single zero sized object would have a sizeof 0.
An array of zero sized objects would have a sizeof 0.
Or to put it another way:
struct nothing {};
assert ( 0 == sizeof(nothing) );
nothing junk[10000];
assert ( 0 == sizeof( junk));
> and how would pointers to zero-sized objects behave?
When you increment them, decrement them, or add (or subtract)
a size_t to (from) them, they do not change.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
---
Ron Natalie
Dennis Yelle wrote:
>
> When you increment them, decrement them, or add (or subtract)
> a size_t to (from) them, they do not change.
>
And the use of this nothingness is?
James Dennett
>
> Dennis Yelle wrote:
>
> > 2. using Base;
> > Example:
> >
> > class Derived : private Base {
> > public:
> > using Base; // expose the entire public interface of Base.
> > // ...
> > };
>
> This is really clunky. "using" brings names forward which have no
> bearing on access control. I'm at a loss as to what this does that
> just inheriting Base publically doesn't.
It disallows most conversions from Derived to Base, hence
avoiding problems (e.g.) with non-virtual destructors.
> > 3. explicit operator.
> > Example:
> >
> > class My_class {
> > public:
> > // ...
> > // allow int(My_class()), but not int i = My_class();
> > explicit operator int();
> > };
>
> Ugh...why not just add an explicit method.
Generic programming can't reasonably know the name of the explicit
method, whereas various casts are almost univerally usable for
conversions.
> > 4. Zero sized objects.
> > This would require lengthof() because the standard idiom would break:
> >
> > #define lengthof(x) (sizeof(x)/sizeof((x)[0]))
> >
> > On the other hand, who puts zero sized objects in an array?
>
> I think it would break far more than ad-hoc size macros. Why do you need
> zero sized objects.
I can't see what this gains us either.
> > 5. Require the "empty base class optimization".
>
> Why?
How? As in, how would you word this requirement?
-- James Dennett
Michael Lee Finney
conversion can only happen explicitly. How about
allowing "implicit" so that a conversion is treated at
the same level as other implicit conversions?
Having the built-in conversions on a level we can't
reach can be very awkward sometimes. It should be
possible for a user defined conversion to be treated
identically to the language defined conversions.
James Kuyper Jr.
>
> We already have "explict" to indicate that a
> conversion can only happen explicitly. How about
> allowing "implicit" so that a conversion is treated at
> the same level as other implicit conversions?
>
> Having the built-in conversions on a level we can't
> reach can be very awkward sometimes. It should be
> possible for a user defined conversion to be treated
> identically to the language defined conversions.
User-defined conversion functions and converting constructors are
already treated almost the same as the built-in conversions. The main
difference is that an implicit conversion sequence cannot contain more
than one user-defined conversion. Is that the restriction you're asking
to have removed for functions declared "implicit"?
Dima Volodin
>
> [...]
> make rules more general and uniform
> improve support for low level embedded programming (note BS explicitly
> does not want to see C++ become an exclusively high level language)
Finally eliminate register and volatile and introduce a generic mechanism to
indicate a class' or an object's location in an implementation specific storage
type and/or location.
> Francis Glassborow ACCU
Dima
trying to be consistent
Francis Glassborow
writes
>A single zero sized object would have a sizeof 0.
>An array of zero sized objects would have a sizeof 0.
The problem is that, as the language is currently designed, objects have
to have addresses. Currently we can just get away with making subobjects
of different types share addresses.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Francis Glassborow
<nos...@mai.com> writes
>- did I mention 'typeof'?
Yes, and so did Bjarne Stroustrup in his talk:) so the message seems to
be getting through.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
Francis Glassborow
writes
>That's a joke: I would like to see a Standard mechanism
>to allow evolution, such that a compiler which fails to
>support feature X can be detected at compile-time even if
>only by the fact that it aborts compilation with an
>"unsupported feature requested" message.
That might be useful. One thing Bjarne suggested is that C++ compilers
in transition from today to the future should be required to implement
new features in a specified order. IOWs if it supports feature X it is
required to support all features prior to X.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
Francis Glassborow
anst.tninet.se>, Hans Aberg <remove...@matematik.su.se> writes
>Amiss (even though mentioned below) in this general picture is support for
>distributed programming.
>
>Also amiss is support for dynamic programming, like support for the hooks
>that enables the efficient implementation of a conservative GC (like a way
>to get access to the root system.
>
>One will need some such additions in order to be able to build good libraries.
>
>As for the teaching aspect, I think this must be always secondary to the
>aspect of C++ as a language designed to get things done. To me, it is OK
>that C++ is a behemoth and an encyclopaedia one never bother learning in
>its completeness: When one needs a feature.
It is hard for even an experienced stenographer to record all that is
said at a meeting. What I wrote was by no way inclusive. My intention
was to relay to the community of csc++ (and clc++m) that we had
effectively fired the start gun and declared open season on looking to
future developments of C++.
I think that it would be in everyone's interests to make this a brain-
storming session where people avoid overly negative responses to the
ideas of others and adopt an inclusion rather than an exclusion model.
I, for one, will be noting the ideas that come forward and culling them.
Eventually my National Body (BSI) via its C++ panel will be promoting
those ideas that we have thrashed out and consider worth putting our
efforts behind. Where-ever you are, it would be worth while getting
yourselves actively involved in your own NB's C++ standard committee.
Remember that the best way to get a feature is by being willing to o
some of the work necessary to get it.
Francis Glassborow
writes
>I spent several hours a couple of weeks ago tracking down an
>uninitialized pointer bug in some third-party code. A waste
>of time, but it probably would have been no easier (maybe
>even less easy) if the pointer value was 0 rather than garbage.
But this could be a QoI issue. It would be nice to have a compiler that
issued a warning for defining pointers without initialisation.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
LR
Radoslav Getov wrote:
> - did I mention 'typeof'?
Yes. What do you think that typeof should return?
LR.
Andrea Ferro
> Howard Gardner wrote:
> >
> > Markus Schaaf wrote:
> >
> > >>> For the love of humanity, define the value of a "default" constructed
builtin!
> > >>
> > >
> > > forgotten to initialize variables, why would zero be the _safe_
> > > choice?
> >
> > It doesn't make the program correct (unless 0 really was the right value),
it makes the resulting disaster easier to reproduce. That, in turn, makes the
error easier to find.
> >
> > I can't count the hours I've spent tracking down uninitialized variable bugs
(sometimes even my own) of one form or another.
>
> What compiler are you using?
> Have you turned on all of the warnings?
Agreed. This kind of "problems" should not be addressed in the language
specification itself. Many compilers do warn you. And I'd even be extremist to
the point that "any coding problem that can be discovered with a good
global-code lint should not be a priority in the language design". I'm not
meaning that strong typing itself is not a language concern. I mean that it is
unless it violates the 0 overhead rule.
I'd rather like
int f()
{
int i;
return i;
}
"ill formed, no diagnostic required" in the language definition, than having the
overhead of zeroing the local.
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info http://www.brainbench.com/transcript.jsp?pid=2522556
Gerhard Menzl
> > I'd prefer something like a Standard pragma (though historically
> > pragmas have been a pain) such as
> >
> > #pragram STDC++ always-initialize
>
> Only if it is REQUIRED to be impelemented is this useful. If it's
> optional, the feature suddenly becomes VERY VERY DANGEROUS. I
> suggest that if we're going to have compile standardized compile
> controls that they NOT be called PRAGMA.
Can you think of a name more suitable than:
#dogma always-initialize
? <g>
Gerhard Menzl
Francis Glassborow
>Fourth: While I understand how standards committees work, most programmers
>don't. The Standards process would do well to use the web actively in
>keeping the community well-informed as to its activities. If we're going to
>ask people to participate, they need to feel included, even if they can't
>afford to travel. That is the strength of the Internet -- bringing people
>together. Let's do it.
I cannot speak for other countries, but within the UK we try to run an
open system and have (through the auspices of ACCU) mechanisms for
including anyone with sufficient interest into electronic
consultation/contribution.
ACCU would happily promote such involvement elsewhere with other
National Bodies but that means that its members elsewhere must ask.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
Stephen Howe
Ron Natalie <r...@spamcop.net> wrote in message
news:3AF091B3...@spamcop.net...
>
>
> Dennis Yelle wrote:
> >
> > When you increment them, decrement them, or add (or subtract)
> > a size_t to (from) them, they do not change.
> >
> And the use of this nothingness is?
nothing :-)
Stephen Howe
Niklas Matthies
> In article <3AF03BF7...@acm.org>, James Dennett <jden...@acm.org>
> writes
> >I spent several hours a couple of weeks ago tracking down an
> >uninitialized pointer bug in some third-party code. A waste
> >of time, but it probably would have been no easier (maybe
> >even less easy) if the pointer value was 0 rather than garbage.
>
> But this could be a QoI issue. It would be nice to have a compiler that
> issued a warning for defining pointers without initialisation.
Preferably, a compiler would have a mode where all accesses (that are
not predictable at compile time) are checked at runtime whether they
access uninitialized values (a flag or special value would have to be
added by the compiler for each object). This would be the best help in
debugging such faults, and it's a feature that more than a few
higher-level languages already have built-in.
-- Niklas Matthies
Francis Glassborow
<ren...@home.com> writes
>I don't mean to piss anybody off with this email; I just find it frustrating
>to see technology advancing so fast and C++ just crawling.
There is a fine line between stability and stagnation. Serious users
want stability, there is nothing to prevent compiler vendors providing
extensions, but it would be a mistake to require them to do so
(particularly when they are still struggling to deliver a fully
conforming implementation of the current standard)
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
Niklas Matthies
[···]
> A single zero sized object would have a sizeof 0.
> An array of zero sized objects would have a sizeof 0.
>
> Or to put it another way:
>
> struct nothing {};
> assert ( 0 == sizeof(nothing) );
> nothing junk[10000];
> assert ( 0 == sizeof( junk));
>
> > and how would pointers to zero-sized objects behave?
>
> When you increment them, decrement them, or add (or subtract)
> a size_t to (from) them, they do not change.
Currently the Standard says: "Two pointers of the same type compare
equal if and only if they are both null, both point to the same object
or function, or both point one past the end of the same array". You mean
you would want to break this property?
And what would you want to use such objects for?
-- Niklas Matthies
Alasdai...@arm.com
>So, what do we want?
Here is my top 10.
1. First a challenge: write a class that behaves like 'int'.
After all, wrapping base types is something a class-based
language should be able to do without breaking sweat. Use your
class instead of int. Then look at all the ways your programs
breaks and fix C++ so that it doesn't. For example:
1(a):
struct { int m_n; } typedef Int;
Int n;
volatile Int nv;
void f() { n = nv; }
This is legal in C but not C++. That really ought to be
fixed, ideally by a general rule about volatile, rather than
by synthesis of extra copy constructors. Perhaps have
qualifier templates, as in the following function:
template<quals Q> char Q * strchr(char Q *, char);
Then the implicit copy constructor can be notionally defined
in terms of qualifier templates.
1(b):
The union constructor problem. It should be possible to say
struct Int { int m_n; Int(_n): m_n(_n) {} };
Int n = 2;
union { Int n; float n; };
The point here is that it should be possible to union a type
that "behaves like a base type", i.e. can be initialised but
has no (significant) default initialisation. One should not
have to do without initialisers (where optional) just to be
able to put types in a union. Unions are not deprecated yet,
are they?
2. It would be useful, for safety, to be able to say that a member
function must override (a non-pure function). For example:
struct A { virtual int f(char *); };
struct B: A { virtual int f(char *) _Pragma(STDC OVERRIDE); };
This protects (by generating a compiler warning or error)
against changes to the interface of A::f - introducing 'const',
say - which have the effect of losing the override in B.
3. friend class T
where T is a template argument. This appeared in drafts of
the Standard (e.g. April 95), with example code. It made it
into at least one production compiler which tracked the drafts.
Its prohibition by the Standard is mysterious and unhelpful.
4. Allow function-local classes to be used as template arguments,
as in
f()
{
struct S { int n; };
std::list<S> l;
}
5. Adopt the C99 'restrict' keyword, after defining its effects on
function linkage and overloading.
6. Make exceptions an officially optional language feature (perhaps
selected or deselected by a standard pragma). There is an argument
for doing this for RTTI, but not nearly as urgent. C++ is already
splitting into a language with exceptions and another language
without exceptions, and a lot of people want the latter. In many
situations exceptions do not justify the overhead required to
implement them.
7. Have a qualifier on pointer/reference function arguments that acts
like Ada's OUT keyword, to improve liveness analysis. I'm sure
there is some keyword or keyword combination that can be used.
(What about 'mutable'?) It would be useful if this keyword could
apply to (all) anonymous variadic parameters, as in scanf.
8. Standardise function qualifiers for pure and side-effect-free.
For pureness you could use 'true', meaning that it is truly a
function of its arguments. I believe gcc already uses 'const'
to mean pure (since they use 'pure' to mean 'side-effect-free'),
though that might conflict with 'const' on member functions.
If in doubt, standardise _Pragma.
9. When defining a class, especially a template, one sometimes wants
to say
IF IT IS MORE EFFICIENT TO REFER TO T THAN TO COPY IT THEN
typedef T const &ArgT;
ELSE
typedef T ArgT;
T operator +(ArgT a, ArgT b);
The 'IF' typedef can be done with a template hack, but I can't see
a way to do the test on which it depends, without language support.
In general the test is architecture-dependent.
10.As 'struct' and 'class' use the same namespace, it should not be
necessary to use the names consistently. The programmer should be
free to change a definition 'struct X' to 'class X', if that becomes
more natural, without invalidating uses of 'struct X' elsewhere.
--
Al Grant
Greg Brewer
> So, what do we want?
>
I want null defined like true and false so that
void Foo(int);
void Foo(char *);
void Bar(void)
{
Foo(0);
}
isn't ambiguous.
Greg Brewer
Dennis Yelle
[...]
> > > 4. Zero sized objects.
> > > This would require lengthof() because the standard idiom would break:
> > >
> > > #define lengthof(x) (sizeof(x)/sizeof((x)[0]))
> > >
> > > On the other hand, who puts zero sized objects in an array?
> >
> > I think it would break far more than ad-hoc size macros. Why do you need
> > zero sized objects.
>
> I can't see what this gains us either.
>
> > > 5. Require the "empty base class optimization".
> >
> > Why?
>
> How? As in, how would you word this requirement?
I would say that it follows directly from point 4. above.
It is one of the reasons for having point 4. above.
Another way to look at it is like this:
#include <stuff> // Defines struct stuff;
struct nothing {};
struct something {
stuff x;
nothing y;
};
// ...
assert( sizeof( nothing) == 0 );
assert( sizeof( something) == sizeof( stuff));
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
---
Dennis Yelle
>
> In article <3AF08832...@jps.net>, Dennis Yelle <denn...@jps.net>
> writes
> >A single zero sized object would have a sizeof 0.
> >An array of zero sized objects would have a sizeof 0.
>
> The problem is that, as the language is currently designed, objects have
> to have addresses. Currently we can just get away with making subobjects
> of different types share addresses.
>
> Francis Glassborow ACCU
> 64 Southfield Rd
> Oxford OX4 1PA +44(0)1865 246490
> All opinions are mine and do not represent those of any organisation
We already have one "magic address":
int* p = 0;
We could define another "magic address".
It could be 1 or 4 or 8 or 16 or whatever the
compiler writer decides works best on his platform.
The only breakage would be questionable code like this:
struct nothing {};
struct two_nothings {
nothing x;
nothing y;
} tn;
assert( &tn.x != &tn.y ); // this assert would fail.
nothing* p1 = new nothing;
nothing* p2 = new nothing;
assert( p1 != p2); // this assert would fail.
And, as you say above, we already have the case that an
empty object may have the same address as some other object.
If one needs distinct addresses one should not be using
empty objects to get them.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
---
Hans Aberg
>Francis Glassborow wrote:
...
>> make rules more general and uniform
>> improve support for low level embedded programming (note BS explicitly
>> does not want to see C++ become an exclusively high level language)
...
>... introduce a generic mechanism to
>indicate a class' or an object's location in an implementation specific storage
>type and/or location.
This is also needed in the programming that goes "the other way", dynamic
and distributed programming.
Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <remove...@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
Harvey Taylor
<denn...@jps.net> Dennis Yelle wrote:
> James Dennett wrote:
> [...]
>>>> 4. Zero sized objects.
>>>> This would require lengthof() because the standard idiom would break:
>>>>
>>>> #define lengthof(x) (sizeof(x)/sizeof((x)[0]))
>>>>
>>>> On the other hand, who puts zero sized objects in an array?
>>>
>>> I think it would break far more than ad-hoc size macros. Why do you need
>>> zero sized objects.
>>
>> I can't see what this gains us either.
>>
>>>> 5. Require the "empty base class optimization".
>>>
>>> Why?
>>
>> How? As in, how would you word this requirement?
>
> I would say that it follows directly from point 4. above.
> It is one of the reasons for having point 4. above.
> Another way to look at it is like this:
>
> #include <stuff> // Defines struct stuff;
>
> struct nothing {};
>
> struct something {
> stuff x;
> nothing y;
> };
>
> // ...
> assert( sizeof( nothing) == 0 );
> assert( sizeof( something) == sizeof( stuff));
>
Hmmm. And the reason I would want to do this is...?
In your code, does 'y' have an address?
ie. is &y valid &/ meaningful?
I am reminded of the 'run past the end of a struct metaphor',
but I doubt that is what you have in mind somehow.
<still curious>
-het
--
"Sacred cows make the best hamburger." -Abby Hoffman
Harvey Taylor http://www.autobahn.mb.ca/~het/
Greg Brewer
That might be useful. One thing Bjarne suggested is that C++ compilers
> in transition from today to the future should be required to implement
> new features in a specified order. IOWs if it supports feature X it is
> required to support all features prior to X.
I like that idea. One problem I would like to see addressed though is
forward compatability. New language features often break existing code.
Wouldn't it be nice if there was a pragma that you could code at the start
of your source modules that declare the version -- either of the compiler or
of the standard. Examples might be
#pragma version cppstd 1998 cstnd 2000 // c++ standard and c standard should
be required
#pragma version msc 2.42 // Microsoft specific information ignored by all
others
#pragma version bc 5.01 // Borland specific information ignored by all
others
The compiler would scan the version info and do something appropriate. One
would expect that the programmer would code the version of the current
compiler. Then 3 years from now when the compiler has been upgraded to the
latest and greatest, the compiler can either issue an error if it might not
be able to handle code for that version or adapt itself (ie turn off/on
switches necessary to support that version). In cases where the version is
unknown (which might happen if you were recompiling for another platform,
etc) then it should issue a warning and proceed.
That is just a spur of the moment idea. Even if this idea won't fly I would
like to see the standards committee take a look at forward compatability so
that code I write today will have a chance of compiling with a 2010 c++
compiler.
Greg Brewer
Robert FISHER
> Robert FISHER wrote:
> [...]
>
>> Am I the only one that hates the standard library? The blatant, violent
>> abuse of operator overloading by the I/O streams has kept me from EVER
>> using them. I respect and admire the STL classes, but I hate using them
>> for reasons I haven't quite completely identified yet. Sure, it's too
>> late to make any radical changes, but I'd sure like to see an
>> "alternative standard library".
>
>
> What are you looking for?
> That is, how will you recognize it when you see it?
> Is it just that the STL is too large?
>
Like I said, I haven't completely identified why I don't like the STL. I
guess I was hoping someone else who with similar feelings might have
something to say that would help be identify my own problems with it.
Maybe it's just that, even after reading much about the STL and groking
at least the basics (which I think I have), I still don't find the
interface very intuitable. I just have to resolve to force myself to use
all the standard library more, so I can either learn to love it or form
better arguments against it. =)
In any case, I'll repeat a couple of my most wanted features for C++0x: =)
* A "finally" construct for exceptions, 'cause "multiparadigm" means I
shouldn't ALWAYS have to use "resource acquisition is initialization".
* A simple, efficient, safe way to tell whether a pointer was allocated
with new and can be safely deleted.
--
Robert FISHER
rfi...@my-deja.com
Johan Ericsson
> constructor and assignment operator for classes with destructors and
> making base classes with virtual member functions have a virtual
> destructor by default. These will be very welcome changes.
I heard Mr. Stroustrup say this in a recent speech, and I am a little bit
confused. It seems like this could break a good amount of good code.
Currently, a public base class is practically required to have a virtual
destructor (even if empty). These classes with empty destructors do have
proper compiler generated copy-ctors and assignment operators. Are we going
to start distinguishing between empty and non-empty destructors?
Granted the second suggestion (requiring virtual destructors for classes
with virtual functions) would remove the need for all of these empty
destructors.
Practically the only destructors needed in my current project are empty
virtual destructors. But I use the default compiler generated copy
constructor in these base classes.
If these suggestions were implemented, then I would need to go through and
remove all virtual destructors from all my base classes... except that if I
needed to compile with a "older" compiler, then I would need to re-add all
the virtual destructors or risk undefined behavior. I guess I would start
seeing a bunch of:
#ifdef OLDER_COMPILER
virtual ~MyClass() {}
#endif
Anyways, I think this is a great suggestion, but perhaps it needs to
distinguish between empty destructors and destructors with statements. But I
think this distinction may obscure its implementation.
Any thoughts?
Johan
Dennis Yelle
>
> On Wed, 2 May 2001 22:45:10 GMT, Dennis Yelle <denn...@jps.net> wrote:
> [···]
> > A single zero sized object would have a sizeof 0.
> > An array of zero sized objects would have a sizeof 0.
> >
> > Or to put it another way:
> >
> > struct nothing {};
> > assert ( 0 == sizeof(nothing) );
> > nothing junk[10000];
> > assert ( 0 == sizeof( junk));
> >
> > > and how would pointers to zero-sized objects behave?
> >
> > When you increment them, decrement them, or add (or subtract)
> > a size_t to (from) them, they do not change.
>
> Currently the Standard says: "Two pointers of the same type compare
> equal if and only if they are both null, both point to the same object
> or function, or both point one past the end of the same array". You mean
> you would want to break this property?
It is already broken.
Decide what this program should print based on the quote above,
and then try it:
=======================================
#include <iostream>
using namespace std;
int main()
{
struct junk {
int x[2];
int y[2];
} stuff;
if ( stuff.x+2 == stuff.y)
cout << "same\n";
else
cout << "different\n";
return 0;
}
=======================================
Both of my compilers print "same".
I don't even see a way that any sane usable compiler could
produce a program that would print "different".
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
---
Hans Aberg
Alasdai...@arm.com wrote:
>6. Make exceptions an officially optional language feature (perhaps
> selected or deselected by a standard pragma). There is an argument
> for doing this for RTTI, but not nearly as urgent. C++ is already
> splitting into a language with exceptions and another language
> without exceptions, and a lot of people want the latter. In many
> situations exceptions do not justify the overhead required to
> implement them.
Exceptions are very pleasing, because a program that always throws
exceptions cannot break, except for non-termination.
Therefore, I expect that the exceptions feature will grow stronger as the
computers become more powerful, and one learns better how to implement it
in the language.
This will also be true for programs that now require small code.
So rather than looking for ways to merely exclude exceptions, I think one
should look for the prudent inclusion of exceptions.
Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <remove...@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
Harvey Taylor
<SPAMstephe...@tnsofres.com> Stephen Howe wrote:
> Ron Natalie <r...@spamcop.net> wrote in message
> news:3AF091B3...@spamcop.net..
>>>
>>> When you increment them, decrement them, or add (or subtract)
>>> a size_t to (from) them, they do not change.
>>>
>> And the use of this nothingness is?
>
> nothing :-)
>
I don't know what Dennis has in mind [please do elucidate, Dennis]
but somehow I can imagine some first millenium arithmetician
saying the same of zero.
<curious>
-het
--
"Sacred cows make the best hamburger." -Abby Hoffman
Harvey Taylor mailto:h...@spam.autobahn.mb.ca http://www.autobahn.mb.ca/~het/
Ron Natalie
Gerhard Menzl wrote:
>
> > controls that they NOT be called PRAGMA.
>
> Can you think of a name more suitable than:
>
> #dogma always-initialize
>
I love it.
(How about coming up with some use for #karma).
Ross Smith
>
> Gerhard Menzl wrote:
> >
> > > controls that they NOT be called PRAGMA.
> >
> > Can you think of a name more suitable than:
> >
> > #dogma always-initialize
> >
>
> I love it.
>
> (How about coming up with some use for #karma).
That's easy: it determines what happens to an object's storage after
it's been destroyed. "#karma bad" means that released memory should be
zeroed out, which will be useful in secure applications.
--
Ross Smith <ros...@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
"Hungarian notation is the tactical nuclear weapon of
source code obfuscation techniques." -- Roedy Green
James Dennett
[snip]
> 10.As 'struct' and 'class' use the same namespace, it should not be
> necessary to use the names consistently. The programmer should be
> free to change a definition 'struct X' to 'class X', if that becomes
> more natural, without invalidating uses of 'struct X' elsewhere.
Luckily number 10 made it into the 1998 Standard, though not
into MSVC++6.
It's quite legal to write:
struct X;
X* px;
class X {
};
even across translation units. I've heard rumours that VC++
encodes struct/class different in mangled names, and so gets
this wrong, but the Standard says that the only differences
between class and struct are default access to members and
default access for inheritance.
-- James Dennett
Carl Daniel
>
My $0.02 worth:
1. typeof
e.g.
std::map<std::string,std::vector<int> > MyMap;
for (typeof(MyMap)::iterator it...)
... many other uses
2. template typedef
e.g.
template <class ValueType> std::map<std::string,ValueType> PropsMap;
With classes like Andrei's smart pointer (from loki) kicking about with so
many template parameters, template typedef would be of great help (I've
heard rumors that template typdef is nearly a shoe-in - true?)
3. finally
Despite my love of the RAII idiom, I too would enjoy having finally. As
someone else pointed out, C++ is and always has been a multi-paradigm
language. Forcing the use of RAII seems anathematic to the principles of
C++.
4. std::hash_map, hash_set, slist, etc.
Duh.
5. Reflection/introspection
IMO, this must be optional - perhaps requested by a new class declaration
decoration (along the lines of MSVC's __declspec() but not that ugly).
At the least, make type_info a bit beefier - the current type_info is pretty
useless except for determining if two classes are in fact the same.
6. Language/library support for abstract factory/virtual constructor.
This pretty much requires reflection, I believe - but the problem is soooooo
common that a standard solution would sure be nice.
7. Standard-sized int's
8. A stream I/O facility which guarantees portability of serialized objects
across platforms (probably requires reflection and standard-sized types).
9. Mssr. Glassborow's suggestion that there be a standard way to inform the
compiler of the language version you're intending to use.
-cd
James Kuyper Jr.
>
> Niklas Matthies wrote:
...
> > Currently the Standard says: "Two pointers of the same type compare
> > equal if and only if they are both null, both point to the same object
> > or function, or both point one past the end of the same array". You mean
> > you would want to break this property?
>
> It is already broken.
> Decide what this program should print based on the quote above,
> and then try it:
> =======================================
> #include <iostream>
> using namespace std;
>
> int main()
> {
> struct junk {
> int x[2];
> int y[2];
> } stuff;
> if ( stuff.x+2 == stuff.y)
> cout << "same\n";
> else
> cout << "different\n";
> return 0;
> }
> =======================================
>
> Both of my compilers print "same".
>
> I don't even see a way that any sane usable compiler could
> produce a program that would print "different".
How about one in which int has a size and alignement of 2 bytes, and
structure members are aligned on multiples of 16 bytes? The platform
would have to be somewhat peculiar, but I don't think exceedingly so, in
order to make that a reasonable implementation.
In any event, how does this constitute a break in the standard? On the
more conventional platforms you were imagining, stuff.x+2 and stuff.y
arguably (and there's been a GREAT deal of argument about it) point to
the same object, namely stuff.y. stuff.x+2 is based upon x, where I'm
using "based" in essentially the same sense as defined by 6.7.3.1 for
restrict-qualified pointers. stuff.x+2 is not based upon y. However, the
standard only refers to whether they point at the same object; it says
nothing about them being based on the same object.
What a pointer points at is defined by what happens when you dereference
the pointer. If an implementation allows you to dereference stuff.x+2
(as undefined behavior, of course), and doing so happens to be exactly
equivalent to dereferencing stuff.y, then I think that implementation
should let them compare equal, and would remain conforming if it did.
Markus Schaaf
> I don't know what Dennis has in mind [please do elucidate, Dennis]
I feel a bit of sympathy for Dennis' idea of zero-sized
objects, so I'll try.
Imagine you have a class that does some magic with c'tor
and d'tor (e.g. locking a file or owning a mutex), but
hasn't any data members. In your code you will have objects
of that type here and there. So the compiler must allocate
storage for these objects, for the standard's sake.
If you never use the address of such an object, and it has
internal linkage, the compiler could make it zero-sized,
i.e. drop it except for the side-effects. Why to render
this difficult for no reason?
It seems to me, that this may be a matter of wording in
the standard, rather than really changing the programming
language. If this is an issue at all. I don't know exactly.
Michael Lee Finney
kuy...@wizard.net says...
> > We already have "explict" to indicate that a
> > conversion can only happen explicitly. How about
> > allowing "implicit" so that a conversion is treated at
> > the same level as other implicit conversions?
> > Having the built-in conversions on a level we can't
> > reach can be very awkward sometimes. It should be
> > possible for a user defined conversion to be treated
> > identically to the language defined conversions.
> User-defined conversion functions and converting constructors are
> already treated almost the same as the built-in conversions. The main
> difference is that an implicit conversion sequence cannot contain more
> than one user-defined conversion. Is that the restriction you're asking
> to have removed for functions declared "implicit"?
The point here is directed towards what another poster
stated more explicitly -- the ability to define a
class which is indistinguishable from a "primitive"
object. One thing needed is "implicit" conversion
operators because that affects type conversion rules.
Another thing needed is the ability to define && and
|| as proper short-circuited operators. One way to do
that is to define the operands as "lazy" so that they
are conceptually passed as a thunk and only evaluated
when referenced. If inlined, the thunk could be
optimized away, resulting in short circuit operators.
Also, the ability to overload the ?: operator is
desirable. That could be done by defining two binary
operators, operator:() which takes two parameters
returning a structure containing two lazily evaluated
parameters, and then operator ? which takes a boolean
expression and the above structure and returns one
element of the structure. Those operators would, of
course, have to have just the right precedence to work
together without messing up anything else, but that
shouldn't be a problem. Again, lazy evaluation shows
up here again, in this case as elements of a
structure. And, again, inline optimization would
normally eliminate the structure and thunks involved
to give the same result as the built in operator.
I suggest that immediately preceding the name of a
element, in a parameter list or structure with an "@"
symbol should indicate that the element is lazily
evaluated, and conceptually, when assignment to such
an element occurs, a "thunk" is created which will
evaluate it in the proper context. There might need to
be rules to ensure that such an element is not passed
out of the execution stack context (so that a stack
can still be used to invoke functions). However, if an
implementation used an activation record allocated
from the heap (potentially just as efficient as stack
allocation) and some form of garbage collection is in
used, then such a constraint could be relaxed.
But then, you could declare functions like...
inline Boolean operator&&(
Boolean lvalue,
Boolean @rvalue)
{
if (lvalue)
if (rvalue)
return true;
else
return false;
else
return false;
}
which would provide the same short circuited result
for user defined classes as for the built in types.
And with inlining the thunk overhead should be
optimized away so that exactly the same code can be
generated.
Another way to handle ?: is to explicitly recognize it
as an overloadable operator (much cleaner than trying
to break it into two peaces) which accepts three
parameters. Then you could define...
inline Integer operator?:(
Boolean choice,
Integer @trueValue,
Integer @falseValue)
{
if (choice)
return trueValue;
else
return falseValue;
}
This approach also has the benefit that lazy
evaluation only needs to be allowed in function
parameters, and so the calling stack problem doesn't
arise.
So, three features
implicit constructors
lazy evaluation for function parameters
overloadable operator?:()
gets us much closer to the ability to be able to
define a user class with exactly the same behaviour as
one of the built in types which I consider to be
extremely important.
Michael Lee Finney
operator being undefined for signed operands. It
should result in a logical right shift for unsigned
operands and in an arithmetic right right for signed
operands. Since it is currently undefined, but the way
that it is normally implemented, this only helps to
pin down the definition of the operator.
Michael Lee Finney
Consider allowing '$' as part of an identifier
(already the case by almost all compilers as a
compiler option), but restrict it to only being used
for private or protected members of a class or struct.
This would help eliminate the very message "_" or
"my_" prefix frequently used to separate the
namespace. It also has the advantage that the compiler
can enforce the private/protected restriction and that
there is no potential conflict with either existing
code.
Michael Lee Finney
"stable" in the same way it can be qualified as
"const". The meaning of "stable" would be that the
function has no side effects other than optional side
effects to mutable data elements, and that two calls
to the function with the same parameter values will
result in exactly the same result.
This could be very useful in assisting the compiler to
eliminate unnecessary function calls by allowing it to
cache the result when it knows that the function call
might be needed again. This can already be done if the
function can be inlined and the optimize can see both
function invocations, but without extensive analysis,
the compiler cannot do the same thing for non-inlined
functions.
Obviously, the use of the keyword would be optional,
but if a pointer to a function is "stable" then any
function assigned to the pointer would also have to be
stable.
Michael Lee Finney
be to allow the case where a label immediately
precedes a "while", "do", "for" or "switch" statement
to be referenced by the continue and break statements.
For example:
label: while (exp)
{
// some code
continue label;
// some code
break label;
}
This would allow multi-level break and continue
without having to use the goto statement. It doesn't
break existing code because the label is already
legal, and the continue and break statement do not
currently allow anything before the semicolon. So
allowing an optional label, which must have been
immediately placed before the start of the control
structure, would allow break and continue to handle
the multi-level situations.
It is better than using the goto statement because
there you would need two labels, one for the continue
and one for the break, and the trailing label is messy
and not very readable. It also explicitly replaces the
most common use of the goto statement so that the goto
statement can be used even less often than it is now.
Michael Lee Finney
virtual function. It would be nice to be able to
define a class as "abstract" so that the class cannot
be instantiated. The keyword "abstract" could be used
on the class declaration for that purpose. It could
also be used to (optionally) replace "=0" for a
abstract member function. There is no particular
reason why you could not declare an abstract member
function which is not virtual. You are merely
declaring that it must be implemented by a non-
abstract subclass, but it is would not be referenced
from a pointer to the base class. So, I could write
something like...
class abc
{
void aFunction() abstract;
virtual void bFunction() abstract;
};
Then, given "abc * p", I could use p->bFunction()
because it is virtual, but I could not use p->
aFunction() because it is not virtual. In either case,
a class...
class def : abc
{...};
would have to implement both aFunction() and bFunction
() for it to be non-abstract. Also...
abstract class abc
{...};
could not be instantiated, but...
class def : abc
{...};
could be instantiated, given no other constraints.
Christopher Eltschka
>
> Radoslav Getov wrote:
>
> > - did I mention 'typeof'?
>
> Yes. What do you think that typeof should return?
Nothing, because it's not a function.
What does int return?
If you think "higher order", typeof returns a type.
Niklas Matthies
> "Francis Glassborow" <francis.g...@ntlworld.com> wrote in message >
> That might be useful. One thing Bjarne suggested is that C++ compilers
> > in transition from today to the future should be required to implement
> > new features in a specified order. IOWs if it supports feature X it is
> > required to support all features prior to X.
>
> I like that idea. One problem I would like to see addressed though is
> forward compatability. New language features often break existing code.
> Wouldn't it be nice if there was a pragma that you could code at the start
> of your source modules that declare the version -- either of the compiler or
> of the standard. Examples might be
> #pragma version cppstd 1998 cstnd 2000 // c++ standard and c standard should
> be required
> #pragma version msc 2.42 // Microsoft specific information ignored by all
> others
> #pragma version bc 5.01 // Borland specific information ignored by all
> others
You can already do this, like
#if __cplusplus == 199711L
// compiling under C++98
#elif __cplusplus > 199711L
// compiling under C++ newer than C++98
#else
// compiling under pre-standard C++
#endif
And compilers usually have their own pre-defined version macros.
What might be more useful is to introduce feature-specific macros, e.g.
__STD__RTTI_98_AVAILABLE, __STD__AUTO_INITIALIZE_OBJECTS.
> That is just a spur of the moment idea. Even if this idea won't fly I
> would like to see the standards committee take a look at forward
> compatability so that code I write today will have a chance of
> compiling with a 2010 c++ compiler.
Usually you use flags to tell the compiler which version of C++ with
which extensions you want your code to be compiled with, and check using
the preprocessor like above that you actually got the version your code
is comfortable with.
-- Niklas Matthies
Niklas Matthies
> Niklas Matthies wrote:
[···]
Even though stuff.x+2 points one past the end of the array stuff.x, it
may very well at the same time also point to the object denoted by
stuff.y[0]. Since "one past the end of the array" doesn't refer to an
object that is part of the array, I don't see that anything is broken.
both stuff.x+2 and stuff.y happen point to the same one object, and
therefore compare equal (assuming there's no padding between x and y).
-- Niklas Matthies
Michael Lee Finney
"isochar" where unichar is unsigned and at least 16
bits and where isochar may be signed or unsigned, but
must be able to represent 31 bits of positive value.
In practice, a unichar would normally be exactly 16
bits and an isochar would be either signed or unsigned
and 32 bits.
This is a lot better than having to figure out which
primitive type is available and also allows us to
explicitly overload on those types (and, yes, I have
programs where I simultaneously use char, unichar and
isochar in the same translation unit and need to
overload on those types).
Perhaps it isn't (yet) appropriate to adopt Unicode or
ISO extension as the native character set, but surely
we should require our language to support these as
native types!
Dennis Yelle
>
> In article <3af13a91$0$15026$ed9e...@reading.news.pipex.net>,
> <SPAMstephe...@tnsofres.com> Stephen Howe wrote:
> > Ron Natalie <r...@spamcop.net> wrote in message
> > news:3AF091B3...@spamcop.net..
> >> Dennis Yelle wrote:
> >>>
> >>> When you increment them, decrement them, or add (or subtract)
> >>> a size_t to (from) them, they do not change.
> >>>
> >> And the use of this nothingness is?
> >
> > nothing :-)
> >
>
> I don't know what Dennis has in mind [please do elucidate, Dennis]
> but somehow I can imagine some first millenium arithmetician
> saying the same of zero.
> <curious>
Well, I thought the uses of empty structs were well known because of
the STL, where they are used a lot. But I agree they are a bit
mysterious.
Maybe this example will help show when the current situation
is a problem:
=================================
#include <iostream>
using namespace std;
struct Base1 {
int stuff;
};
struct Base2 {
int foo() { return 3; }
};
struct Both : Base1, Base2 {};
int main()
{
cout << "Base1 size: " << sizeof(Base1) << '\n';
cout << "Base2 size: " << sizeof(Base2) << '\n';
cout << "Both size: " << sizeof(Both ) << '\n';
return 0;
}
=================================
For the program above, one of my compilers gives this result:
Base1 size: 4
Base2 size: 1
Both size: 8
And my other compiler gives this result:
Base1 size: 4
Base2 size: 1
Both size: 4
Now, it may be that they both conform to the standard
for this particular program, but to me, they are both wrong.
In the first case, using a second empty base class, something
which should logically be free, costs me 4 bytes per object.
In the second, we see that seemingly a total of 5 bytes
fits in a struct 4 bytes long.
I guess I just don't understand why it was felt that
an empty struct should have a size of 1, and then
invent some special cases to make that 1 byte
go away some times. Just doing the natural thing of
allowing it to be 0 bytes long would, it seems to me,
lead to all of the right results.
I think part of the problem was that when this decision
was originally made, we did not have enough experience
with empty classes and structs to see that they should
actually have a size of zero.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
---
Michael Lee Finney
the syntax:
do <statement> while (<exp>;
with:
do <statement> while (<exp>) statement
This is backward compatible because ; is a valid
statement. It also allows me to write:
do
{
// some code
}
while (exp)
{
// some more code
}
and explicitly solves the n and a half loop problem
which occurs in many algorithms. This neither
introduces new keywords nor does it break existing
code. But is would be welcome extension which makes
structured code for some problems easier to write.
Joseph Gottman
constructor, or assignment operator, then automatically use the one that the
compiler would have generated for the class if I hadn't declared it. This
would be useful if the only reason I declared the function was to make it
private or protected. One possible way of doing this without adding a new
keyword is by reusing the keyword 'using';
class Foo {
protected:
using Foo(const Foo &); // Autogenerate protected copy constructor
using Foo &operator=(const Foo &); // Autogenerate protected
assignment operatror
};
Joe Gottman
John Crickett
"James Dennett" <jden...@acm.org> wrote in message
news:3AF03BF7...@acm.org...
> Howard Gardner wrote:
> > I can't count the hours I've spent tracking down uninitialized
> > variable bugs (sometimes even my own) of one form or another.
>
> I spent several hours a couple of weeks ago tracking down an
> uninitialized pointer bug in some third-party code. A waste
> of time, but it probably would have been no easier (maybe
> even less easy) if the pointer value was 0 rather than garbage.
Surely then the issue is to "persude" compiler writers to issues some decent
warnings?
Or just buy Lint, it would have pointed this problem out immediately.
> And many of us don't want to pay for a feature (possibly more
> easily reproducible bugs) that we don't use at the expense of
> code which runs more slowly.
I'd hate to pay for this feature that's a fix for poor diagnostics, or the
lack of a tool like lint to make up for them.
Regards, John
Francis Glassborow
<live...@hotmail.com> writes
>Currently, a public base class is practically required to have a virtual
>destructor (even if empty). These classes with empty destructors do have
>proper compiler generated copy-ctors and assignment operators. Are we going
>to start distinguishing between empty and non-empty destructors?
But he is also proposing that virtual default dtors be provided for any
class with a virtual member so it would no longer be necessary to write
and empty dtor.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Jens Kilian
> I want to eliminate the problem of the right shift
> operator being undefined for signed operands.
I'd like bit-rotation, population count, highest-bit-set and lowest-bit-set
operators (or standard functions that could be implemented efficiently
on machines with the appropriate instructions).
Also, standard library functions for float-to-ASCII and ASCII-to-float
conversions which guarantee accuracy, similar to the ones found in most Lisps.
(Efficient implementations for these are freely available.)
Some kind of lambda feature would be nice, but people tend to disagree about
how much power is needed and how it should be implemented.
--
mailto:j...@acm.org phone:+49-7031-464-7698 (TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
Anthony Williams
news:MPG.155bcfc9b...@news.lynchburg.net...
> In article <3AF14C18...@wizard.net>,
> kuy...@wizard.net says...
> > > We already have "explict" to indicate that a
> > > conversion can only happen explicitly. How about
> > > allowing "implicit" so that a conversion is treated at
> > > the same level as other implicit conversions?
>
> > > Having the built-in conversions on a level we can't
> > > reach can be very awkward sometimes. It should be
> > > possible for a user defined conversion to be treated
> > > identically to the language defined conversions.
>
> > User-defined conversion functions and converting constructors are
> > already treated almost the same as the built-in conversions. The main
> > difference is that an implicit conversion sequence cannot contain more
> > than one user-defined conversion. Is that the restriction you're asking
> > to have removed for functions declared "implicit"?
>
> The point here is directed towards what another poster
> stated more explicitly -- the ability to define a
> class which is indistinguishable from a "primitive"
> object. One thing needed is "implicit" conversion
> operators because that affects type conversion rules.
Agreed - allow chaining of "implicit" conversions.
> Another thing needed is the ability to define && and
> || as proper short-circuited operators.
Agreed
> One way to do
> that is to define the operands as "lazy" so that they
> are conceptually passed as a thunk and only evaluated
> when referenced. If inlined, the thunk could be
> optimized away, resulting in short circuit operators.
I like the idea. This is effectively just a lambda function, created
on-the-fly from an arbitrary expression
bool func(bool lambda x) // x is a lambda function returning bool
{
if(someCondition)
return x; // x is only evaluated here
else return false;
}
func(a+b+c); // invocation of func()
the expression (a+b+c) is converted to a lambda function (ie not evaluated).
If the result can be converted to bool, then it is a match for the
declaration of func above. Any expression can be converted to a lambda
function, by effectively defining a functor with a reference data member for
each object named in the expression, and operator() that replicates the
original expression using these members, e.g. (for a+b+c)
struct lambda1
{
typeof(a)& a_;
typeof(b)& b_;
typeof(c)& c_;
typeof(a+b+c) operator() { return a_+b_+c_;}
};
Also, you can declare a lambda function (e.g. for use as a functor)
std::vector<std::string> vs;
std::for_each(vs.begin(),vs.end(),
void lambda(const std::string&b)
{
std::cout<<b<<'\n';
}
);
> Also, the ability to overload the ?: operator is
> desirable.
Agreed, but I don't like the suggestion of splitting it into two.
[SNIP]
> Another way to handle ?: is to explicitly recognize it
> as an overloadable operator (much cleaner than trying
> to break it into two peaces) which accepts three
> parameters. Then you could define...
>
> inline Integer operator?:(
> Boolean choice,
> Integer @trueValue,
> Integer @falseValue)
> {
> if (choice)
> return trueValue;
> else
> return falseValue;
> }
>
> This approach also has the benefit that lazy
> evaluation only needs to be allowed in function
> parameters, and so the calling stack problem doesn't
> arise.
I think the first parameter should always be a UDT, but the others need not
be. The second and third parameters must also always be of the same type,
except that one or both may be lambda functions returning the common type.
operator?: may be defined as a class member, thus omitting the first
parameter.
e.g.
struct MyClass
{
std::string operator?:(std::string lhs,std::string lambda rhs);
}
> So, three features
>
> implicit constructors
> lazy evaluation for function parameters
> overloadable operator?:()
>
> gets us much closer to the ability to be able to
> define a user class with exactly the same behaviour as
> one of the built in types which I consider to be
> extremely important.
My list is (in no particular order):
* explicitly "implicit" conversions
* "explicit" conversion operators - to permit int a; a=int(myClassObject);,
but not int a; a=myClassObject;
* lambda functions
* permit operator?: overloading
* typeof
* template typedef
* require local classes to have linkage, so they can be used as template
arguments
* local functions
* enable proxy types (a natural extension to smart pointers) => permit
overloading of "operator."
* enable non-const references to temporaries
Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer
Andrew Jenner
<michael...@acm.org> wrote:
> label: while (exp)
> {
> // some code
> continue label;
> // some code
> break label;
> }
I like this idea. Here is another way it could be done, with numeric
arguments to break and continue:
while(x) {
...
while(y) {
...
if (z)
break 2; // breaks out of both loops, ends up at ***
}
}
// ***
and
while(x) {
// ***
...
while(y) {
...
if (z)
continue 2; // breaks out of inner loop, ends up at ***
}
}
Advantage: named break statements are effectively gotos anyway - this
method is more structured.
Disadvantage: If you add another nesting of loop inbetween the
outermost and innermost loop the meaning of the code changes in this
method but not in Michael's. Of course, making such a radical change
would usually require a lot of other changes as well.
Another way of writing these could be "break break;" or "break
continue;".
All three of these syntaxes can coexist.
Andrew
Jens Kilian
> Also, you can declare a lambda function (e.g. for use as a functor)
>
> std::vector<std::string> vs;
> std::for_each(vs.begin(),vs.end(),
> void lambda(const std::string&b)
> {
> std::cout<<b<<'\n';
> }
> );
I would prefer a syntax like the following, which parallels templates and
new-style casts, and which also may be easier to parse:
std::vector<std::string> vs;
std::for_each(vs.begin(),vs.end(),
lambda<void>(const std::string&b)
{
std::cout<<b<<'\n';
}
);
--
mailto:j...@acm.org phone:+49-7031-464-7698 (TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
---
Pete Becker
>
> If you never use the address of such an object, and it has
> internal linkage, the compiler could make it zero-sized,
> i.e. drop it except for the side-effects. Why to render
> this difficult for no reason?
It's not at all difficult. If you don't every do anything that depends
on the size of the object then the compiler is free to give it any size
that works well, including zero.
>
> It seems to me, that this may be a matter of wording in
> the standard, rather than really changing the programming
> language. If this is an issue at all. I don't know exactly.
>
This is known as the "as if" rule: the compiler must generate code that
works as if it had followed the rules exactly. If a change from the
details of the rules won't be detected by the program, then that change
is okay.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Anthony Williams
news:MPG.155bd570f...@news.lynchburg.net...
> Also, how about allowing a function to qualified by
> "stable" in the same way it can be qualified as
> "const". The meaning of "stable" would be that the
> function has no side effects other than optional side
> effects to mutable data elements, and that two calls
> to the function with the same parameter values will
> result in exactly the same result.
>
> This could be very useful in assisting the compiler to
> eliminate unnecessary function calls by allowing it to
> cache the result when it knows that the function call
> might be needed again. This can already be done if the
> function can be inlined and the optimize can see both
> function invocations, but without extensive analysis,
> the compiler cannot do the same thing for non-inlined
> functions.
>
> Obviously, the use of the keyword would be optional,
> but if a pointer to a function is "stable" then any
> function assigned to the pointer would also have to be
> stable.
>
Obviously, a stable function would have to be verified as such by the
compiler when defined, meaning that it could only call stable functions
itself.
Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer
---
Marcin 'Qrczak' Kowalczyk
> Exceptions are very pleasing, because a program that always throws
> exceptions cannot break, except for non-termination.
I'm not sure what do you mean by this, but
http://cseng.awl.com/book/related/0,3833,020163371X+11,00.html
shows that exceptions are not as safe as they might seem.
--
__("< Marcin Kowalczyk * qrc...@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
Greg Comeau
Scott Robert Ladd <sc...@coyotegulch.com> wrote:
>Fourth: While I understand how standards committees work, most programmers
>don't. The Standards process would do well to use the web actively in
>keeping the community well-informed as to its activities. If we're going to
>ask people to participate, they need to feel included, even if they can't
>afford to travel. That is the strength of the Internet -- bringing people
>together. Let's do it.
I agree, and that is exactly why Francis posted his message here! :)
Anyway, there was some discussion and action at the Copenhagen meeting
(which ended about an hour ago) about publicizing more. As well,
there are less official aspects, though certainly to be considered
tentacles of the committee, such as the links from my web site,
http://www.comeaucomputing.com/iso, the dkuug.dk site, and probably
others. What do you feel is incomplete on those sites?
--
Greg Comeau Comeau C/C++ 4.2.45.2
ONLINE COMPILER ==> http://www.comeaucomputing.com/tryitout
NEW: Try out libcomo! NEW: Try out our C99 mode!
com...@comeaucomputing.com http://www.comeaucomputing.com
Gerhard Menzl
> > Can you think of a name more suitable than:
> >
> > #dogma always-initialize
> >
>
> I love it.
It's been on my mind for years, but I never saw a practical need for it.
Now, eventually!
What about a standardized way of ignoring warnings using
#phlegma ...
?
Gerhard Menzl
Marcin 'Qrczak' Kowalczyk
> I also want two new primtive types: "unichar" and
> "isochar" where unichar is unsigned and at least 16
> bits and where isochar may be signed or unsigned, but
> must be able to represent 31 bits of positive value.
> In practice, a unichar would normally be exactly 16
> bits and an isochar would be either signed or unsigned
> and 32 bits.
In Unicode 3.1 characters go up to U+10FFFF.
16 bits are not enough.
--
__("< Marcin Kowalczyk * qrc...@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
---
LR
>
> LR wrote:
> >
> > Radoslav Getov wrote:
> >
> > > - did I mention 'typeof'?
> >
> > Yes. What do you think that typeof should return?
>
> Nothing, because it's not a function.
> What does int return?
>
> If you think "higher order", typeof returns a type.
Ok, your point is well made, and well taken. Please allow me to ask a
slightly different question. Maybe the answer is obvious.
Consider this fragment:
class Base {};
class D1 : public Base {};
class D2 : public Base {};
Base *pb = new Base;
Base *pd = somecondition ? new D1 : new D2;
Then what should typeof(pb) and typeof(pd), return? Probably they should
all return Base*. But isn't it possible that we might want typeof(pd)
to give us D1*. Could we have syntax that might be like *typeof(pd)
that will yield this info?
And how can typeof be used? Anywhere that I can specify a type?
Assuming that I want to clone what pd points to, maybe something like:
typeof(pd) px = new *typeof(pd);
Maybe I should ask what typeof will or should do? Or what people see as
it's intended use.
LR.
Daniel Frey
>
> I'd like to see some way to declare a class's default constructor, copy
> constructor, or assignment operator, then automatically use the one that the
> compiler would have generated for the class if I hadn't declared it. This
> would be useful if the only reason I declared the function was to make it
> private or protected. One possible way of doing this without adding a new
> keyword is by reusing the keyword 'using';
>
> class Foo {
> protected:
> using Foo(const Foo &); // Autogenerate protected copy constructor
> using Foo &operator=(const Foo &); // Autogenerate protected
> assignment operatror
> };
What about 'default' (already a reserved keyword)?
class Foo
{
protected:
Foo( const Foo& ) = default;
Foo& operator=( const Foo& ) = default;
};
or
class Foo
{
protected:
default Foo( const Foo& );
default Foo& operator=( const Foo& );
};
seems to make sense too. If we have a way to access the
default-copy-ctor and default-assignment-operator, we could also do
funny things like:
class auto_foo
{
public:
auto_foo& operator=( auto_foo& f ) { ... }
auto_foo& operator=( const auto_foo& ) = default; //1
};
//1: Could be faster than a 'real' implementation, as the compiler has a
better chance to optimize it, right?
Regards, Daniel
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: danie...@aixigo.de, web: http://www.aixigo.de
Daniel Frey
> <michael...@acm.org> wrote:
>
> > label: while (exp)
> > {
> > // some code
> > continue label;
> > // some code
> > break label;
> > }
Good, but the label should better be a 'named' loop like:
while label() { ... break label; };
because a label is expected to be accessed via 'goto label' and so I'd
expect the code to continue where label is, not at the end of the loop
followed by label. OTOH a named loop is easy to understand and it should
be intuitive what break label is doing. You example could easily be
obfuscated like this:
label:
// Now I start the loop
while( exp ) {
// some code
break label;
// some code
goto label;
// some code
continue label;
}
// some other code
goto label;
I suggest the label of a named loop is only visible inside the loop and
not a real label accessible by goto.
Andrew Jenner wrote:
>
> I like this idea. Here is another way it could be done, with numeric
> arguments to break and continue:
No, please don't! This will lead to more errors and makes the code
unmaintainable.
> Advantage: named break statements are effectively gotos anyway - this
> method is more structured.
This has nothing to do with 'structured' programming if I have to count
nestings.
Regards, Daniel
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: danie...@aixigo.de, web: http://www.aixigo.de
---
Peter Dimov
<celt...@dollywood.itp.tuwien.ac.at> =====
>LR wrote:
>>
>> Radoslav Getov wrote:
>>
>> > - did I mention 'typeof'?
>>
>> Yes. What do you think that typeof should return?
>
>Nothing, because it's not a function.
... but an operator.
>What does int return?
Nothing, because it's not an operator. :-)
>If you think "higher order", typeof returns a type.
That much is obvious, but which type?
typeof(std::cout << 5) f()
{
return std::cout << 5;
}
What is the return type of f()?
--
Peter Dimov
Multi Media Ltd.
Ron Natalie
James Dennett wrote:
>
> Luckily number 10 made it into the 1998 Standard, though not
> into MSVC++6.
>
> It's quite legal to write:
>
> struct X;
>
> X* px;
>
> class X {
> };
>
This works in VC++ it just gives a warning about a class previously
seen called "struct."
Peter Dimov
>
>I would prefer a syntax like the following, which parallels templates and
>new-style casts, and which also may be easier to parse:
>
> std::vector<std::string> vs;
> std::for_each(vs.begin(),vs.end(),
> lambda<void>(const std::string&b)
> {
> std::cout<<b<<'\n';
> }
> );
How about
std::for_each(vs.begin(), vs.end(), std::cout << _1 << '\n');
This has the slight advantage that it's possible to implement in the current
language. :-)
--
Peter Dimov
Multi Media Ltd.
---
Valentin Bonnard
> I think part of the problem was that when this decision
> was originally made, we did not have enough experience
> with empty classes and structs to see that they should
> actually have a size of zero.
I think part of the problem is that you don't understand
what object identity is, why it maybe critical, and why
the compiler doesn't know when.
-- VB
Valentin Bonnard
> 2. using Base;
> Example:
>
> class Derived : private Base {
> public:
> using Base; // expose the entire public interface of Base.
> // ...
> };
1) I read this as:
typedef Base::Base Base;
(I interpret this as useless way to import _one_ name,
Base, in the local scope. Do you really mean
using Base.*;
? ;-)
2) Why only the public interface ? Why not all the
members ? It's inconsistent to only import public
members: C++ constructs don't depend on accessibillity.
Valentin Bonnard
> Francis Glassborow wrote:
>> Keep the zero overhead principle
> For the love of humanity, define the value of a "default" constructed builtin!
For the love of programmers, define it to deadbeef (or your
prefered invalid value).
Valentin Bonnard
> Preferably, a compiler would have a mode where all accesses (that are
> not predictable at compile time) are checked at runtime whether they
> access uninitialized values (a flag or special value would have to be
> added by the compiler for each object).
> it's a feature that more than a few
> higher-level languages already have built-in.
Can you name one ?
Carl Daniel
"Francis Glassborow" <francis.g...@ntlworld.com> wrote in message
news:Z29zRgAC...@ntlworld.com...
> In article <98890591...@cswreg.cos.agilent.com>, Johan Ericsson
> <live...@hotmail.com> writes
> >Currently, a public base class is practically required to have a virtual
> >destructor (even if empty). These classes with empty destructors do have
> >proper compiler generated copy-ctors and assignment operators. Are we
going
> >to start distinguishing between empty and non-empty destructors?
>
> But he is also proposing that virtual default dtors be provided for any
> class with a virtual member so it would no longer be necessary to write
> and empty dtor.
>
I, for one, would hate to see such a change to the language - I suspect that
it would silently break a lot of code (which is overtly or covertly
dependent on vtable layout). Windows compilers would be virtually required
to provide an option to suppress that behavior as it breaks COM.
Personally, I'd be happy with wording in the standard that encourages
implementations to give warnings on such classes, but not change the default
behavior. If a standard mechanism for requesting advanced features is
incorporated into the next standard (something I'm highly in favor of), then
we could have it both ways.
-cd