Reference: <3.0.5.32.19981208145702.0098f430@central.beasys.com>

I wrote:
> (There is far more COBOL code written worldwide than probably any
> other single language, COBOL being an international standard as
> well.  All COBOL programs must begin with IDENTIFIER DIVISION
> regardless of what country they come from.)

That should, of course, be IDENTIFICATION DIVISION.  Eesh.  (And to
think I wrote a COBOL compiler some years ago.  Just goes to show
you how my mind has forgotten anything COBOL.)

-- David R. Tribble, dtribble@technologist.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

References: <DOT1$LAoY9Y2EwwP@robinton.demon.co.uk>

Francis Glassborow wrote:
> On the subject of identifiers; Mats Henricson & Erik Nyquist in
> 'Industrial Strength C++' (well worth reading) have this to say:
>   Rec 1.2  Use English names for identifiers.
>   Do not use names that are difficult to understad.  Most importantly,
>   do not use names that are understood only by those who understand
>   your native language.

Of course, if your source code is never intended to leave the country
(or the building where you work, for that matter), you can use any
names you like.  But if your code is meant to be read by others,
especially others in foreign countries, stick with a common
language.  It might also be helpful here to remember that the
keywords in C/C++ are English in nature, so mixing them with
non-English names would probably be confusing.  (Comments are not so
restricted, but most comments are probably written in a single
language within a given program, or at least within a given
block.)

(There is far more COBOL code written worldwide than probably any
other single language, COBOL being an international standard as
well.  All COBOL programs must begin with IDENTIFIER DIVISION
regardless of what country they come from.)

I can't help throwing this out, though, just to be cheeky:

    #include <stdio.h>

    #define entero  int
    #define letra   char
    #define para    for
    #define regresa return
    ...

    entero main(entero argn, letra **argv)
    {
        entero  i;

        para (i = 0;  i < argn;  i++)
            printf("%d: '%s'\n", i, argn[i]);

        regresa 0;
    }

(Of course, this still has to use the English names for the standard
library header filenames and functions.  ISO C and C++ are
international standards, after all.  But even these could be
converted into Spanish with enough effort.)

-- David R. Tribble, dtribble@technologist.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Here is my second try for this post, sorry if it appears twice, it's been
3 days since the first...

Bjarne Stroustrup wrote ...
>Hmm. I thought my original statement was reasonably clear: If a program
>is to be used internationally it is usually best to stick to English and
>ASCII.
>
>If I were to write a program that would be used in Denmark only, I could
>use identifiers such as trea, bedsteforaeldre, and roedgroed_med_floede
>(apologies to Danish readers - my mailer doesn't support the last three
>letters in the Danish alphabet well). However, except for very small
>programs for my own personal use, I would in most cases worry that I
>compromised the utility/value of my code by severely limiting the number
>of people who could read my code easily.

AS I'm sure you know, learning C++ keywords is not really learning english
so I would be very surprised to learn that most non-english C++ programmers
would really understand the english language used in the context of complex
comments or meaningful identifier in a non trivial program. I am not sure
that using english would really be better than using russian or french. But
as there are many english programmers, (those) many C++ programmers will be
happy. However I think it does not make the program more    international   ,
just understandable by more programmers than if another language was used
(until chinese people gets into programming by the millions?).

Maybe this explains why so many programs are written with bad identifiers
and no comments... most programmers wouldn't understand them anyway :-)

Michel Michaud micm19@removethis.mail2.cstjean.qc.ca
http://www3.sympatico.ca/michel.michaud



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <741pmu$73i$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
writes
>But Francis, if you start a project that will be designed and
>written by French programmers, documented by French technical
>writers, used by French users, and maintained by French
>programmers, would you insist that they write the program in
>English? If so, why?

That would be their choice, however they would have a problem if they
wanted to use third party components.  In addition how big a sale would
a component library have if it were written in any language other than
English?

While we are on this subject what about the problems of Arabic (from
their perspective) all our code is written back to front in some weird
alien alphabet or Chinese etc.  or languages using a Cyrillic alphabet.

If you really want to do all your own work use whatever language you
like but if you want to capitalise on the work of others you don't have
as much choice as you might like.  Sometimes we have to be pragmatic.



Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:
  ...
> > > Reading Stroustrup for
> > > example, one could get the feelings that all important C++ programs
> > > should be written in english only... I'm not sure that's what he
> > > meant, but this is what he wrote (p.831):
> > >
> > > "A program is hard to read unless you understand the natural language
> > > used for identifiers and comments. Consequently, for programs used
> > > internationally it is usually best to stick to English and ASCII."
> >
> > My interpretation is that this reflects the simple fact that
> > English/ASCII
> > is most likely to be understood in the international community, and this
> > paragraph is suggesting a way that I can write a program and have a fair
> > number of people able to understand it.  This reflects the fact that
> > (say) English is the most commonly understood language in international
> > circles.
>
> I think so. I hope so! Mr. Stroustrup, do you have any comments
> at this time?

Hmm. I thought my original statement was reasonably clear: If a program
is to be used internationally it is usually best to stick to English and
ASCII.

If I were to write a program that would be used in Denmark only, I could
use identifiers such as trea, bedsteforaeldre, and roedgroed_med_floede
(apologies to Danish readers - my mailer doesn't support the last three
letters in the Danish alphabet well). However, except for very small
programs for my own personal use, I would in most cases worry that I
compromised the utility/value of my code by severely limiting the number
of people who could read my code easily.

Other people may evaluate the tradeoffs differently. Not everybody thinks
of themselves as writing for an international market.

Unless all machines on which that source code should be viewed and/or
compiled supported at least the Latin-1 character set, things would become
even more interesting: The "extra" scandinavian characters take up the
character set encodings that ASCII use for [ ] ^ \ { and }. See pg 159
of "The Design and Evolution of C++" for an example.

 - Bjarne
Bjarne Stroustrup - http://www.research.att.com/~bs



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michel Michaud wrote:

> For a start, I see three : clear_screen(), cursor_to(x,y)
> and read_key()... (I have no real need for any of those
> but from what I can see on C++ newgroups, many people
> want them)

Such functions make no sens in isolation. Having a
standard clear_screen() would help no one.

What is usefull is a complete vt package, or something
like that. Just to specify the behaviour of these functions,
you have to define what is the virtual screen and its
properties.

Some people want to have a clear_screen() at program startup
and a read_key() at the end (on DOS), and only stdio between
them; on Unix no one wants that (and users would really hate
that): command output follow each other in a natural way, and
I don't want to type a letter to quit a simple program (indeed
for many programs, there is no real terminal, and no one to
type the key).

So the usefullness of these functions depends on the kind
of system we use; and even on Windows, a DOS utility might
be ok in DOS, but unusable in Windows (Run a DOS command...)
because the window  is closed immedialty after the program
quits.

So the usefullness of these functions depends on the kind
of virtual terminal !

Under the Turbo IDE, it's difficult to distinguish outputs
of different runs of the same program, as they are collapsed,
with no separator, so people find is easier to clear the
screen first.

So these VT functions are often used as a cure for an
unpleasent IDE (where there isn't any option to clear
the screen, insert a separator, or wait until a key is
pressed at the end of program execution).

Functions usefull in a particular IDE or kind of terminal
don't need to be standardised.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36635688.FB357D89@nonexistant.com>,
  "Robert O'Dowd" <nospam@nonexistant.com> wrote:
>
> Michel Michaud wrote:
> >
> > James Kuyper wrote <3660C85B.19F0449D@wizard.net>...
> > >
> > >Michel Michaud wrote:
> > >....
> > >> Again where would "existing practice" stops? For one, I suppose most
> > >> people would not even consider function names that are not english
> > >> words or that do not adhere to the common naming scheme of C++ (all
> > >
> > >I think there are a lot of programmers whose native language is not
> > >English, who would disagree with you on that.
> >
> > I'm not saying I would oppose it only that an "official committee" would
> > choose english as the base language. Are you saying that most programmers,
> > even those whose native language is not english, would agree to use
> > only english or are you saying the contrary? Reading Stroustrup for
> > example, one could get the feelings that all important C++ programs
> > should be written in english only... I'm not sure that's what he
> > meant, but this is what he wrote (p.831):
> >
> > "A program is hard to read unless you understand the natural language
> > used for identifiers and comments. Consequently, for programs used
> > internationally it is usually best to stick to English and ASCII."
>
> My interpretation is that this reflects the simple fact that
> English/ASCII
> is most likely to be understood in the international community, and this
> paragraph is suggesting a way that I can write a program and have a fair
> number of people able to understand it.  This reflects the fact that
> (say) English is the most commonly understood language in international
> circles.

I think so. I hope so! Mr. Stroustrup, do you have any comments
at this time?

> To support programmers whos native language is not English should be
> relatively straight forward *if* the focus is simply on character sets
> and keywords.  For example, if we want a German version of C++, pick
> a character set that supports umlauts and things (and is probably
> compatible with a German keyboard, should such a thing exist).  Then
> simply translate the keywords (for, do, while, if, else, template,
> exception, ...) into German.

And what about keywords that aren't (single, full) English words?
    asm auto bool char const extern goto inline int
    namespace struct typedef typeid typename wchar_t

I don't think anyone has seriously proposed changing the keywords
for other spoken languages. It could certainly be a viable language,
but it wouldn't be C++ anymore.

I expect C++ programmers to know and understand the C++ keywords,
even if they don't know any other English. (Remember that C++ is
the TINIEST of tiny subsets of English. There's no C++ keyword
for restaurant or house or boat because these things are not part
of the programming domain. There's also no C++ keyword for parent
or sibling or child or root, although these things may very well
be part of the programming domain, because the computer language
doesn't directly address them.

(By the same token, physicians don't have to know every Latin word
 in the dictionary. They use those terms that convey a common idea
 quickly, and they conduct the bulk of their conversations in the
 language appropriate to their location.)

You are of course free to implement a data structure with a pointer
named "next" and a pointer named "parent." By the same token, a
French programmer could create a data structure with a pointer
named "prochain" and a pointer named "pere". (The programmer really
wants to put an accent on the first e in pere, but until recently
that was forbidden!)

One important measure of a good programmer is how easily the code
can be maintained. Can you imagine trying to fix an error or add
a new feature to a program, when the variable names and comments
were all written in a foreign language?

    // HOMSHE -- Ip du tem, womma de llaiuyha voppi. Moiy dettim
    // whiggemm uppi ghggum! Ha ha ha... Imm dello vlannz.
    //  15-6-89 Phlong Di whiggemm ip noi ghggum ip du vlannz em
    //                 wiyytt joo soddp. Ew D'lopp froom American
    //                 yopph quimme Ronald Regan. HAHAHA!
    //  22-6-89 Riuuy  Phlong ip slkko BANNA noi eew 25 grosse.
    //  23-6-89 Phlong Et noi!
    //  23-6-89 Riuuy  Et pooli, quimme ghggum-lood!
    char *floobwa(int llaiuyha, int ghggphsoy, int whiggi)
    {
        char droopi[100];

        // Ip ghggum de onneh wollp?
        if (whuum_wollp(llaiuyha, whiggi) > whiggi)
        {
            strcpy(droopi, "Snookums, wherrin uppi ip: ");
        }
        else
        {
            // 19-6-89 Snookums  Epp '\0' foon zobbi!
            droopi[0] = '\0';
        }

        // Dfoophllshn uppir droopi pit Snookums, tis nwod?
        // 1-7-89 Snookums  Llaiuyha quoth ftr-spannik
        Dfooph(droopi, llaiuyha);
        if (ghggphsoy > llaiuyha / 2)
        {
            // 19-6-89 Snookums  Llaiuyha/5 + int(0.3*Llaiuyha) = Llaiuyha/2
            Dfooph(droopi, llaiuyha / 2);
            //Dfooph(droopi, llaiuyha/5 + int(0.3*llaiuyha));
            // Ip Star Trek wijjel Picard, ekklub den Kirk?
        }

        // Hut mikk
        return strcpy(new char[strlen(droopi)+1], droopi);
    }

The compiler, of course, has no trouble with this code fragment. But
I know that YOU don't know THIS language -- having just made it up
myself -- so I wouldn't expect you to be able to maintain it. (Yes, I
really do have little Phlong vs. Riuuy battles on my desk here... and
I have no idea how to pronounce what you see above... you have no
idea what it's like to be me... *Sigh*)

My point is, (yes, I do have one, thank you very much):

Just as you don't have to understand Italian to cook a pizza, you
also don't have to know much English in order to know the C++
keywords, and be a productive programmer in your native environment!

Hut mikk.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <DOT1$LAoY9Y2EwwP@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
>
> In article <73vf8a$8e8$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
> writes
> >But surely it's obvious to anyone who programs on a PC that clrscr
> >is short for CLeaR SCReen... right? No. Even among computers that
> >have a screen to clear, they're not all PCs. Perhaps a better name
> >would be erase? ...No, that might delete files from my hard disk...
>
> If everyone agreed there would be no problem.  It is exactly because not
> everyone agrees (and therefore the same common function can have
> different names -- and different parameter orderings) that a standard
> function name might be useful.
>
> On the subject of identifiers; Mats Henricson & Erik Nyquist in
> 'Industrial Strength C++'  (well worth reading) have this to say:
> Rec 1.2  Use English names for identifiers.
> Do not use names that are difficult to understad.  Most importantly, do
> not use names that are understood only by those who understand your
> native language.  What does the word *bil* mean to an English or
> Japanese programmer?  Not many know that it is the Swedish word for car.

To me, "bil" would probably mean 10**9 or 10**12. There's another
problem: even English words mean different things to different people:

  Number                              American words   British words
  ------   -------------------------  ---------------  --------------------
  10**3  =                     1,000  One thousand     One thousand
  10**6  =                 1,000,000  One million      One million
  10**9  =             1,000,000,000  One billion      One thousand million
  10**12 =         1,000,000,000,000  One trillion     One billion
  10**15 =     1,000,000,000,000,000  One quadrillion  One thousand billion
  10**18 = 1,000,000,000,000,000,000  One quintillion  One million billion

> Note that neither author is a native English speaker so perhaps they can
> get away with what would not be PC for those whose mother tongue is some
> dialect of English.

I shouldn't be passionate about the subject, since I'm an English
speaker, and every project I work on will be English-based. But I
*am* passionate about it, and you should know that I rarely ever
support a rule or convention *ONLY* because it's PC.

In an ideal world, all projects would be conducted in whatever
language the *majority* of programmers use. But this is not an
ideal world, and the fact is that it's much easier to find a French
programmer that speaks English, than it is to find an American
programmer that speaks French. (To our shame.) A realistic
alternative, then, is to use English for all mixed-language
projects.

But Francis, if you start a project that will be designed and
written by French programmers, documented by French technical
writers, used by French users, and maintained by French
programmers, would you insist that they write the program in
English? If so, why?

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote <36630393.931384A1@wizard.net>...
>
>Michel Michaud wrote:
>> I'm not saying I would oppose it only that an "official committee" would
>> choose english as the base language. Are you saying that most
programmers,
>> even those whose native language is not english, would agree to use
>> only english or are you saying the contrary? Reading Stroustrup for
>
>The contrary. I'm saying that people who don't know English might object
>to the idea that they must learn English in order to write a C program.
>I think that people who already know English, but who are not fluent in
>it, might object to the idea that a program meant for use entirely
>within their own country should be written in English.
>
>> example, one could get the feelings that all important C++ programs
>> should be written in english only... I'm not sure that's what he
>> meant, but this is what he wrote (p.831):
>>
>> "A program is hard to read unless you understand the natural language
>> used for identifiers and comments. Consequently, for programs used
>> internationally it is usually best to stick to English and ASCII."
>
>Guess what? Lots of programs don't need to be used internationally. I've
>never had to write a program that needed to be understood by anyone who
>wasn't currently resident in an English-speaking country. Therefore,
>English made perfect sense as the language for variable names and
>comments. A program that would never be worked on by non-Russian
>speakers can equally well be written in Russian.

You don't have to convince me, as I think the first rule of programming
should be the programmer must understand perfectly the programs he writes.
So I do program in french (and I'm looking forward to using accentuated
characters in identifier), but do you think non english speaking
programmers will prefer learning french, german or russian words ? I
think most will prefer to perfect their english skills... But I'd
really like ViderEcran() instead of clear_screen()...

BTW I am not sure I understand your comment on Stroustrup's comment, are
you saying he is wrong or that you think this a comment that refers to
only a small number of international programs? Then why not use
Esperanto for those, it could give a new life to this language... :)

Michel Michaud micm19@removethis.mail2.cstjean.qc.ca
http://www3.sympatico.ca/michel.michaud




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote <73v298$t0u$1@nnrp1.dejanews.com>...

