>Why not to call the keyword NULL?


Null is reserved. C++ references the C standard, and there NULL is a macro
defined in stdio.h (probably ;) with the ontent of a null pointer.

That also means the whenever C++ will hain a cool npc, NULL will be defined
to that NPC instead of the 0 it is defined now, and programs using NULL
consistently will benefit.

Hopefully the compilers will have a configurable warning "decrepated
feature: 0 used as npc".

Paul


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

James Dennett wrote in message <3B0E3C73.37C832E0@acm.org>...

> Foo* foo = std::null;
>
> as oposed to:
>
> Foo* foo = __null;

>I think the std::null form has some chance of success, because it
>doesn't stomp over names used in existing valid code.

null and npc should be part of the core. It should be usable without
including any headers. And anyway, I think std::null is ugly as hell. You
can't even intelligently teach your tools to highlight it, as one can use
whitespace around :: . I bool, true, false made its way to the language I
see no reason why npc and null could not.

Paul





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

"Balog Pal (mh)" <pasa@lib.hu> wrote in message
news:3b1d001e@andromeda.datanet.hu...
> null and npc should be part of the core. It should be usable without
> including any headers. And anyway, I think std::null is ugly as hell. You
> can't even intelligently teach your tools to highlight it, as one can use
> whitespace around :: . I bool, true, false made its way to the language I
> see no reason why npc and null could not.

The reason is that you risk breaking Standard-conforming
code.  That's a whole different ball game from breaking
non-Standard code by introducing keywords into pre-Standard
languages or the first Standard.



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

Tue,  5 Jun 2001 23:11:08 GMT, Balog Pal (mh) <pasa@lib.hu> pisze:

> null and npc should be part of the core. It should be usable without
> including any headers. And anyway, I think std::null is ugly as hell.

Why not to call the keyword NULL?

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK

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

Marcin 'Qrczak' Kowalczyk wrote:
>
> Tue,  5 Jun 2001 23:11:08 GMT, Balog Pal (mh) <pasa@lib.hu> pisze:
>
> > null and npc should be part of the core. It should be usable without
> > including any headers. And anyway, I think std::null is ugly as hell.
>
> Why not to call the keyword NULL?

Consistency: C++ doesn't have any upper-case keywords today, and
uses all upper-case identifiers for macros only (though errno is
a macro now and doesn't follow the pattern).

Compatibility:  it's currently legal to write a TU in which

#define NULL 0

appears.  I have heard that redefining a keyword is not allowed,
although I've not looked for a reference in the Standard to back
that up.

Readability:  NULL is ugly, IMO.  Its ugliness is justified
while it's a macro, but not otherwise.  (Others clearly think
that std::null is ugly, and null obviously risks running over
identifiers used in existing code.  We can't win ;)

-- James Dennett

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

In article <tgrchq86v7351d@corp.supernews.co.uk>, Neil Butterworth
<neil_butterworth@lineone.net> writes
>Well, why not - anything is better than nothing :-) That was why I suggested
>"warning" rather than "error" for this kind of thing.

The only thing you can require of a compiler is a diagnostic. The sort
of thing you seem to want is purely a QoI issue.


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-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9el257$94f8$1@newssvr05-en0.news.prodigy.com>, Michael Farnham
says...
>
>
>> "Eugene Karpachov" <jk@steel.orel.ru> wrote in message
>> What rationale is behind this "don't have a .h"? It is just making
>maintaning
>> files more difficult, and gain from this is not obvious for me.
>
>I think it has to do with namespaces. iostream puts everything in
>namespace std::, iostream.h does not. cstdlib puts everything in
>namespace std::, stdio.h does not.
>
>Regards
>Mike Farnham

I think this shows why teaching the <.h> form is bad. There is no
iostream in the global namespace, nor a iostream.h which puts it
there, according to the standard.
So the rule is simple: Use <stdheader> and "myheader.h"

True, there is a stdio.h for backwards compatibility with standard C.
But if we teach C++, backwards compatibility with C doesn't matter.

Regards,
Michiel Salters

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

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

Neil Butterworth wrote:
>
> "Greg Comeau" <comeau@panix.com> wrote in message
> news:9ejtkk$gvp$1@panix3.panix.com...
...
> > * Perhaps iostream.h should exist (as with NULL, this doesn't solve the
> >   whole problem, but it's a source of unending confusion).
>
> No, no no - please. Let's teach one rule - "all standard headers don't have
> a .h at the end" rather than "the headers don't have .h at the end, but you
> can pretend they do." This one will go away in a year or so, anyway, as
> fully compliant libraries become prevelant,

My - you're an optimist! Pre-ANSI C hasn't even disappeared yet; I doubt
that <iostream.h> will disappear any faster.


> > * The whole int main() thing is just sad and the amount of
> >   time spent discussing it for years seems pointless.  My gut
> >   just says something needs to be done here.  And not only in say
> >   debated about say "void main" but also about say main taking a
> >   std::string, or some related facility.
>
> I think void main() should be legal. I know _no_ operating system that makes
> any use of the return value of main, If an application (like a shell script)
> ueses the value, then that is its problem.

Most shell scripting languages on Unix use the exit status in one way or
another. For instance, by default, make terminates if a build script
returns a non-zero status.

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

Thu, 24 May 2001 23:46:00 GMT Neil Butterworth =CE=C1=D0=C9=D3=C1=CC:
>> * Perhaps iostream.h should exist (as with NULL, this doesn't solve th=
e
>>   whole problem, but it's a source of unending confusion).
>
>No, no no - please. Let's teach one rule - "all standard headers don't h=
ave
>a .h at the end" rather than "the headers don't have .h at the end, but =
you

What rationale is behind this "don't have a .h"? It is just making mainta=
ning
files more difficult, and gain from this is not obvious for me.

--=20
jk

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

Fri, 25 May 2001 01:03:25 GMT Neil Butterworth =CE=C1=D0=C9=D3=C1=CC:
>>
>> boost have gone one better with stream_cast (or lexical_cast,
>> whatever it's called at the moment).  This can convert between
>> any two types if the source can write itself to a stream in a
>> form the second can read, and I'm sure the boost folks will
>> be keen for it to be included in a future C++ Standard.
>
>Ooh, no - I don't like that. It implies building the  concept of streams
>into the core language, rather than leaving them as a library. The enorm=
ous

But formatted conversion is all what streams are about - they take care a=
bout
locale, they are extensible (you can define operator<< for your own type)
etc. IMO to put all formatting into one place (into iostream) is a good t=
hing.

BTW, it is not core language - the lexical_cast<> is templated function.
                            =20
--=20
jk

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

Proclaimed Eugene Karpachov from the mountaintops:

> Thu, 24 May 2001 23:46:00 GMT Neil Butterworth ???????:
>>> * Perhaps iostream.h should exist (as with NULL, this doesn't solve the
>>>   whole problem, but it's a source of unending confusion).
>>
>>No, no no - please. Let's teach one rule - "all standard headers don't
>>have a .h at the end" rather than "the headers don't have .h at the end,
>>but you
>
> What rationale is behind this "don't have a .h"? It is just making
> maintaning files more difficult, and gain from this is not obvious for me.

The rule only applies to Standard Library "files" you are not allowed to
write, such as <string> and <cmath>.

"files" because they only need behave As If they are files.

--
  Phlip                          phlip_cpp@my-deja.com
============== http://phlip.webjump.com ==============
  --  Have a :-) day  -

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

"Phil Edwards" <pedwards@dmapub.dma.org> wrote in message
news:200105250033.UAA19339@dmapub.dma.org...
>
> In article <tgr3md9vpu2g3c@corp.supernews.co.uk> you write:

[snip]

>
> > > * The whole int main() thing is just sad and the amount of
> > >   time spent discussing it for years seems pointless.  My gut
> > >   just says something needs to be done here.  And not only in say
> > >   debated about say "void main" but also about say main taking a
> > >   std::string, or some related facility.
> >
> > I think void main() should be legal. I know _no_ operating system that
makes
> > any use of the return value of main, If an application (like a shell
script)
> > ueses the value, then that is its problem.
>
> Uh, no.
>
> The point of returning a value from main is so that the OS can make it
> available to other programs, not so that the OS can make use of it itself.
> (What would it do??)  If my script tests your program, you can't point
> at my script and say, "Eh, that's your problem," because then I have no
> possible solutions available to me.  How /else/ is my script supposed to
> decide whether your program succeeded?  Examine sheep entrails?
>
> (Unless you open source your program, then I can fix the code and
recompile
> it.  But I don't think that requirement is going into the C++ Standard.
:-)
>
> I never understood the complaints about int main().  Just s/void/int/
> and be done with it.  The standard already specifies that if you don't
> specify a return value, it's zero.  For that matter, I believe at least
> one compiler does that for you (by default or not, I don't know).

I always use "int main()", because I want to write portable code and have no
problem with it, but most of my code looks like this

int main( int argc, char * argv[]) {
    // do something
}

Notice, the quite legal lack of a return value. So why would this be so
wrong:

void main( int argc, char * argv[]) {
    // do something
}

This second example could simply do what the first one does, but could also
issue a diagnostic if it did explicitly return a value.

[snip]

NeilB




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

"James Dennett" <jdennett@acm.org> wrote in message
news:3B0D91EE.E2789077@acm.org...
>
> Could we add a reserved word __null, and change the definition
> of a null pointer constant so that __null is allowed (and might
> have type __null_t, if we need a type).  Maybe this could even
> live in namespace std, and get a non-mutilated name?

Hello.

Why could it not be just plain 'null'? I would guess you have concerns
regarding not breaking existing code. Is that the only reason or is there
anything else I am missing?

I know my claim might sound silly and pointless, but IMHO, as far as
improving the teachability and accessibility of the language is concerned,
the code would look better without the prefixing '__'.

class Foo {};

Foo* foo = null;

or maybe even as you suggested:

Foo* foo = std::null;

as oposed to:

Foo* foo = __null;

In general, I am in favor of not adding clutter to names and I am also fond
of this whole idea of making the language more accessible and easier to
learn. Personally, I believe that is the only way to make sure we are going
to have a big and ever growing community of C++ programmers.

I hope I will not get flamed for those who feel my post is too shallow.

Regards,

Ney Andr    de Mello Zunino.

"Take of the fruit,
    But guard the seed..."


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

Thu, 24 May 2001 23:47:00 GMT James Dennett =CE=C1=D0=C9=D3=C1=CC:
>
>Could we add a reserved word __null, and change the definition

__nil is shorter (less to type :) and convenient too. BTW, these undersco=
res
are very ugly.

--=20
jk

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

Neil Butterworth wrote:
>
> "James Dennett" <jdennett@acm.org> wrote in message
> news:3B0DA349.46E74099@acm.org...
> > Neil Butterworth wrote:
> > >
> > > "Greg Comeau" <comeau@panix.com> wrote in message
> > > news:9ejtkk$gvp$1@panix3.panix.com...
> >
> > [snip]
> >
> > > > * Things such as:
> > > >     foo(++i, ++i); a[i] = ++i; etc.
> > > >   should probably be outright errors.
> > >
> > > I would say warnings.
> >
> > Compilers are already free to issue warnings for this, but
> > I don't know of any that do.  I see no reason to allow such
> > code, so we should require a diagnostic.  Diagnostics, of
> > course, are whatever the compiler says they are, but most
> > compilers issue hard errors (and stop compilation) if the
> > Standard requires a diagnostic.
>
> Given that i in the above code  might be an object of class type, and that
> ++ might be an operator defined by that class that did nothing, I think that
> the code above should not be an error. Perhaps the standard needs a new
> class of error messages - Mandatory Warnings?

I should have been more explicit.  The problem in the code
above exists only when i is of built-in type, and so the
error should be emitted only in that case.

(There's a lesser problem for UDTs, that of unspecified
evaluation order, but there's no undefined behaviour in
the sense of the C++ Standard.  Nasal demons will not
visit.)

>
> > > > * 0 and the whole null pointer stuff just sucks, period.
> > > >   I don't expect this to be fixed but wonder if adding an n suffix
> > > >   can be the least damanging fix, IOWs, so it would be preferrable
> that
> > > >   NULL would be 0n in C++.  (I'm certain this is a naive suggestion,
> > > >   but I suggest it nonetheless.)
> > >
> > > In C++, I don't see there is any problem here. Maybe you are thinking of
> C
> > > portability? I'd ignore that.
> >
> > This has been looked at many times.  Adding a better npc is
> > relatively easy.  Banning the use of 0 as an npc is less
> > popular (although I personally would love to see it done).
>
> Why?

Why would I like to see C++ admit that ints are *never* pointers?
Consistency, for a start.

const int i = ...;
void *p = i;

is legal *only* if i is known by the rules of the Standard to
evaluate to 0 at compile time.  How disgusting.  This is, in
my mind, an inappropriate use of conceptual overloading.

I think the fact that 0 is a valid npc also encourages C++ users
who learn primarily by experimentation on common platforms to
think that pointers are glorified ints, rather than being
(base object, offset) abstractions in the C++ language.

Another reason to want to get rid of 0 as an npc is so that
we can't call f(MyClass *) with 0 as an argument, only with
null as an argument.

> > > > I'll probably end up expanding this some, so it probably wouldn't
> > > > hurt to ask for feedback, as well as additional considerations
> > > > that would seem helpful to add on this topic.
> > >
> > > One thing that I'd add is a standard ToString() templated function to
> > > convert any type that implements a stream output operator into a string.
> > > This is one of the most frequently asked questions here. I'd also
> deprecate
> > > all formatted input, but maybe that is a bit too radical :-)
> >
> > boost have gone one better with stream_cast (or lexical_cast,
> > whatever it's called at the moment).  This can convert between
> > any two types if the source can write itself to a stream in a
> > form the second can read, and I'm sure the boost folks will
> > be keen for it to be included in a future C++ Standard.
>
> Ooh, no - I don't like that. It implies building the  concept of streams
> into the core language, rather than leaving them as a library.

No, it doesn't.  lexical_cast is implemented in the library, as
boost::lexical_cast.  Its use looks like that of a built-in cast
operator, but the clean separation between library and language
is not threatened (not that it's completely clean anyway).

> The enormous
> success of C (and hence C++) has always been based on the fact that the
> _language_ said nothing about libraries or I/O mechanisms. This is not a
> good time to break that compact.

std::bad_alloc and friends already interfere with that rule, but
a lexical_cast does not need to.

-- James Dennett

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

Pete Becker wrote:
>
> James Dennett wrote:
> >
> > Neil Butterworth wrote:
> > >
> > > "Greg Comeau" <comeau@panix.com> wrote in message
> > > news:9ejtkk$gvp$1@panix3.panix.com...
> >
> > [snip]
> >
> > > > * Things such as:
> > > >     foo(++i, ++i); a[i] = ++i; etc.
> > > >   should probably be outright errors.
> > >
> > > I would say warnings.
> >
> > Compilers are already free to issue warnings for this, but
> > I don't know of any that do.  I see no reason to allow such
> > code, so we should require a diagnostic.  Diagnostics, of
> > course, are whatever the compiler says they are, but most
> > compilers issue hard errors (and stop compilation) if the
> > Standard requires a diagnostic.
> >
>
> How can the compiler recognize this case?
>
> // a.cpp
> void f(const int *ip)
> {
> *(int*)ip += 1;
> }
>
> // b.cpp
> int i = 3;
> foo(&i, &i);

I'm missing your point, I fear.  Where in that code is
the same name used for write access + some other access
between sequence points?

It seems to me that the sequence points induced by function
calls mean that the rule as I stated it should be diagnosable
by inspecting a single statement at a time.  If that
conclusion is wrong then I'd abandon the proposal.

I may well be wrong -- in which case I'd love to see a
clear counterexample.

> Or would the rule be that the compiler must diagnose such things except
> when it can't? <g>

<g> indeed.  That would leave it as a QoI issue, which it is
right now -- and as such the implementors have ignored it to
focus on more important conformance issues, as they should.

-- James Dennett

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

In article <9ejtkk$gvp$1@panix3.panix.com>, comeau@comeaucomputing.com wrote:
>* I always felt a #warning (or perhaps now a _Warning() ala _Pragma
>  from C99) could be beneficial to implementors and users.

Perhaps an #info directive too: The #warning and #info directives only
differs in how the information is presented to the user of the compiler:
Neither stops the compilation. A warning is an indication of that
something might be wrong, whereas the info is just informative.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

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

Greg Comeau writes:
>* 0 and the whole null pointer stuff just sucks, period.
>  I don't expect this to be fixed but wonder if adding an n suffix
>  can be the least damanging fix, IOWs, so it would be preferrable that
>  NULL would be 0n in C++.  (I'm certain this is a naive suggestion,
>  but I suggest it nonetheless.)

Any null pointer constant that would provide proper overload resolution
between pointer types and int would be most welcome in my book.  Is
there any technical reason why special treatment could not be mandated
for (void *)0?  Pre-standard versions of gcc did this -- they defined
NULL as (void *)0 and would allow assignment of this constant to arbitrary
pointer types, but would not allow arbitrary void pointers to be assigned
to pointers of other types.

>* The whole int main() thing is just sad and the amount of
>  time spent discussing it for years seems pointless.  My gut
>  just says something needs to be done here.  And not only in say
>  debated about say "void main" but also about say main taking a
>  std::string, or some related facility.

If there is only one possible return type -- int -- why is it necessary
to write it down?  I find it strange that I am permitted to omit a
return statement (and get an implicit "return 0" if I do so) and yet
I have to specify the return type in the declaration.  In other words,
for those who really don't need and don't want a return type, why not
allo this

main () {
}

as the shortest legal C++ program?  Note that I am not advocating to
allow implicit int in general, only in this specific case.

Mike

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

> "Eugene Karpachov" <jk@steel.orel.ru> wrote in message
> What rationale is behind this "don't have a .h"? It is just making
maintaning
> files more difficult, and gain from this is not obvious for me.

I think it has to do with namespaces. iostream puts everything in
namespace std::, iostream.h does not. cstdlib puts everything in
namespace std::, stdio.h does not.

Regards

--
Regards
Mike Farnham


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

"Ney Andr=E9 de Mello Zunino" wrote:
>=20
> "James Dennett" <jdennett@acm.org> wrote in message
> news:3B0D91EE.E2789077@acm.org...
> >
> > Could we add a reserved word __null, and change the definition
> > of a null pointer constant so that __null is allowed (and might
> > have type __null_t, if we need a type).  Maybe this could even
> > live in namespace std, and get a non-mutilated name?
>=20
> Hello.
>=20
> Why could it not be just plain 'null'? I would guess you have concerns
> regarding not breaking existing code. Is that the only reason or is the=
re
> anything else I am missing?

You've got it.  I'd prefer null, but every time the idea of a new
keyword is introduced to comp.std.c++, someone is hanged for it.
=20
> I know my claim might sound silly and pointless, but IMHO, as far as
> improving the teachability and accessibility of the language is concern=
ed,
> the code would look better without the prefixing '__'.

Absolutely.

> class Foo {};
>=20
> Foo* foo =3D null;
>=20
> or maybe even as you suggested:
>=20
> Foo* foo =3D std::null;
>=20
> as oposed to:
>=20
> Foo* foo =3D __null;

I think the std::null form has some chance of success, because it
doesn't stomp over names used in existing valid code.

> In general, I am in favor of not adding clutter to names and I am also =
fond
> of this whole idea of making the language more accessible and easier to
> learn. Personally, I believe that is the only way to make sure we are g=
oing
> to have a big and ever growing community of C++ programmers.
>=20
> I hope I will not get flamed for those who feel my post is too shallow.

So do I.  It's a fair question.

-- James Dennett

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

Eugene Karpachov wrote:
>=20
> Thu, 24 May 2001 23:47:00 GMT James Dennett =CE=C1=D0=C9=D3=C1=CC:
> >
> >Could we add a reserved word __null, and change the definition
>=20
> __nil is shorter (less to type :) and convenient too.=20

Less to type pales into insignificance next to "clearer."
Given the use of NULL in C++ to date, null seems clearer
to me.

> BTW, these underscores
> are very ugly.

I know.  I intended to avoid the usual "you can't introduce
new keywords" comments.

-- James Dennett

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

[...]

> > > * Things such as:
> > >     foo(++i, ++i); a[i] = ++i; etc.
> > >   should probably be outright errors.
> >
> > I would say warnings.
>
> Compilers are already free to issue warnings for this, but
> I don't know of any that do.

[...]

Intel 4.5 does...



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

James Dennett wrote:
>
> Greg Comeau wrote:

> > * 0 and the whole null pointer stuff just sucks, period.
> >   I don't expect this to be fixed but wonder if adding an n suffix
> >   can be the least damanging fix, IOWs, so it would be preferrable that
> >   NULL would be 0n in C++.  (I'm certain this is a naive suggestion,
> >   but I suggest it nonetheless.)
>
> Could we add a reserved word __null, and change the definition
> of a null pointer constant so that __null is allowed (and might
> have type __null_t, if we need a type).  Maybe this could even
> live in namespace std, and get a non-mutilated name?

Using either syntax, (0n or __null), add a rule to guarantee it can only
be used when the type of the resulting pointer is unambiguous.  For
instance:

 printf("%p\n", NULL); // is an error

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

In article <M3jP6.33509$Lc7.1387406@news20.bellglobal.com>,
Bart Kowalski <me@nospam.com> wrote:
>And of course, speaking of things that should be fixed we're still
>waiting for compilers that actually support the 'export' keyword
>(sorry Greg, I couldn't resist :-)).

If it helps any, we've gone and established an export vigil :)
this week that we'll update as progress is made.  We're keeping
our fingers crossed lest we end up putting our foot in our mouths instead.
--
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!
comeau@comeaucomputing.com  http://www.comeaucomputing.com

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

Phil Edwards wrote:
>
> In article <3B0DAAEB.F97056E6@acm.org> you write:
> > James Dennett wrote:
> > > Neil Butterworth wrote:
> > > > "Greg Comeau" <comeau@panix.com> wrote in message
> > > > news:9ejtkk$gvp$1@panix3.panix.com...
> > >
> > > > > * Things such as:
> > > > >     foo(++i, ++i); a[i] = ++i; etc.
> > > > >   should probably be outright errors.
> [ big snip]
> >
> > How can the compiler recognize this case?
> >
> > // a.cpp
> > void f(const int *ip)
> > {
> > *(int*)ip += 1;
> > }
> >
> > // b.cpp
> > int i = 3;
> > foo(&i, &i);
> >
> > Or would the rule be that the compiler must diagnose such things except
> > when it can't? <g>
>
> I thought that was already the rule.  :-)  But yes, I think the suggestion
> is to diagnose multiple changes to a variable between sequence points, not
> possible problems due to casting away const (a.cpp) nor aliasing (b.cpp).

Casting away const is not the issue. In this case the cast is valid.

> That is, the rule would only apply to the original example of foo(++i,++i)
> and the like.

And that's essentially what this code (in the revised form that I just
posted) does. The point was to move the increment outside the view of
the compiler.

>
> Alternatively/additionally, we could adopt __noalias for your second example,
> and outright ban C-style casts for the first.  We'd have to find some other
> way of doing the thing that C-style casts permit which the new-style casts
> don't (that funky pointer-to-private-base-class, or whatever *grin*).

Bandaids on top of bandaids. Which indicates that the underlying idea
may be seriously flawed...

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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

James Dennett wrote:
>
> Pete Becker wrote:
> >
> > James Dennett wrote:
> > >
> > > Neil Butterworth wrote:
> > > >
> > > > "Greg Comeau" <comeau@panix.com> wrote in message
> > > > news:9ejtkk$gvp$1@panix3.panix.com...
> > >
> > > [snip]
> > >
> > > > > * Things such as:
> > > > >     foo(++i, ++i); a[i] = ++i; etc.
> > > > >   should probably be outright errors.
> > > >
> > > > I would say warnings.
> > >
> > > Compilers are already free to issue warnings for this, but
> > > I don't know of any that do.  I see no reason to allow such
> > > code, so we should require a diagnostic.  Diagnostics, of
> > > course, are whatever the compiler says they are, but most
> > > compilers issue hard errors (and stop compilation) if the
> > > Standard requires a diagnostic.
> > >
> >
> > How can the compiler recognize this case?
> >
> > // a.cpp
> > void f(const int *ip)
> > {
> > *(int*)ip += 1;
> > }
> >
> > // b.cpp
> > int i = 3;
> > foo(&i, &i);
>
> I'm missing your point, I fear.  Where in that code is
> the same name used for write access + some other access
> between sequence points?

The example was nonsense. Sorry. Try this:

// a.cpp
int f(const int *ip)
{
*(int*)ip += 1;
return *ip;
}

// b.cpp
int i = 3;
foo(f(&i), f(&i));

>
> It seems to me that the sequence points induced by function
> calls mean that the rule as I stated it should be diagnosable
> by inspecting a single statement at a time.  If that
> conclusion is wrong then I'd abandon the proposal.
>
> I may well be wrong -- in which case I'd love to see a
> clear counterexample.

Sequence points don't tell you what values get passed to foo. The only
way I know of to resolve this is to adopt the Java rule: code gets
executed from left to right, so foo gets called with 4,5. Of course,
that severely constrains code generators.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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

Pete Becker wrote:
>
> James Dennett wrote:
> >
> > Pete Becker wrote:
> > >
> > > James Dennett wrote:
> > > >
> > > > Neil Butterworth wrote:
> > > > >
> > > > > "Greg Comeau" <comeau@panix.com> wrote in message
> > > > > news:9ejtkk$gvp$1@panix3.panix.com...
> > > >
> > > > [snip]
> > > >
> > > > > > * Things such as:
> > > > > >     foo(++i, ++i); a[i] = ++i; etc.
> > > > > >   should probably be outright errors.
> > > > >
> > > > > I would say warnings.
> > > >
> > > > Compilers are already free to issue warnings for this, but
> > > > I don't know of any that do.  I see no reason to allow such
> > > > code, so we should require a diagnostic.  Diagnostics, of
> > > > course, are whatever the compiler says they are, but most
> > > > compilers issue hard errors (and stop compilation) if the
> > > > Standard requires a diagnostic.
> > > >
> > >
> > > How can the compiler recognize this case?
> > >
> > > // a.cpp
> > > void f(const int *ip)
> > > {
> > > *(int*)ip += 1;
> > > }
> > >
> > > // b.cpp
> > > int i = 3;
> > > foo(&i, &i);
> >
> > I'm missing your point, I fear.  Where in that code is
> > the same name used for write access + some other access
> > between sequence points?
>
> The example was nonsense. Sorry. Try this:
>
> // a.cpp
> int f(const int *ip)
> {
> *(int*)ip += 1;
> return *ip;
> }
>
> // b.cpp
> int i = 3;
> foo(f(&i), f(&i));

Thanks for the clarification.

I thought that was the most likely version, but I did not
wish to put words (or code) into your mouth (or keyboard).

Either foo(4,5) or foo(5,4) is called.  This behaviour
is indeterminate, but I don't think that it's undefined
(i.e., the implementation must make one call or the
other).

That's not the case I'm proposing to catch.  I propose
only to catch the simple case of undefined behaviour
caused by modifying a value twice through the same
name between sequence points, or modifying and
inappropriately reading through the same name between
sequence points.

> >
> > It seems to me that the sequence points induced by function
> > calls mean that the rule as I stated it should be diagnosable
> > by inspecting a single statement at a time.  If that
> > conclusion is wrong then I'd abandon the proposal.
> >
> > I may well be wrong -- in which case I'd love to see a
> > clear counterexample.
>
> Sequence points don't tell you what values get passed to foo. The only
> way I know of to resolve this is to adopt the Java rule: code gets
> executed from left to right, so foo gets called with 4,5. Of course,
> that severely constrains code generators.

I can live with the order of evaluation of arguments being
undefined.  A diagnotic for dumb code such as

int a;

foo(++a, ++a);

would still be nice, and seems reasonably implementable.  It
only catches one form of error, and it's an error only made
by novices (for suitable ideas of what a novice is), but it
would make C++ easier to teach I think.

-- James Dennett

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

James Dennett wrote:
>
> That's not the case I'm proposing to catch.  I propose
> only to catch the simple case of undefined behaviour
> caused by modifying a value twice through the same
> name between sequence points, or modifying and
> inappropriately reading through the same name between
> sequence points.

Through the same name? So this would require a diagnostic:

i = i++;

and this would not:

int& ir = i;
ir = i++;

> I can live with the order of evaluation of arguments being
> undefined.

I can't. It's currently unspecified. Undefined behavior is quite
different.

>
> int a;
>
> foo(++a, ++a);
>
> would still be nice, and seems reasonably implementable.  It
> only catches one form of error, and it's an error only made
> by novices (for suitable ideas of what a novice is), but it
> would make C++ easier to teach I think.
>

How should the standard say this?

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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

Pete Becker wrote:
>
> James Dennett wrote:
> >
> > That's not the case I'm proposing to catch.  I propose
> > only to catch the simple case of undefined behaviour
> > caused by modifying a value twice through the same
> > name between sequence points, or modifying and
> > inappropriately reading through the same name between
> > sequence points.
>
> Through the same name? So this would require a diagnostic:
>
> i = i++;
>
> and this would not:
>
> int& ir = i;
> ir = i++;

Yes.  The first would require a diagnostic (because that's
"clearly" implementable), and the second would not (because
it's hard to define how complex should be the situations in
which we require a diagnostic).

I think that the first case would catch a large percentage
of novice errors in an informal sense.

> > I can live with the order of evaluation of arguments being
> > undefined.
>
> I can't. It's currently unspecified. Undefined behavior is quite
> different.

Thanks for the correction.  Unspecified is what I meant.
It's "undefined" only in that sense that the Standard calls
"unspecified".  I should be more careful in comp.std.c++.

> > int a;
> >
> > foo(++a, ++a);
> >
> > would still be nice, and seems reasonably implementable.  It
> > only catches one form of error, and it's an error only made
> > by novices (for suitable ideas of what a novice is), but it
> > would make C++ easier to teach I think.
> >
>
> How should the standard say this?

(Avoiding the question...) By a modification to 5/4 (paragraph
4 of section 5[expr], that is), to specify situations in which
a diagnostic is required when the behaviour would otherwise be
undefined.

The hard bit, of course, is nailing down what I mean by
"through the same name."  Do I mean a name as in an identifier
or a more general sense?  It would be nice to catch both

int i(0);
foo(++i, ++i);

and

int *p(&i);
foo(++ *p, ++ *p);

but the latter obviously requires a more general (and surely
more complex) notion of the "name" through which an object
is accessed.  Even if we could only require diagnostics for
the first this might be worthwhile.   It's not of value to
experienced programmers, but that should not blind us to the
possible value to teachers of C++.

-- James Dennett

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

In article <3B0D66DA.6868DC42@acm.org>,
James Dennett  <jdennett@acm.org> wrote:
>"Arthur H. Gold" wrote:
>> Ramesh wrote:
>> > In C if u r passing paramters to fnctions means in what way will it pare
>> > it..i.e from right to left or left to right.
>> > or this is a compiler dependent one.
>>
>> It is explicitly undefined.
>>
>> > int i=10;
>> > fun(i++,i,++i);
>> This invokes undefined behavior.
>
>Maybe we (the C++ community) should tighten that up?  See
>below.

I agree, see below.

>> > return 0;
>> > }
>> >
>> > what could be the output.
>> Nasal demons, perhaps?
>
>I shall suggest to the C++ Standards folk that nasal demons
>should be mandated rather than being optional as they are
>at present.  There may be implementation difficulties, but
>I think the additional clarity would be useful.

One of the things which came up at the Copenhagen meeting of
the C++ committee this month is to begin thinging about the
evolution of C++.

One aspect of that is teachabilty and ease of use of C++.
I have a (so far) short list of issues in this direction and
the above is one of them (along with similar stuff like
a[++i] = i; and such).  Just no good can really come of it,
and the other stuff, and/or it's just plain old annoying.

I jotted these down during the committee discussion.
They're motived from two directions: (1) years of teaching
and observing folks using and learning C++ (2) skimming
past logs from http://www.comeaucomputing.com/tryitout ,
the Comeau online compiler.  I'm _sure_ the following list
can be expanded.  I'm also sure it can be considered problematic.
So I'll keep it brief on purpose.  I'm more just trying to mention
the stuff for now than solve them, and perhaps get a ball rolling.
So consider it food for thought more than anything else right now.

Ease of use, teachability considerations:
* Allow a semicolon at end of
    extern "C" / namespaces / function definitions / blocks / #endif
* A missing semicolon at end of struct / class / union / enum
  is also an unending source of problems.  I'm not sure how is
  should be solved.  But perhaps compilers need to do a better
  job here if nothing else.
* Things such as:
    foo(++i, ++i); a[i] = ++i; etc.
  should probably be outright errors.
* 0 and the whole null pointer stuff just sucks, period.
  I don't expect this to be fixed but wonder if adding an n suffix
  can be the least damanging fix, IOWs, so it would be preferrable that
  NULL would be 0n in C++.  (I'm certain this is a naive suggestion,
  but I suggest it nonetheless.)
* Require explicit specification of accessibility when inheriting, so,
  for instance, class X : Y would be an error
* Perhaps iostream.h should exist (as with NULL, this doesn't solve the
  whole problem, but it's a source of unending confusion).
* The whole int main() thing is just sad and the amount of
  time spent discussing it for years seems pointless.  My gut
  just says something needs to be done here.  And not only in say
  debated about say "void main" but also about say main taking a
  std::string, or some related facility.
* I always felt a #warning (or perhaps now a _Warning() ala _Pragma
  from C99) could be beneficial to implementors and users.
* I wonder if allowing `member constants':
   class xyz { static const int var = 99; /* */ };
  shouldn't make sense for more types.
* iostream ctors should allow std::string parameters as appropriate.

I'll probably end up expanding this some, so it probably wouldn't
hurt to ask for feedback, as well as additional considerations
that would seem helpful to add on this topic.
--
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!
comeau@comeaucomputing.com  http://www.comeaucomputing.com

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

"Greg Comeau" <comeau@panix.com> wrote in message
news:9ejtkk$gvp$1@panix3.panix.com...

> Ease of use, teachability considerations:
> * Allow a semicolon at end of
>     extern "C" / namespaces / function definitions / blocks / #endif

Yes!

> * A missing semicolon at end of struct / class / union / enum
>   is also an unending source of problems.  I'm not sure how is
>   should be solved.  But perhaps compilers need to do a better
>   job here if nothing else.

Yes, and they can - cfront derived compilers always gave you a diagnostic.

> * Things such as:
>     foo(++i, ++i); a[i] = ++i; etc.
>   should probably be outright errors.

I would say warnings.

> * 0 and the whole null pointer stuff just sucks, period.
>   I don't expect this to be fixed but wonder if adding an n suffix
>   can be the least damanging fix, IOWs, so it would be preferrable that
>   NULL would be 0n in C++.  (I'm certain this is a naive suggestion,
>   but I suggest it nonetheless.)

In C++, I don't see there is any problem here. Maybe you are thinking of C
portability? I'd ignore that.

> * Require explicit specification of accessibility when inheriting, so,
>   for instance, class X : Y would be an error

Agree.

> * Perhaps iostream.h should exist (as with NULL, this doesn't solve the
>   whole problem, but it's a source of unending confusion).

No, no no - please. Let's teach one rule - "all standard headers don't have
a .h at the end" rather than "the headers don't have .h at the end, but you
can pretend they do." This one will go away in a year or so, anyway, as
fully compliant libraries become prevelant,

> * The whole int main() thing is just sad and the amount of
>   time spent discussing it for years seems pointless.  My gut
>   just says something needs to be done here.  And not only in say
>   debated about say "void main" but also about say main taking a
>   std::string, or some related facility.

I think void main() should be legal. I know _no_ operating system that makes
any use of the return value of main, If an application (like a shell script)
ueses the value, then that is its problem.

> * I always felt a #warning (or perhaps now a _Warning() ala _Pragma
>   from C99) could be beneficial to implementors and users.

Dunno.

> * I wonder if allowing `member constants':
>    class xyz { static const int var = 99; /* */ };
>   shouldn't make sense for more types.

Yes.

> * iostream ctors should allow std::string parameters as appropriate.

Yes, yes, yes. It's ludicrous that they don't.

> I'll probably end up expanding this some, so it probably wouldn't
> hurt to ask for feedback, as well as additional considerations
> that would seem helpful to add on this topic.

One thing that I'd add is a standard ToString() templated function to
convert any type that implements a stream output operator into a string.
This is one of the most frequently asked questions here. I'd also deprecate
all formatted input, but maybe that is a bit too radical :-)

NeilB






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

Greg Comeau wrote:
>
> In article <3B0D66DA.6868DC42@acm.org>,
> James Dennett  <jdennett@acm.org> wrote:
> >"Arthur H. Gold" wrote:
> >> Ramesh wrote:
> >> > In C if u r passing paramters to fnctions means in what way will it pare
> >> > it..i.e from right to left or left to right.
> >> > or this is a compiler dependent one.
> >>
> >> It is explicitly undefined.
> >>
> >> > int i=10;
> >> > fun(i++,i,++i);
> >> This invokes undefined behavior.
> >
> >Maybe we (the C++ community) should tighten that up?  See
> >below.
>
> I agree, see below.
>
> >> > return 0;
> >> > }
> >> >
> >> > what could be the output.
> >> Nasal demons, perhaps?
> >
> >I shall suggest to the C++ Standards folk that nasal demons
> >should be mandated rather than being optional as they are
> >at present.  There may be implementation difficulties, but
> >I think the additional clarity would be useful.
>
> One of the things which came up at the Copenhagen meeting of
> the C++ committee this month is to begin thinging about the
> evolution of C++.
>
> One aspect of that is teachabilty and ease of use of C++.
> I have a (so far) short list of issues in this direction and
> the above is one of them (along with similar stuff like
> a[++i] = i; and such).  Just no good can really come of it,
> and the other stuff, and/or it's just plain old annoying.