>In article <bdq72.1325$3C4.3148502@news20.bellglobal.com>,
>  "Michel Michaud" <micm19@removethis.mail2.cstjean.qc.ca> wrote:
>>
>> Francis Glassborow wrote:
>> >
>> > In article <9gD52.788$lW3.1529102@news20.bellglobal.com>, Michel
Michaud
>> > <micm19@removethis.mail2.cstjean.qc.ca> writes
>> I am not sure there would be many such simple function (as a
>> clear screen) that one cannot write easily, so there is no
>> real need for a standard function for most of them.

>Functions that cannot be written easily are not the issue.
>We're talking about either complex math functions, or else
>system-dependant I/O functions.

>> However I think a more formal study should be made. How
>> about a "vote" here, and a discussion, about what functions
>> (and names) should be consider? After a few weeks, we'd
>> get a better picture. Don't we have 10 years anyway?...
>>
>> For a start, I see three : clear_screen(), cursor_to(x,y)
>> and read_key()... (I have no real need for any of those
>> but from what I can see on C++ newgroups, many people
>> want them)

>A reasonable start, but consider: for function cursor_to(x,y),
>what is the minimum and maximum legal values for x and y?
>Is it screen size dependant? If so, we need a function to
>tell us the legal values. If the screen has graphics
>capabilities, do we report the screen size in characters or in
>pixels? If it's in pixels then we better provide a way to use
>them, at the very least a function like plot(x,y,color). But
>then what does this do on monochrome text-only screens? On PCs,
>the presence or absence of graphics depends on the current
>mode. Characters look better in modes that don't allow graphics.
>Do we allow the program to switch modes? What happens if the
>screen can use proportional fonts? Now each character has a
>different width. Do we provide a function to tell you the length
>in pixels of any arbitrary string? Do we support switching fonts?
>If so, do we create a list of "standard required" fonts, or do we
>add another function to enumerate the fonts available?

>You've pointed at the tip of the iceberg. To get an idea of
>how big it might be, take a look at the API for Microsoft
>Windows or X-Windows or Macintosh...

>We may have to make a choice between towing the entire iceberg
>home, or just filling up a few ice chests and hoping some people
>have their own iceberg already.

Don't think I don't see the problems, I do see them very clearly,
However as Francis Glassborow, there a number of things almost
universal that could be put in a "facultative standard" (I hope
I understand you Francis). So the discussion could well be on
what you ask (details) or, first, on the usefulness of things
we might put in this group. Do we really need a clear_screen()?
I don't think so, but having so many people asking for it
do make me think about it. The same kind of argument can be
made about any other functionality we might consider.