Additional context: this question (or ones equivalent to it)
are asked probably once a day on average on
alt.comp.lang.learn.c-c++.  We can and should teach people
not to write such ugly code, but it would be nice not to
have to threaten them with demonic emissions in order to
motivate them.

>
> I jotted these down during the committee discussion.
> They're motived from two directions: (1) years of teaching
> and observing folks using and learning C++ (2) skimming
> past logs from http://www.comeaucomputing.com/tryitout ,
> the Comeau online compiler.  I'm _sure_ the following list
> can be expanded.  I'm also sure it can be considered problematic.
> So I'll keep it brief on purpose.  I'm more just trying to mention
> the stuff for now than solve them, and perhaps get a ball rolling.
> So consider it food for thought more than anything else right now.
>
> Ease of use, teachability considerations:
> * Allow a semicolon at end of
>     extern "C" / namespaces / function definitions / blocks / #endif

Could this be done by allowing an empty declaration?  (I guess
not without breaking the rule that a declaration must add a new
name.)

> * A missing semicolon at end of struct / class / union / enum
>   is also an unending source of problems.  I'm not sure how is
>   should be solved.  But perhaps compilers need to do a better
>   job here if nothing else.

I'd agree that a good compiler warning should be enough; if there's
a syntax error after the end of such a definition, why not back up
and assume a semi-colon... if that succeeds, a clear diagnostic
should be possible.

> * Things such as:
>     foo(++i, ++i); a[i] = ++i; etc.
>   should probably be outright errors.

AFAICS, in the absence of multiple access paths to the same
object that's quite easy to do.  Should we mandate it only if
conflicting accesses are via the same name?  I.e., should the
following code still not require a dianostic:

int a(0);
int &r(a);
foo(++a, ++r);

even though we can and should require a diagnostic for

foo(++a, ++a);

The first version would still give undefined behaviour, I fear.

> * 0 and the whole null pointer stuff just sucks, period.
>   I don't expect this to be fixed but wonder if adding an n suffix
>   can be the least damanging fix, IOWs, so it would be preferrable that
>   NULL would be 0n in C++.  (I'm certain this is a naive suggestion,
>   but I suggest it nonetheless.)

Could we add a reserved word __null, and change the definition
of a null pointer constant so that __null is allowed (and might
have type __null_t, if we need a type).  Maybe this could even
live in namespace std, and get a non-mutilated name?

> * Require explicit specification of accessibility when inheriting, so,
>   for instance, class X : Y would be an error

Might be good for teaching.  It would slightly break some nice
idioms such as

using boost::noncopyable;

class X : noncopyable {
 // blah
};

Of course, these "idioms" can also be seen as "abuse of language."

> * Perhaps iostream.h should exist (as with NULL, this doesn't solve the
>   whole problem, but it's a source of unending confusion).

Interesting suggestion.  I was tempted to dismiss is out of hand,
but those in the know would avoid it anyway, and those less
knowledgable are unlikely to be bitten by the differences between
old (non-Standard) versions and a proposed Standard version.
I imagine the Standard version, were one created, would include
<iostream> and inject the names into the global namespace --
would it also include any other headers, to be as compatible
as reasonable with pre-Standard IOStreams?

> * The whole int main() thing is just sad and the amount of
>   time spent discussing it for years seems pointless.  My gut
>   just says something needs to be done here.  And not only in say
>   debated about say "void main" but also about say main taking a
>   std::string, or some related facility.

I'd love to just define the behaviour of "void main()."  It's not
hard to figure out wording which does what the naive user wants;
essentially, wrap their void main() in a real int main() which
implicitly returns 0.

> * I always felt a #warning (or perhaps now a _Warning() ala _Pragma
>   from C99) could be beneficial to implementors and users.