Michel Michaud micm19@removethis.mail2.cstjean.qc.ca
http://www3.sympatico.ca/michel.michaud



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3660C85B.19F0449D@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
>
> Michel Michaud wrote:
> ....
> > Again where would "existing practice" stops? For one, I suppose most
> > people would not even consider function names that are not english
> > words or that do not adhere to the common naming scheme of C++ (all
>
> I think there are a lot of programmers whose native language is not
> English, who would disagree with you on that.

I *am* a native English speaker. But I don't think that "itoa" or
"clrscr" are valid English words...

The i is an abbreviation for integer, and the a is an abbreviation
for ASCII, right? Even if I buy that this is obvious (I don't), or
that abbreviations are also English words (I doubt it), I say that
this type of reasoning would make "KGB" an English-language term
too! Further, someone more familiar with math than C might think
that this is a mis-spelling for "iota".

But surely it's obvious to anyone who programs on a PC that clrscr
is short for CLeaR SCReen... right? No. Even among computers that
have a screen to clear, they're not all PCs. Perhaps a better name
would be erase? ...No, that might delete files from my hard disk...

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michel Michaud wrote:
>
> James Kuyper wrote <3660C85B.19F0449D@wizard.net>...
> >
> >Michel Michaud wrote:
> >....
> >> Again where would "existing practice" stops? For one, I suppose most
> >> people would not even consider function names that are not english
> >> words or that do not adhere to the common naming scheme of C++ (all
> >
> >I think there are a lot of programmers whose native language is not
> >English, who would disagree with you on that.
>
> I'm not saying I would oppose it only that an "official committee" would
> choose english as the base language. Are you saying that most programmers,
> even those whose native language is not english, would agree to use
> only english or are you saying the contrary? Reading Stroustrup for
> example, one could get the feelings that all important C++ programs
> should be written in english only... I'm not sure that's what he
> meant, but this is what he wrote (p.831):
>
> "A program is hard to read unless you understand the natural language
> used for identifiers and comments. Consequently, for programs used
> internationally it is usually best to stick to English and ASCII."
>

My interpretation is that this reflects the simple fact that
English/ASCII
is most likely to be understood in the international community, and this
paragraph is suggesting a way that I can write a program and have a fair
number of people able to understand it.  This reflects the fact that
(say) English is the most commonly understood language in international
circles.

To support programmers whos native language is not English should be
relatively straight forward *if* the focus is simply on character sets
and keywords.  For example, if we want a German version of C++, pick
a character set that supports umlauts and things (and is probably
compatible with a German keyboard, should such a thing exist).  Then
simply translate the keywords (for, do, while, if, else, template,
exception, ...) into German.

But having done this, you've only scratched the top of an iceberg.
Some other problems to be resolved will be;

   -   how should the standard library be handled?  All current namespaces
         assume English/ASCII (albeit somewhat cryptically) for the
         names of functions.  Will we require a dedicated version of the
         STL that supports German programmers?

   -   what about multi-lingual C++?  An English programmer exchanging code
         with a German one?  The problems will be exactly the same as we have
         now.  Will we need a German C++ <-> English C++ translator?  Or an
         incredibly smart editor?  Given that there are concepts in English
         that don't map cleanly into German (and vice versa), this is far
         from trivial.  Now, consider what happens when we have Mandarin
         or Japanese versions of C++ as well.

   -   then there's the issue of vendor supplied libraries (both existing and
         in the future).  And system level API's. And ....

I don't have answers to the above.  The bottom line of all this is that we
wish our code to be understandable by future programmers who have to
maintain it.  The way that's done at the moment is to specify English/ASCII
(admittedly an imperfect solution, but better than none) and discipline by the
programmer (coding style, etc).


-<Automagically included trailer>
Robert O'Dowd                       Ph    +61 (8) 9553 3618
DSTO Bldg A51                     Fax    +61 (8) 9553 3577
HMAS Stirling                       Email:
robert.odowd@dsto.defence.gov.au
Rockingham, Western Australia, 6958

Disclaimer: Opinions above are mine and may be worth what you paid for
them


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

Michel Michaud wrote:

> James Kuyper wrote <36630393.931384A1@wizard.net>...

> >Michel Michaud wrote:
....
> >> only english or are you saying the contrary? Reading Stroustrup for
....
> >> example, one could get the feelings that all important C++ programs
                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> should be written in english only... I'm not sure that's what he
> >> meant, but this is what he wrote (p.831):
> >>
> >> "A program is hard to read unless you understand the natural language
> >> used for identifiers and comments. Consequently, for programs used
> >> internationally it is usually best to stick to English and ASCII."

> >Guess what? Lots of programs don't need to be used internationally. I've
....
> BTW I am not sure I understand your comment on Stroustrup's comment, are
> you saying he is wrong or that you think this a comment that refers to
> only a small number of international programs? Then why not use
> Esperanto for those, it could give a new life to this language... :)

I am saying that he correctly identified "programs used internationally"
as the ones for which his advice is relevant. Not "all important
programs", as you put it; that's a somewhat different set of programs.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <73vf8a$8e8$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
writes
>But surely it's obvious to anyone who programs on a PC that clrscr
>is short for CLeaR SCReen... right? No. Even among computers that
>have a screen to clear, they're not all PCs. Perhaps a better name
>would be erase? ...No, that might delete files from my hard disk...

If everyone agreed there would be no problem.  It is exactly because not
everyone agrees (and therefore the same common function can have
different names -- and different parameter orderings) that a standard
function name might be useful.

On the subject of identifiers; Mats Henricson & Erik Nyquist in
'Industrial Strength C++'  (well worth reading) have this to say:
Rec 1.2  Use English names for identifiers.
Do not use names that are difficult to understad.  Most importantly, do
not use names that are understood only by those who understand your
native language.  What does the word *bil* mean to an English or
Japanese programmer?  Not many know that it is the Swedish word for car.


Note that neither author is a native English speaker so perhaps they can
get away with what would not be PC for those whose mother tongue is some
dialect of English.


Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote <3660C85B.19F0449D@wizard.net>...
>
>Michel Michaud wrote:
>....
>> Again where would "existing practice" stops? For one, I suppose most
>> people would not even consider function names that are not english
>> words or that do not adhere to the common naming scheme of C++ (all
>
>I think there are a lot of programmers whose native language is not
>English, who would disagree with you on that.

I'm not saying I would oppose it only that an "official committee" would
choose english as the base language. Are you saying that most programmers,
even those whose native language is not english, would agree to use
only english or are you saying the contrary? Reading Stroustrup for
example, one could get the feelings that all important C++ programs
should be written in english only... I'm not sure that's what he
meant, but this is what he wrote (p.831):

"A program is hard to read unless you understand the natural language
used for identifiers and comments. Consequently, for programs used
internationally it is usually best to stick to English and ASCII."

Michel Michaud micm19@removethis.mail2.cstjean.qc.ca
http://www3.sympatico.ca/michel.michaud




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michel Michaud wrote:
>
> James Kuyper wrote <3660C85B.19F0449D@wizard.net>...
> >
> >Michel Michaud wrote:
> >....
> >> Again where would "existing practice" stops? For one, I suppose most
> >> people would not even consider function names that are not english
> >> words or that do not adhere to the common naming scheme of C++ (all
> >
> >I think there are a lot of programmers whose native language is not
> >English, who would disagree with you on that.
>
> I'm not saying I would oppose it only that an "official committee" would
> choose english as the base language. Are you saying that most programmers,
> even those whose native language is not english, would agree to use
> only english or are you saying the contrary? Reading Stroustrup for

The contrary. I'm saying that people who don't know English might object
to the idea that they must learn English in order to write a C program.
I think that people who already know English, but who are not fluent in
it, might object to the idea that a program meant for use entirely
within their own country should be written in English.

> example, one could get the feelings that all important C++ programs
> should be written in english only... I'm not sure that's what he
> meant, but this is what he wrote (p.831):
>
> "A program is hard to read unless you understand the natural language
> used for identifiers and comments. Consequently, for programs used
> internationally it is usually best to stick to English and ASCII."

Guess what? Lots of programs don't need to be used internationally. I've
never had to write a program that needed to be understood by anyone who
wasn't currently resident in an English-speaking country. Therefore,
English made perfect sense as the language for variable names and
comments. A program that would never be worked on by non-Russian
speakers can equally well be written in Russian.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <bdq72.1325$3C4.3148502@news20.bellglobal.com>,
  "Michel Michaud" <micm19@removethis.mail2.cstjean.qc.ca> wrote:
>
> Francis Glassborow wrote:
> >
> > In article <9gD52.788$lW3.1529102@news20.bellglobal.com>, Michel Michaud
> > <micm19@removethis.mail2.cstjean.qc.ca> writes
> > >But seriously, why was this line of thinking never proposed? I would
> > >guess because it would take forever to decide where to stop adding
> > >optional functions, after a few thousands it would be really
> > >uninteresting. For example, simply add all existing non standard
> > >functions from major compiler vendors and say this is the way they
> > >should work from now on, would this accomplish anything?
> >
> > But there is something about standardising existing practice.  Quite a
>
> Again where would "existing practice" stops? For one, I suppose most
> people would not even consider function names that are not english
> words or that do not adhere to the common naming scheme of C++ (all
> lowercase), etc. But by changing function names from existing practice
> it would cease being common practice.
>
> > few functions are common (such as your clrscrn) across many platforms
> > but are not in the standard because they cannot sensibly be implemented
> > by everyone.
>
> I am not sure there would be many such simple function (as a
> clear screen) that one cannot write easily, so there is no
> real need for a standard function for most of them.

Functions that cannot be written easily are not the issue.
We're talking about either complex math functions, or else
system-dependant I/O functions.

> However I think a more formal study should be made. How
> about a "vote" here, and a discussion, about what functions
> (and names) should be consider? After a few weeks, we'd
> get a better picture. Don't we have 10 years anyway?...
>
> For a start, I see three : clear_screen(), cursor_to(x,y)
> and read_key()... (I have no real need for any of those
> but from what I can see on C++ newgroups, many people
> want them)

A reasonable start, but consider: for function cursor_to(x,y),
what is the minimum and maximum legal values for x and y?
Is it screen size dependant? If so, we need a function to
tell us the legal values. If the screen has graphics
capabilities, do we report the screen size in characters or in
pixels? If it's in pixels then we better provide a way to use
them, at the very least a function like plot(x,y,color). But
then what does this do on monochrome text-only screens? On PCs,
the presence or absence of graphics depends on the current
mode. Characters look better in modes that don't allow graphics.
Do we allow the program to switch modes? What happens if the
screen can use proportional fonts? Now each character has a
different width. Do we provide a function to tell you the length
in pixels of any arbitrary string? Do we support switching fonts?
If so, do we create a list of "standard required" fonts, or do we
add another function to enumerate the fonts available?

You've pointed at the tip of the iceberg. To get an idea of
how big it might be, take a look at the API for Microsoft
Windows or X-Windows or Macintosh...

We may have to make a choice between towing the entire iceberg
home, or just filling up a few ice chests and hoping some people
have their own iceberg already.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <9gD52.788$lW3.1529102@news20.bellglobal.com>, Michel Michaud
> <micm19@removethis.mail2.cstjean.qc.ca> writes
> >But seriously, why was this line of thinking never proposed? I would
> >guess because it would take forever to decide where to stop adding
> >optional functions, after a few thousands it would be really
> >uninteresting. For example, simply add all existing non standard
> >functions from major compiler vendors and say this is the way they
> >should work from now on, would this accomplish anything?
>
> But there is something about standardising existing practice.  Quite a

Again where would "existing practice" stops? For one, I suppose most
people would not even consider function names that are not english
words or that do not adhere to the common naming scheme of C++ (all
lowercase), etc. But by changing function names from existing practice
it would cease being common practice.

> few functions are common (such as your clrscrn) across many platforms
> but are not in the standard because they cannot sensibly be implemented
> by everyone.

I am not sure there would be many such simple function (as a
clear screen) that one cannot write easily, so there is no
real need for a standard function for most of them.

However I think a more formal study should be made. How
about a "vote" here, and a discussion, about what functions
(and names) should be consider? After a few weeks, we'd
get a better picture. Don't we have 10 years anyway?...

For a start, I see three : clear_screen(), cursor_to(x,y)
and read_key()... (I have no real need for any of those
but from what I can see on C++ newgroups, many people
want them)

--
Michel Michaud (micm19@removethis.mail2.cstjean.qc.ca)
http://www3.sympatico.ca/michel.michaud



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> David R Tribble wrote:
> > ...
> > I'm still irritated that I can't declare ctor or dtor functions
> > with return types.
>
> James Kuyper wrote:
> > How exactly would you imagine using them? As the language stands,
> > there's no way to retrieve the value that would be returned by a ctor.
> > A dtor would be a little easier.
>
> Here's how you invoke a ctor explicitly:
>     foo(Type());       // Calls Type::Type() for a temp object
>
> Here's how you invoke a dtor explicitly:
>     obj.~Type();       // Calls Type::~Type() for obj
>
> Constructors don't "return" an object; on the other hand, they
> might be considered to "return" their 'this' object when invoked to

More accurately, they return something akin to (Type&)*this.

> create temporary values (as shown above).  Thus it makes sense to
> declare the ctor for class 'Type' as returning a 'Type' or 'Type&'.

But the only point to doing so would be to provide a return type other
than Type&. That would be a very bad idea; it would invalidate most
explicit uses of ctors. Not permitting a return type, protects you from
giving the wrong type; not requiring a return type saves some typing.

....
> reaching consequences.  I'm just complaining that it wasn't there
> from the beginning, and that the lack of explicit return types for
> ctor/dtor functions is an inconsistency in the language.

ctors and dtors serve purposes fundamentally different from other member
functions; it's appropriate for them to have different rules.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michel Michaud wrote:
....
> Again where would "existing practice" stops? For one, I suppose most
> people would not even consider function names that are not english
> words or that do not adhere to the common naming scheme of C++ (all

I think there are a lot of programmers whose native language is not
English, who would disagree with you on that.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jeff Haas wrote:
>
> In article <365A32F6.BA86C8C2@wizard.net>, James Kuyper
> <kuyper@wizard.net> wrote:
> >David R Tribble wrote:
> >> I'm still irritated that I can't declare ctor or dtor functions
> >> with return types.
> >
> >How exactly would you imagine using them? As the language stands,
> >there's no way to retrieve the value that would be returned by a ctor. A
> >dtor would be a little easier.
>
> Seems to me to be the other way around.  I can easily see something like:
>
> int whatever = ( MyClass objectOfMyclass(45, "OtherArgs") );

You're giving a declaration a value. Normally only expressions have
values. That is a major change to the language.

> So the parentheses make it a little awkward, perhaps there is another way
> to do it.  (You asked for an example, not a *good* example ;)  )
>
> What I don't see is how you'd get a value from the d'tor, since there is
> no place you actually call a d'tor.

? I believe the following is legal code (assuming that T has an
accessible default constructor):

 T t;
 t.~T();

Of course, you must follow it with something like the following before
leaving the scope of 't', in order to avoid calling the dtor twice
without an intervening call to the ctor (assuming T has an accessible
copy constructor):

 new(&t) T(t2);



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <jhaas1-2411980854290001@neih069.unl.edu>,
  jhaas1@bigred.unl.edu (Jeff Haas) wrote:

[Hypothetical example of how constructors could return values]

> What I don't see is how you'd get a value from the d'tor, since there is
> no place you actually call a d'tor.

As someone recently pointed out to me, delete and delete[] are
operators, not statements. The operators always return void,
of course, but we could extend that.

    class Counter {
        int count;
    public:
        Counter(int i=0) : count(i) {}
        void tick() { ++count; }
        int ~Counter() { return count; }
    };
Here the destructor returns an int.
    int main() {
        Counter *c = new Counter(5);
        c.tick(); c.tick();
        std::cout << (delete c) << std::endl;
        return 0;
    }
This program would print "7" on standard output.

> Personally, I'm not sure just how useful it would be to return from c'tor
> and d'tors, but I'd like to see what everyone thinks.

I'm not sure either. I just point out that it's possible.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3659CDE6.5007@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:

> I'm still irritated that I can't declare ctor or dtor functions
> with return types.

The way I look at it, the ctor is all return type and no name.
In fact, wording in the standard supports this view:

    12.1 Constructors

    1   Constructors do not have names. ...

Of course, if this is true, then out-of-line constructors and
destructors have rather bizarre syntax:
    myClass::myClass(int arg1, ...) { /* ... */ }
    myClass::~myClass() { /* ... */ }
It would make more sense to move the class name qualifier to
just before the argument list, which is where the name would
be if only they had names:
    myClass myClass::(int arg1, ...) { /* ... */ }
    myClass myClass::~() { /* ... */ }
Not that I'm advocating a switch to this syntax; I just say that
it seems more natural.

But maybe I misunderstood *WHY* you would want to specify the
return value. You wouldn't want to return any other type, would
you? For instance, have the myClass constructor return an int?
    int i = myClass(1,2,3);
If so, what you really want is a function.
    int myFunc(int arg1,...);

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 26 Nov 1998 00:04:57 GMT, AllanW@my-dejanews.com
>  jhaas1@bigred.unl.edu (Jeff Haas) wrote:

>> Personally, I'm not sure just how useful it would be to return from c'tor
>> and d'tors, but I'd like to see what everyone thinks.

>I'm not sure either. I just point out that it's possible.

If ctors returned values, you couldn't create unnamed objects to do
useful things.  Example:
   cout << Date("26nov1998").weekday() << '\n';
wouldn't work anymore as Date("26nov1998") might return something,
like an error code, to which weekday() can't be applied.

Dtors could return values, but if ctors can't, then perhaps dtors
shouldn't be able to do so either.  Of course, the parallel structure
between ctors and dtors is not perfect.  For example, you can call
a dtor on an object, but you can't call a ctor on it.

Anyway, since the object goes out of scope, conceptually, any values
in it must cease to exist.  So, conceptually speaking, it shouldn't
return anything.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
> ...
> I'm still irritated that I can't declare ctor or dtor functions
> with return types.

James Kuyper wrote:
> How exactly would you imagine using them? As the language stands,
> there's no way to retrieve the value that would be returned by a ctor.
> A dtor would be a little easier.

Here's how you invoke a ctor explicitly:
    foo(Type());       // Calls Type::Type() for a temp object

Here's how you invoke a dtor explicitly:
    obj.~Type();       // Calls Type::~Type() for obj

Constructors don't "return" an object; on the other hand, they
might be considered to "return" their 'this' object when invoked to
create temporary values (as shown above).  Thus it makes sense to
declare the ctor for class 'Type' as returning a 'Type' or 'Type&'.
It wouldn't hurt to allow a ctor to contain 'return *this'
statements, either.

Destructors don't return a value at all, even when invoked
explicitly.  Thus it makes sense to declare dtors as returning
'void'.  It's already legal for a dtor to contain simple 'return'
statements, just like real void functions.

Example:
    class Type
    {
    public:
        Type    Type();
      //or:
        Type &  Type();

        void    ~Type();
    };

Requiring ctor and dtor functions to be declared with explicit
return types closes a syntactical hole in the language, namely,
that *every* function must now be declared with an explicit return
type.  This simplifies the grammar somewhat, too.

But, of course, it would be foolish to suggest that I want this
considered as a serious change to the language.  It's much too
late for such a far-reaching, code-breaking change as this.
Even making this an optional part of the grammar would have far-
reaching consequences.  I'm just complaining that it wasn't there
from the beginning, and that the lack of explicit return types for
ctor/dtor functions is an inconsistency in the language.

-- David R. Tribble, dtribble@technologist.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <365A32F6.BA86C8C2@wizard.net>, James Kuyper
<kuyper@wizard.net> wrote:
>David R Tribble wrote:
>> I'm still irritated that I can't declare ctor or dtor functions
>> with return types.
>
>How exactly would you imagine using them? As the language stands,
>there's no way to retrieve the value that would be returned by a ctor. A
>dtor would be a little easier.

Seems to me to be the other way around.  I can easily see something like:

int whatever = ( MyClass objectOfMyclass(45, "OtherArgs") );

So the parentheses make it a little awkward, perhaps there is another way
to do it.  (You asked for an example, not a *good* example ;)  )

What I don't see is how you'd get a value from the d'tor, since there is
no place you actually call a d'tor.

Personally, I'm not sure just how useful it would be to return from c'tor
and d'tors, but I'd like to see what everyone thinks.

Jeff
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

  I think that some way of specifiing the attributes in C++ should be
standartized and than the meaning of general attibutes should be
standartized. After that futher minor extensions to C++ can be made via
attributes. "override" is one of them. I think compiler writers should be
allowed not to implement the proposed attributes. Again, a lot of useful
semantic information can be specified via attributes, making C++ more
programmer-friendly.

PS: I have mailed this message 20.11.98, but i don't see it in this thread
(25.11.98) so i decided to resend it. May be something with my newsreader or
news server.
  I'm sorry if it's a duplicate.
- Vlad
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

henk.devos@dzine.be wrote:
[...]
> I would propose to solve this be adding a new C++ keyword : "override".
> When you declare a function as override, you say that you intend to override a
> base class function.
[...]

The funny thing is that there's ALMOST something like this in C++: "using".
I propose that instead of adding a new keyword, the behavior of "using" would
be expanded to allow:


class Derived : public Base
{
  using void Base::f( const char * );
  virtual void f( const char * p )
    {
    //...
    }
}

(Currently, "using" can only say "Base::f", which is only half of what you
need.)


--------------------------------
Ziv Caspi
zivca@netvision.net.il


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote ...
>This is an idea I like.  I have long wanted a kind of optional
>'standard' by which I mean things that are not required to be
>implemented but if they are they must be done in a specified way. For
>example, raw keyboard input.  Choose a function name to do this and
>invite implementers to use it if they want to provide that functionality

Yes and don't forget a clear screen function, sure would save a lot of
post in newsgroups...

But seriously, why was this line of thinking never proposed? I would
guess because it would take forever to decide where to stop adding
optional functions, after a few thousands it would be really
uninteresting. For example, simply add all existing non standard
functions from major compiler vendors and say this is the way they
should work from now on, would this accomplish anything?

Michel Michaud micm19@removethis.mail2.cstjean.qc.ca
http://www3.sympatico.ca/michel.michaud





[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka wrote:
...
> What he wants is a _new_ keyword, wich tells the compiler
> "Hey, I intend to *override* a base class method. If I actually
> don't do that, I've made a mistake, so tell me about that."
>
> This can work, since this keyword would be orthogonal to
> virtual (although all correct override functions would be
> virtual due to the feature that the overrider of a virtual
> member function is automatically virtual, even if you don't
> say it explicitly; if that rule were changed - resulting
> in a modified-C++ equivalent to Javas final methods - the
> orthogonality of the two concepts would be obvious).

Then how about '~virtual'?  ;-)

    class Base
    {
    public:
        int             maybe();     // May or may not override
        virtual int     may();       // May override
        virtual int     must() = 0;  // Must override
        ~virtual int    cannot();    // Must not override
        ~virtual int    bogus() = 0; // Illegal
    };

Of course, '~virtual' reads like "not virtual" which is a tad bit
confusing, although probably no more so than "virtual inheritance".

Bill Wade <bill.wade@stoner.com> wrote:
> ... I'm not at all sure I'd use 'overload' [sic] even if it were
> available.

I'm not sure I would use 'override' (or 'overload') either.
I'm still irritated that I can't declare ctor or dtor functions
with return types.

-- David R. Tribble, dtribble@technologist.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <9gD52.788$lW3.1529102@news20.bellglobal.com>, Michel Michaud
<micm19@removethis.mail2.cstjean.qc.ca> writes
>But seriously, why was this line of thinking never proposed? I would
>guess because it would take forever to decide where to stop adding
>optional functions, after a few thousands it would be really
>uninteresting. For example, simply add all existing non standard
>functions from major compiler vendors and say this is the way they
>should work from now on, would this accomplish anything?

But there is something about standardising existing practice.  Quite a
few functions are common (such as your clrscrn) across many platforms
but are not in the standard because they cannot sensibly be implemented
by everyone.



Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
....
> I'm still irritated that I can't declare ctor or dtor functions
> with return types.

How exactly would you imagine using them? As the language stands,
there's no way to retrieve the value that would be returned by a ctor. A
dtor would be a little easier.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <lB0MMiAE0yU2Ewl7@robinton.demon.co.uk>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In article <3652E03F.167E@wizard.net>, James Kuyper <kuyper@wizard.net>
>writes
>>I think that a misspelled overrider could be a very tricky thing to test
>>for. By definition, there is a function that it overrides, which might
>>by chance perform a task not easily distiguished from the correct task.
>
>If you cannot test for it how does it matter?

It might do the job but take more time.

Even though it is difficult to time functions (resolution of clocks,
caches, randomized algorithms, etc) this does not mean
that the time to execute a function doesn't matter.
--
// Home page  http://www.dna.lth.se/home/Hans_Olsson/
// Email To..Hans.Olsson@dna.lth.se [Please no junk e-mail]
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote in message ...
>If you cannot test for it how does it matter?
>
>All code should have test harnesses that exercise the code.  These
>should be simple and an inherent part of the development process.

Of course we know that the use of 'All' is flame-bait, but I'll bite.

I like the principle, but in practice there are plenty of valid exceptions.

Should a student spend time writing a test harness for his homework
assignment, or do something more productive like studying for his philosophy
exam or going out on a date?

Most of the time I don't write test harnesses for my test harnesses, even if
they're written in C++.

The more likely it is that the compiler will catch a simple typo, the less
likely that my test harness will have a stupid 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

  I think that some way of specifiing the attributes in C++ should be
standartized and than the meaning of general attibutes should be
standartized. After that futher minor extensions to C++ can be made via
attributes. "override" is one of them. I think compiler writers should be
allowed not to implement the proposed attributes. Again, a lot of useful
semantic information can be specified via attributes, making C++ more
programmer-friendly.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <73279r$8sv$1@uuneo.neosoft.com>, Bill Wade
<bill.wade@stoner.com> writes
>The more likely it is that the compiler will catch a simple typo, the less
>likely that my test harness will have a stupid error.

True, but I worry when programmers come to rely on the compiler as there
only tool.

BTW, teaching students to write a test harness for their homework would
be no bad thing.  I expect all atendees at my training courses to write
a test harness for every class they define/implement.  Actually I expect
them to provide regression tests to be applied as the further develop a
class to ensure that earlier behaviour is left unchanged.


Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3655d8f6.0@monster.ssau.ru>, Vlad Harchev
<vladhar@imimail.ssau.ru> writes
>  I think that some way of specifiing the attributes in C++ should be
>standartized and than the meaning of general attibutes should be
>standartized. After that futher minor extensions to C++ can be made via
>attributes. "override" is one of them. I think compiler writers should be
>allowed not to implement the proposed attributes. Again, a lot of useful
>semantic information can be specified via attributes, making C++ more
>programmer-friendly.

This is an idea I like.  I have long wanted a kind of optional
'standard' by which I mean things that are not required to be
implemented but if they are they must be done in a specified way. For
example, raw keyboard input.  Choose a function name to do this and
invite implementers to use it if they want to provide that functionality




Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3652E03F.167E@wizard.net>, James Kuyper <kuyper@wizard.net>
writes
>I think that a misspelled overrider could be a very tricky thing to test
>for. By definition, there is a function that it overrides, which might
>by chance perform a task not easily distiguished from the correct task.

If you cannot test for it how does it matter?

All code should have test harnesses that exercise the code.  These
should be simple and an inherent part of the development process.


Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36509C15.446B@wizard.net>, James Kuyper <kuyper@wizard.net>
writes
>There's one kind of problem that such code analysis tools couldn't
>possibly detect without the help of something like the suggested
>'override' keyword: misspelling the name of the overrider, so that it
>isn't recognised as one.

True, but any respectable test should.  If you do not test that the
correct function is called then you are taking unnecessary risks.



Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <36509C15.446B@wizard.net>, James Kuyper <kuyper@wizard.net>
> writes
> >There's one kind of problem that such code analysis tools couldn't
> >possibly detect without the help of something like the suggested
> >'override' keyword: misspelling the name of the overrider, so that it
> >isn't recognised as one.
>
> True, but any respectable test should.  If you do not test that the
> correct function is called then you are taking unnecessary risks.

I think that a misspelled overrider could be a very tricky thing to test
for. By definition, there is a function that it overrides, which might
by chance perform a task not easily distiguished from the correct task.

In any event, problems that are detected at compiler time can be fixed a
lot cheaper than ones that are detected during testing.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3647CBCA.B3BD841D@acm.org>, Pete Becker <petebecker@acm.org> wrote:

>class Base
>{
>public:
>        virtual void f(int);
>};
>
>class Derived : public Base
>{
>public:
>        void f(char *);
>};
>
>int main()
>{
>Derived d;
>d.f(1);
>return 0;
>}
>
>The attempted call to f(1) in main is illegal: f is not overloaded,
>because the two declarations are not in the same scope. This is a case
>where most compilers (every one that I've used) will give you a warning.

The example given is not the best illustration of when the override
keyword would be useful.  There are several related examples where it
provides a benefit that cannot be achieved in other ways, however.  I once
spent a long time trying to figure out why my code no longer worked after
a library update before I discovered that a base class method which had
been virtual in the previous version of the library had been made
non-virtual in this version, and so my override was not being called.  A
more common use is for catching typos, spelling errors, and other function
name snafus.  The compiler will happily let me declare a virtual method
named Basefunc(), but if I really intended to override BaseFunc() then I
won't find out about my mistake until I get into the debugger.  Having an
override keyword would catch any of these programmer errors at
compile-time, which would have saved me some debugging time over the
years.  As others have mentioned, override would be optional just as
virtual is in derived classes, so there would be no impact on existing
code.

In addition to its error-catching features, an override keyword also has
explanatory value.  Consider the following class declaration:

class Derived : public Base {
public:
   void f1();           // virtual?, declared in base?
   virtual void f2();   // virtual, declared in base?
   override void f3();  // virtual, declared in base
};

This sounds like a good usage.  It still would call for no changes
in the language if compilers would warn that a function
having the same name as a virtual function in the base class
did not also have the virtual keyword in its declaration
[even though that keyword is not required in the derived class].
The compiler should also warn when a derived function declared
virtual is named the same as a function in the base class, and that
function was not declared virtual.

I've had to make the same discoveries in the debugger, unfortunately.
"Ohhhh, I forgot to declare the damned thing virtual in the base class."

And then you have Visual C++ 6.0......

Chris

Kirk Swenson wrote:

> The example given is not the best illustration of when the override
> keyword would be useful.  There are several related examples where it
> provides a benefit that cannot be achieved in other ways, however.  I once
> spent a long time trying to figure out why my code no longer worked after
> a library update before I discovered that a base class method which had
> been virtual in the previous version of the library had been made
> non-virtual in this version, and so my override was not being called.
>

--
Chris Ahlstrom
major league software, llc
1259 Center Lake Dr.
Mt. Pleasant, SC 29464-7419
(843)849-0985
a h l s t r o c @bellsouth.net

They don't let Bill Gates code anymore.




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Kirk Swenson wrote:

> In article <3647CBCA.B3BD841D@acm.org>, Pete Becker <petebecker@acm.org> wrote:

> >class Base
> >{
> >public:
> >        virtual void f(int);
> >};
> >
> >class Derived : public Base
> >{
> >public:
> >        void f(char *);
> >};
> >
> >int main()
> >{
> >Derived d;
> >d.f(1);
> >return 0;
> >}
> >
> >The attempted call to f(1) in main is illegal: f is not overloaded,
> >because the two declarations are not in the same scope. This is a case
> >where most compilers (every one that I've used) will give you a warning.

> The example given is not the best illustration of when the override
> keyword would be useful.

It was not intended to be. In the part that you snipped the original
poster claimed that this was an example of overloading, and the example
illustrates that this is not so.

--
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <364DB4A3.F46E66D7@bellsouth.net>, Chris Ahlstrom
<ahlstroc@bellsouth.net> writes
>This sounds like a good usage.  It still would call for no changes
>in the language if compilers would warn that a function
>having the same name as a virtual function in the base class
>did not also have the virtual keyword in its declaration
>[even though that keyword is not required in the derived class].
>The compiler should also warn when a derived function declared
>virtual is named the same as a function in the base class, and that
>function was not declared virtual.

So what you want is that we do not declare over-riders of virtuals as
virtual so you will get a warning?  Or do you want a warning if a
function declared virtual in a derived does not over-ride a base class
virtual.  Either way I think it does not work.

Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <364DB4A3.F46E66D7@bellsouth.net>, Chris Ahlstrom
> <ahlstroc@bellsouth.net> writes
> >This sounds like a good usage.  It still would call for no changes
> >in the language if compilers would warn that a function
> >having the same name as a virtual function in the base class
> >did not also have the virtual keyword in its declaration
> >[even though that keyword is not required in the derived class].
> >The compiler should also warn when a derived function declared
> >virtual is named the same as a function in the base class, and that
> >function was not declared virtual.
>
> So what you want is that we do not declare over-riders of virtuals as
> virtual so you will get a warning?  Or do you want a warning if a
> function declared virtual in a derived does not over-ride a base class
> virtual.  Either way I think it does not work.

What he wants is a _new_ keyword, wich tells the compiler
"Hey, I intend to *override* a base class method. If I actually
don't do that, I've made a mistake, so tell me about that."

This can work, since this keyword would be orthogonal to
virtual (although all correct override functions would be
virtual due to the feature that the overrider of a virtual
member function is automatically virtual, even if you don't
say it explicitly; if that rule were changed - resulting
in a modified-C++ equivalent to Javas final methods - the
orthogonality of the two concepts would be obvious).

"" (non-virtual) means "I want not to be able to be overridden".
"virtual" means "I want to be able to be overridden".
"virtual = 0" (pure virtual) means "I want to be overridden".

"" means "I want to be able to override" (That's all we have now)
"override" would mean "I want to override".
There's no "I want not to be able to override". (This, too,
could be an interesting option - it could protect derived
classes from later addition of virtual members to base classes)
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <kswenson-1311981021550001@jellybean2.keypress.com>, Kirk
Swenson <kswenson@keypress.com> writes
>I think these are clear benefits of an override keyword.  I would not
>expect implementation to be very difficult.  I'm not sure how to measure
>the cost of increasing the complexity of the language by adding a new
>keyword against the benefits of the new keyword.  At the very least I
>think it merits discussion when the next revision of the language is
>considered.

I really do not think that the benefits merit the work.  Respectable
source code analysis tools should detect the kind of problems you had.

(I would expect such tools to spot apparent virtual over-riders which
have not been declared virtual in the base class (it isn't very
difficult to do).

We should keep a clear distinction between adding to the expressive
power of the language and adding features to try to make compilers do
everything.


Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote in message ...

>I really do not think that the benefits merit the work.  Respectable
>source code analysis tools should detect the kind of problems you had.
>
>(I would expect such tools to spot apparent virtual over-riders which
>have not been declared virtual in the base class (it isn't very
>difficult to do).


I think the more valuable use is in detecting typo's.  I intended to
override fuzzbomb(), but I named my overriding function fuzbomb().  I get no
compiler error or link error, just wrong runtime behavior.  An analysis tool
(or even a linker) can tell me that fuzbomb() is never called, but most
programs see many declarations of functions which are never called.

Virtual function overrides and overloaded function names are the two places
in C++ where a typo in a declaration/definition are not likely to be caught
by the compiler or linker.

Having said all that, I'm not at all sure I'd use 'overload' even if it were
available.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <kswenson-1311981021550001@jellybean2.keypress.com>, Kirk
> Swenson <kswenson@keypress.com> writes
> >I think these are clear benefits of an override keyword.  I would not
> >expect implementation to be very difficult.  I'm not sure how to measure
> >the cost of increasing the complexity of the language by adding a new
> >keyword against the benefits of the new keyword.  At the very least I
> >think it merits discussion when the next revision of the language is
> >considered.
>
> I really do not think that the benefits merit the work.  Respectable
> source code analysis tools should detect the kind of problems you had.
>
> (I would expect such tools to spot apparent virtual over-riders which
> have not been declared virtual in the base class (it isn't very
> difficult to do).

There's one kind of problem that such code analysis tools couldn't
possibly detect without the help of something like the suggested
'override' keyword: misspelling the name of the overrider, so that it
isn't recognised as one.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <72prns$kgt$1@uuneo.neosoft.com>,
  "Bill Wade" <bill.wade@stoner.com> wrote:
> Francis Glassborow wrote in message ...

> >I really do not think that the benefits merit the work.  Respectable
> >source code analysis tools should detect the kind of problems you had.
> >
> >(I would expect such tools to spot apparent virtual over-riders which
> >have not been declared virtual in the base class (it isn't very
> >difficult to do).
>
> I think the more valuable use is in detecting typo's.  I intended to
> override fuzzbomb(), but I named my overriding function fuzbomb().  I get no
> compiler error or link error, just wrong runtime behavior.  An analysis tool
> (or even a linker) can tell me that fuzbomb() is never called, but most
> programs see many declarations of functions which are never called.

> Virtual function overrides and overloaded function names are the two places
> in C++ where a typo in a declaration/definition are not likely to be caught
> by the compiler or linker.

> Having said all that, I'm not at all sure I'd use 'overload' even if it were
> available.

Now that's an interesting slip. The proposed new keyword "override"
does indeed look extremely similar to the old former-keyword "overload."
And their uses are even vaguely similar; overload used to be required
for any overloaded function, while override would be used for member
functions that happen to overload an existing virtual function.
If the proposal is adopted, I'm sure that Bill isn't the last one
that will make that mistake.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>
> On 05 Nov 98 23:33:52 GMT, henk.devos@dzine.be <henk.devos@dzine.be> wrote:
>
> >class base
> >{
> >public:
> >    virtual void f(const char *p);
> >};
> >
> >class derived : public base
> >{
> >public:
> >    virtual override void f(char *p);
> >};
>
> But you lose type some type safety this way.  When calling the func f
> through a pointer/reference to a base, the arg of f had better be
> a "const char *".  Eg,

If you look at his message again, you'll see that the 'override' keyword
wouldn't make the code legal. What it does is inform the compiler that
derived::f was intended to be an override of base::f, provoking a
diagnostic if override doesn't qualify as one. In addition to type
mis-matches, it would also improve the identification of spelling
mistakes. I like any feature which improves the compiler's ability to
detect my mistakes - I make far too many of them.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran <sbnaran@localhost.localdomain> writes:

> On 05 Nov 98 23:33:52 GMT, henk.devos@dzine.be <henk.devos@dzine.be> wrote:
>
> >class base
> >{
> >public:
> >    virtual void f(const char *p);
> >};
> >
> >class derived : public base
> >{
> >public:
> >    virtual override void f(char *p);
> >};
>
> But you lose type some type safety this way.

No, override never _causes_ functions to override other
functions. It just makes some programs ill-formed. Note that
I have proposed that here some time ago. See:

http://www.eleves.ens.fr:8080/home/bonnard/evol/override.html

Also there migth be another use of override:

void Base1::foo (int) { }
void Base2::foo (int) { }
void Der::foo (int) overrides Base1::foo

to choose which function is overriden.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I think you're wrong about that. As I understand it, "virtual" means only
"can be overridden in a derived class", without the "but..." part. In my
opinion, a compiler should not generate a warning when overloading a function
that already exists in a base class. This is perfectly legal and it is even
very important that you should be able to do that. I for one do use a
"#define PURE_VIRTUAL =0", which I would not substitute by a keyword because
there is a good alternative, namely my define. However, there is no
alternative for the proposed "override" keyword. In no way can I express my
intent to override a base class function. It would not require a lot of code
to be rewritten, because you can omit the keyword "override", just as you can
omit "virtual" in the derived class if the base class function is already
virtual.

In article <3644654A.ABE03ABC@bellsouth.net>,
  kisov@bellsouth.net wrote:

> Besides, the compiler would have to specifically analyze what's going on
> when it sees the keyword "override", and some compilers already do that
> when the see the keyword "virtual".   "virtual" means "can be overridden
> in a derived class, but not overloaded", whereas as "override" would
> mean "virtual, and I'm definitely overriding it in this derived class".
>
> That sounds like a tiny increment in help to the programmer, and adding
> it would require a lot of code to be edited, unless "override" was made
> superfluous.
>
> Myself, I'd kinda like to see "pure" as a synonym for "= 0" in a class
> member function declaration.  But I haven't even made a #define for
> that, since it isn't too big a deal.


> Francis Glassborow wrote:

> > >I would propose to solve this be adding a new C++ keyword : "override".
> > >When you declare a function as override, you say that you intend to
> > >override a base class function.
> >
> > This is a QoI matter.  Even if your compiler does not warn you about
> > such dubious code your other static analysis tools (you do use other
> > code checking tools?) should.
> >
> > New keywords should only be introduced to do things that cannot be done
> > otherwise.

[ moderator's note: excessive quoting deleted. Please trim included
  material to include only what is necessary. -sdc ]



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

henk.devos@dzine.be wrote:
>
> I think you're wrong about that. As I understand it, "virtual" means only
> "can be overridden in a derived class", without the "but..." part. In my
> opinion, a compiler should not generate a warning when overloading a function
> that already exists in a base class. This is perfectly legal and it is even
> very important that you should be able to do that.

class Base
{
public:
 virtual void f(int);
};

class Derived : public Base
{
public:
 void f(char *);
};

int main()
{
Derived d;
d.f(1);
return 0;
}

The attempted call to f(1) in main is illegal: f is not overloaded,
because the two declarations are not in the same scope. This is a case
where most compilers (every one that I've used) will give you a warning.

--
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <71suvk$4fp$1@nnrp1.dejanews.com>, henk.devos@dzine.be writes
>It is clear that I actually wanted to override base::f in derived::f, but the
>signature is not the same. The derived::f will be regarded a new virtual
>function for derived instead of an override. However, the compiler can
>impossibly know that. Everything will compile correctly but the result will
>not be as desired.
>
>I would propose to solve this be adding a new C++ keyword : "override".
>When you declare a function as override, you say that you intend to override a
>base class function.

This is a QoI matter.  Even if your compiler does not warn you about
such dubious code your other static analysis tools (you do use other
code checking tools?) should.

New keywords should only be introduced to do things that cannot be done
otherwise.

Francis Glassborow      Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Nov  6, 1998, sbnaran@localhost.localdomain (Siemel Naran) wrote:

> On 05 Nov 98 23:33:52 GMT, henk.devos@dzine.be <henk.devos@dzine.be> wrote:

>> class base { public: virtual void f(const char *p); };
>>
>> class derived : public base { public:
>>   virtual override void f(char *p); };

> But you lose type some type safety this way.

Nope; the suggestion was for the compiler to emit an error, not to
accept that as an actual overrider.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:oliva@gnu.org mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn6v44ib.plj.sbnaran@localhost.localdomain>,
  sbnaran@KILL.uiuc.edu wrote:
 > On 05 Nov 98 23:33:52 GMT, henk.devos@dzine.be <henk.devos@dzine.be> wrote:
 >
 > >class base
 > >{
 > >public:
 > >    virtual void f(const char *p);
 > >};
 > >
 > >class derived : public base
 > >{
 > >public:
 > >    virtual override void f(char *p);
 > >};
 >
 > But you lose type some type safety this way.  When calling the func f
 > through a pointer/reference to a base, the arg of f had better be
 > a "const char *".  Eg,
 >
 > void function(base * b)
 > {
 >      const char u='u';
 >      b->f(&u); // from signature, we are assured that u will not change!
 >      // but derived::f(char *) may try to change u!
 > }

That's not what I meant. When using the override keyword, the compiler should
generate an error if the signature is not correct.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> On 05 Nov 98 23:33:52 GMT, henk.devos@dzine.be <henk.devos@dzine.be> wrote:

> >class base
> >{
> >public:
> >    virtual void f(const char *p);
> >};

> >class derived : public base
> >{
> >public:
> >    virtual override void f(char *p);
> >};

In article <slrn6v44ib.plj.sbnaran@localhost.localdomain>,
  sbnaran@KILL.uiuc.edu wrote:
> But you lose type some type safety this way.  When calling the func f
> through a pointer/reference to a base, the arg of f had better be
> a "const char *".  Eg,

Henks knew this -- reread the original post. Henks went on to explain
a proposed language change which would have caught this error.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Besides, the compiler would have to specifically analyze what's going on
when it sees the keyword "override", and some compilers already do that
when the see the keyword "virtual".   "virtual" means "can be overridden
in a derived class, but not overloaded", whereas as "override" would
mean "virtual, and I'm definitely overriding it in this derived class".

That sounds like a tiny increment in help to the programmer, and adding
it would require a lot of code to be edited, unless "override" was made
superfluous.

Myself, I'd kinda like to see "pure" as a synonym for "= 0" in a class
member function declaration.  But I haven't even made a #define for
that, since it isn't too big a deal.

Chris

Francis Glassborow wrote:

> >I would propose to solve this be adding a new C++ keyword : "override".
> >When you declare a function as override, you say that you intend to override a
> >base class function.
>
> This is a QoI matter.  Even if your compiler does not warn you about
> such dubious code your other static analysis tools (you do use other
> code checking tools?) should.
>
> New keywords should only be introduced to do things that cannot be done
> otherwise.
>

Chris Ahlstrom
major league software, llc
1259 Center Lake Dr.
Mt. Pleasant, SC 29464-7419
(843)849-0985
a h l s t r o c @bellsouth.net

They don't let Bill Gates code anymore.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Suppose I write the following code:

class base
{
public:
    virtual void f(const char *p);
};

class derived : public base
{
public:
    virtual void f(char *p);
};

It is clear that I actually wanted to override base::f in derived::f, but the
signature is not the same. The derived::f will be regarded a new virtual
function for derived instead of an override. However, the compiler can
impossibly know that. Everything will compile correctly but the result will
not be as desired.

I would propose to solve this be adding a new C++ keyword : "override".
When you declare a function as override, you say that you intend to override a
base class function.

I would thus write the following code instead:

class base
{
public:
    virtual void f(const char *p);
};

class derived : public base
{
public:
    virtual override void f(char *p);
};

This would be illegal, because no base class function has the same signature.
This keyword could save a lot of bugs and a lot of time. The precise meaning
would be: when you specify override, a base class virtual function with the
same name and the same signature must exist.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 05 Nov 98 23:33:52 GMT, henk.devos@dzine.be <henk.devos@dzine.be> wrote:

>class base
>{
>public:
>    virtual void f(const char *p);
>};
>
>class derived : public base
>{
>public:
>    virtual override void f(char *p);
>};

But you lose type some type safety this way.  When calling the func f
through a pointer/reference to a base, the arg of f had better be
a "const char *".  Eg,

void function(base * b)
{
     const char u='u';
     b->f(&u); // from signature, we are assured that u will not change!
     // but derived::f(char *) may try to change u!
}


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]