Absolutely.  A non-preprocessor variant would be best, to allow
(for example) a warning to be issued if a particular macro is
used.

> * I wonder if allowing `member constants':
>    class xyz { static const int var = 99; /* */ };
>   shouldn't make sense for more types.

I think the same about the switch construct.  Forcing it to work
only for integral types seems to me to be basic the language design
around a low-level implementation detail.  Why should we not be
able to switch on a std::string?  (Yes, I know that there are
usually better ways, but lots of special case rules for integral
types make C++ more complicated than it needs to be.)

> * iostream ctors should allow std::string parameters as appropriate.

I hope that one doesn't meet much resistance; it seems to fit the
goal of making a more consistent library.

Now: can you really make a compiler which supplies nasal demons?

-- James Dennett

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

Neil Butterworth wrote:
>
> "Greg Comeau" <comeau@panix.com> wrote in message
> news:9ejtkk$gvp$1@panix3.panix.com...

[snip]

> > * Things such as:
> >     foo(++i, ++i); a[i] = ++i; etc.
> >   should probably be outright errors.
>
> I would say warnings.

Compilers are already free to issue warnings for this, but
I don't know of any that do.  I see no reason to allow such
code, so we should require a diagnostic.  Diagnostics, of
course, are whatever the compiler says they are, but most
compilers issue hard errors (and stop compilation) if the
Standard requires a diagnostic.

> > * 0 and the whole null pointer stuff just sucks, period.
> >   I don't expect this to be fixed but wonder if adding an n suffix
> >   can be the least damanging fix, IOWs, so it would be preferrable that
> >   NULL would be 0n in C++.  (I'm certain this is a naive suggestion,
> >   but I suggest it nonetheless.)
>
> In C++, I don't see there is any problem here. Maybe you are thinking of C
> portability? I'd ignore that.

This has been looked at many times.  Adding a better npc is
relatively easy.  Banning the use of 0 as an npc is less
popular (although I personally would love to see it done).

> > I'll probably end up expanding this some, so it probably wouldn't
> > hurt to ask for feedback, as well as additional considerations
> > that would seem helpful to add on this topic.
>
> One thing that I'd add is a standard ToString() templated function to
> convert any type that implements a stream output operator into a string.
> This is one of the most frequently asked questions here. I'd also deprecate
> all formatted input, but maybe that is a bit too radical :-)

boost have gone one better with stream_cast (or lexical_cast,
whatever it's called at the moment).  This can convert between
any two types if the source can write itself to a stream in a
form the second can read, and I'm sure the boost folks will
be keen for it to be included in a future C++ Standard.

-- James Dennett

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

In article <tgr3md9vpu2g3c@corp.supernews.co.uk> you write:
> > * Allow a semicolon at end of
> >     extern "C" / namespaces / function definitions / blocks / #endif
>
> Yes!

Works for me, except for #endif.  Let's not make "#endif ; " a special case.
I'd rather ignore anything following #endif, including comments.  That would
also solve the problem.


> > * Perhaps iostream.h should exist (as with NULL, this doesn't solve the
> >   whole problem, but it's a source of unending confusion).
>
> No, no no - please. Let's teach one rule - "all standard headers don't have
> a .h at the end" rather than "the headers don't have .h at the end, but you
> can pretend they do." This one will go away in a year or so, anyway, as
> fully compliant libraries become prevelant,

I fully agree with you.  I don't expect iostream.h to go away anytime soon
(one year? ha), but I think trying to standardize the contents of iostream.h
would just cause problems.


> > * The whole int main() thing is just sad and the amount of
> >   time spent discussing it for years seems pointless.  My gut
> >   just says something needs to be done here.  And not only in say
> >   debated about say "void main" but also about say main taking a
> >   std::string, or some related facility.
>
> I think void main() should be legal. I know _no_ operating system that makes
> any use of the return value of main, If an application (like a shell script)
> ueses the value, then that is its problem.

Uh, no.

The point of returning a value from main is so that the OS can make it
available to other programs, not so that the OS can make use of it itself.
(What would it do??)  If my script tests your program, you can't point
at my script and say, "Eh, that's your problem," because then I have no
possible solutions available to me.  How /else/ is my script supposed to
decide whether your program succeeded?  Examine sheep entrails?

(Unless you open source your program, then I can fix the code and recompile
it.  But I don't think that requirement is going into the C++ Standard.  :-)

I never understood the complaints about int main().  Just s/void/int/
and be done with it.  The standard already specifies that if you don't
specify a return value, it's zero.  For that matter, I believe at least
one compiler does that for you (by default or not, I don't know).


> > * I always felt a #warning (or perhaps now a _Warning() ala _Pragma
> >   from C99) could be beneficial to implementors and users.
>
> Dunno.

I'd like a #warning (if you use this file at all, you see it) as well as some
kind of "_warning" attached to a name (you won't see this untill you actually
try and call the function / use the variable / create an instance of a type).

We're about to add this as another "attribute" in GCC.  You can flag a
thing as "deprecated" and the compiler will warn about it, if-and-only-if
it gets used.  (The folks at Apple rule.  :-)



> > * iostream ctors should allow std::string parameters as appropriate.
>
> Yes, yes, yes. It's ludicrous that they don't.

I can see both sides of this argument.  It should at least be made
available, present or not according to some option (a #define before
#including <fstream>, or something).

The argument for /not/ allowing it would go away if we had a <stringfwd>
header, a la <iosfwd>.  That'd be, what, three lines?


Luck++;
Phil

--
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

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

James Dennett wrote:
>
> Neil Butterworth wrote:
> >
> > "Greg Comeau" <comeau@panix.com> wrote in message
> > news:9ejtkk$gvp$1@panix3.panix.com...
>
> [snip]
>
> > > * Things such as:
> > >     foo(++i, ++i); a[i] = ++i; etc.
> > >   should probably be outright errors.
> >
> > I would say warnings.
>
> Compilers are already free to issue warnings for this, but
> I don't know of any that do.  I see no reason to allow such
> code, so we should require a diagnostic.  Diagnostics, of
> course, are whatever the compiler says they are, but most
> compilers issue hard errors (and stop compilation) if the
> Standard requires a diagnostic.
>

How can the compiler recognize this case?

// a.cpp
void f(const int *ip)
{
*(int*)ip += 1;
}

// b.cpp
int i = 3;
foo(&i, &i);

Or would the rule be that the compiler must diagnose such things except
when it can't? <g>

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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

In article <3B0DAAEB.F97056E6@acm.org> you write:
> James Dennett wrote:
> > Neil Butterworth wrote:
> > > "Greg Comeau" <comeau@panix.com> wrote in message
> > > news:9ejtkk$gvp$1@panix3.panix.com...
> >
> > > > * Things such as:
> > > >     foo(++i, ++i); a[i] = ++i; etc.
> > > >   should probably be outright errors.
[ big snip]
>
> How can the compiler recognize this case?
>
> // a.cpp
> void f(const int *ip)
> {
> *(int*)ip += 1;
> }
>
> // b.cpp
> int i = 3;
> foo(&i, &i);
>
> Or would the rule be that the compiler must diagnose such things except
> when it can't? <g>

I thought that was already the rule.  :-)  But yes, I think the suggestion
is to diagnose multiple changes to a variable between sequence points, not
possible problems due to casting away const (a.cpp) nor aliasing (b.cpp).
That is, the rule would only apply to the original example of foo(++i,++i)
and the like.

Alternatively/additionally, we could adopt __noalias for your second example,
and outright ban C-style casts for the first.  We'd have to find some other
way of doing the thing that C-style casts permit which the new-style casts
don't (that funky pointer-to-private-base-class, or whatever *grin*).


Luck++;
Phil

--
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

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

"James Dennett" <jdennett@acm.org> wrote in message
news:3B0DA349.46E74099@acm.org...
> Neil Butterworth wrote:
> >
> > "Greg Comeau" <comeau@panix.com> wrote in message
> > news:9ejtkk$gvp$1@panix3.panix.com...
>
> [snip]
>
> > > * Things such as:
> > >     foo(++i, ++i); a[i] = ++i; etc.
> > >   should probably be outright errors.
> >
> > I would say warnings.
>
> Compilers are already free to issue warnings for this, but
> I don't know of any that do.  I see no reason to allow such
> code, so we should require a diagnostic.  Diagnostics, of
> course, are whatever the compiler says they are, but most
> compilers issue hard errors (and stop compilation) if the
> Standard requires a diagnostic.

Given that i in the above code  might be an object of class type, and that
++ might be an operator defined by that class that did nothing, I think that
the code above should not be an error. Perhaps the standard needs a new
class of error messages - Mandatory Warnings?

> > > * 0 and the whole null pointer stuff just sucks, period.
> > >   I don't expect this to be fixed but wonder if adding an n suffix
> > >   can be the least damanging fix, IOWs, so it would be preferrable
that
> > >   NULL would be 0n in C++.  (I'm certain this is a naive suggestion,
> > >   but I suggest it nonetheless.)
> >
> > In C++, I don't see there is any problem here. Maybe you are thinking of
C
> > portability? I'd ignore that.
>
> This has been looked at many times.  Adding a better npc is
> relatively easy.  Banning the use of 0 as an npc is less
> popular (although I personally would love to see it done).

Why?

> > > I'll probably end up expanding this some, so it probably wouldn't
> > > hurt to ask for feedback, as well as additional considerations
> > > that would seem helpful to add on this topic.
> >
> > One thing that I'd add is a standard ToString() templated function to
> > convert any type that implements a stream output operator into a string.
> > This is one of the most frequently asked questions here. I'd also
deprecate
> > all formatted input, but maybe that is a bit too radical :-)
>
> boost have gone one better with stream_cast (or lexical_cast,
> whatever it's called at the moment).  This can convert between
> any two types if the source can write itself to a stream in a
> form the second can read, and I'm sure the boost folks will
> be keen for it to be included in a future C++ Standard.

Ooh, no - I don't like that. It implies building the  concept of streams
into the core language, rather than leaving them as a library. The enormous
success of C (and hence C++) has always been based on the fact that the
_language_ said nothing about libraries or I/O mechanisms. This is not a
good time to break that compact.

NeilB





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

"Pete Becker" <petebecker@acm.org> wrote in message
news:3B0DAAEB.F97056E6@acm.org...
> James Dennett wrote:
> >
> > Neil Butterworth wrote:
> > >
> > > "Greg Comeau" <comeau@panix.com> wrote in message
> > > news:9ejtkk$gvp$1@panix3.panix.com...
> >
> > [snip]
> >
> > > > * Things such as:
> > > >     foo(++i, ++i); a[i] = ++i; etc.
> > > >   should probably be outright errors.
> > >
> > > I would say warnings.
> >
> > Compilers are already free to issue warnings for this, but
> > I don't know of any that do.  I see no reason to allow such
> > code, so we should require a diagnostic.  Diagnostics, of
> > course, are whatever the compiler says they are, but most
> > compilers issue hard errors (and stop compilation) if the
> > Standard requires a diagnostic.
> >
>
> How can the compiler recognize this case?
>
> // a.cpp
> void f(const int *ip)
> {
> *(int*)ip += 1;
> }
>
> // b.cpp
> int i = 3;
> foo(&i, &i);
>
> Or would the rule be that the compiler must diagnose such things except
> when it can't? <g>
>

Well, why not - anything is better than nothing :-) That was why I suggested
"warning" rather than "error" for this kind of thing.

NeilB






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