"James Kuyper Jr." <kuyper@wizard.net> writes:

|>  James Kanze wrote:
|>  ...
|>  > The important point is (and I think we agree): <iostream> is as
|>  > much a part of C++ as are while and if.

|>  Yes, <iostream> is as much a part of the C++ library, as while and
|>  if are of the C++ language.

|>  However, I do consider <iostream> to be a far less fundamental part
|>  of C++ than while or if.

The standard doesn't.  The standard defines C++.  <iostream> is part of
C++.

What is this C++, which is defined by the standard?

This is a serious question.  I, too, normally think of the language and
the library as being separate things.  But then we have the question:
what is the thing that the standard defines, if it is both language and
library.

I think that the standard itself is a bit ambiguous about this.  The
very first sentence is unambiguous: the standard defines a language.
Since <iostream> is part of what the standard defines, it must be part
of the language.  As you and Greg point out, however, in other places,
the standard uses the words with their more usual significations, in
which language and library are in opposition.

I have always heard, in standards circles (more often C than C++), that
the library IS part of the language.  I have always supposed that this
was just a special use of the word within the standard, justified, at
least in fact, by the fact that the "library" wasn't required to be a
library.  Obviously, this special use ubiquious in the standard, as your
quotes show:-).

For me, then, the questions remain:
  - what does the standard define, if it is not (only) the C++
    *language*, and
  - what is the formal difference between the "language" and the
    "library", in the context of the standard?

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

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

In article <86g0ha4aob.fsf@alex.gabi-soft.de>,
James Kanze  <kanze@gabi-soft.de> wrote:
>Francis Glassborow <francis.glassborow@ntlworld.com> writes:
>
>|>  Why do people have problems with this sort of thing? Why are authors
>|>  still writing, and readers still buying books that are based on the
>|>  pre- standard versions of C++?
>
>Because 2 years isn't a particularly long lead time.  I would hope that
>no one is currently writing a book based on the pre-standard C++, but of
>the books I generally recommend, many appeared before the standard.  And
>I'm not about to tell anyone to throw Scott Meyers (or James Coplien, or
>Barton and Nackman) out the window, just because they happened to write
>their book too soon.

I agree that the techniques et al in some books seem to give
them extra consideration here, though too, they are usually not
novice books.  That said, it would be nice to see some of them
upgraded.

I hope too that nobody is still writing a pre-standard C++ text,
but some of the garbage out there can result in the same net effect :(

Re 2 years: Well, saying it's 2 years is generous IMO.
Anyway, I think your point is that writing a good book
takes time among other things, and of that I agree.
--
Greg Comeau                   Comeau C/C++ 4.2.44 "so close"
ONLINE COMPILER ==>           http://www.comeaucomputing.com/tryitout
4.2.45 during February!       NEW ONLINE: Try out our C99 mode!
comeau@comeaucomputing.com    http://www.comeaucomputing.com

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

James Kanze wrote:
>
> "James Kuyper Jr." <kuyper@wizard.net> writes:
[Re: the distinction (or lack thereof) between the language and the
standard library].
> |>  This is not just just a theoretical distinction. While the standards
> |>  do allow a blurring of the distinction,
>
> The standard *requires* a blurring of the distinction in certain cases:
> new, delete, typeid, for example.  The sizeof operator returns a size_t,
> which is defined in the library.
>
> The blurring is more ubiquious than you think.

The C++ standard spends 300 pages from clause 2 through 16, describing
the C++ language. In those 300 pages, here's every significant reference
I could find to the standard library:

2.8p1, 3.7.3p2, 3.7.3.1p4, 3.7.3.2p3-4, 3.9p3, footnote 39, 5.2.8p6,
5.3.3p6, 5.3.4p7, 5.3.4p12, 5.7p6, 5.8p2, 8.3.5p2

Note that most of those references occur in non-normative text, which
indicates their non-essential role in the description of the language. I
don't consider that a ubiquitous aspect of the standard.

...
> An implementation *can* do this.  It is not required.

Exactly what I said. By the way, I found exactly the most relevant
citations from the C++ standard. They're in section 1.5. Checking back,
I see that Greg Comeau has already referred you to that section, but
didn't quote from it. I can't tell from your reply to his message
whether you actually looked it up. Here's what it says:

1.5p1: "Clauses 2 through 16 describe the C++ programming language. ..."
1.5p2: "Clauses 17 through 27 (the _library clauses_) describe the
standard C++ library, ..."

I don't see how the standard could make the distinction any clearer than
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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James Kanze wrote:
...
> The important point is (and I think we agree): <iostream> is as much a
> part of C++ as are while and if.

Yes, <iostream> is as much a part of the C++ library, as while and if
are of the C++ language.

However, I do consider <iostream> to be a far less fundamental part of
C++ than while or if.

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

In article <867l2c3poa.fsf@alex.gabi-soft.de>,
James Kanze  <kanze@gabi-soft.de> wrote:
>comeau@panix.com (Greg Comeau) writes:
>|>  I may divide C++ in such a way and talk about it as such, because,
>|>  as mentioned, the Standard let's me do so.
>
>You may divide C++ in such a way, and speak of the library and the
>language, because this is the common usage in technical English.  And it
>is sometimes convenient to do so.

And because the Standard says so.

>|>  See 1.5 for C++ (I'm certain C has similar narrative) and IMO this
>|>  does not dispute the first sentence of the standard.
>
>The word "language" has several different meanings.  I forget the exact
>use which triggered my remarks, but I would very much object to someone
>saying something to the effect that <iostream> is not part of the C++
>language.

As mentioned, it's not part of COBOL, so as mentioned, I agree.

>Unless, of course, the context were 100% clear that he was
>using language in the more generally accepted sense, to deliniate a part
>of the what the C++ standard defines.  But in that case, it would
>probably be superfluous to say that <iostream> was not part of the
>language.

This seems to be where the "fine line" is.

>The important point is (and I think we agree): <iostream> is as much a
>part of C++ as are while and if.

Yes, just different parts :)
--
Greg Comeau                   Comeau C/C++ 4.2.44 "so close"
ONLINE COMPILER ==>           http://www.comeaucomputing.com/tryitout
4.2.45 during February!       NEW ONLINE: Try out our C99 mode!
comeau@comeaucomputing.com    http://www.comeaucomputing.com

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

James Kanze wrote:
>
> James Dennett <jdennett@acm.org> writes:
>
> |>  Because <iostream.h> already existed on a lot of systems and its
> |>  contents were not standardised; the <iostream.h> headers are not
> |>  compatible except at a very simplistic level.
>
> Several people have seemed to imply this in the past, but this is the
> first time I've seen it said so explicitly.  I know that there were
> incompatibilities; I've had to program around them.  But they were
> generally of no great importance, and I've written user defined
> streambuf which effectively worked on a number of systems (GreenHills,
> CFront based, g++ and the post CFront Sun CC) without modifications.
>
> Do you consider user defined streambuf's just a simplistic level, or
> have I just been incredibly lucky?  My impression was that most vendors
> considered the USL implementation delivered with CFront as a de facto
> standard, and made their implementations compatible, even to the point
> of implementing the same bugs.

I'm maybe guilty of posting received wisdom rather than my own
experience.

I'd say that defining a streambuf is quite simple, and pretty vital
to any extension of IOStreams.  Using the filebuf* attach(int) or
int fd() const methods won't be portable, of course, to systems which
don't have file descriptors of type int, and I find numerous other
non-portable functions in my old streambuf.h with names which I could
legitimately (if ill-advisedly) trample with macros in ignorance.
The header file in question isn't very careful with its names, but
given that there was no Standard at the time I find that understandable.
Naturally, it wasn't hard to learn which features were portable and
which were not, and even in the presence of Standards the same kind
of effort is required to learn where the Standard is implemented
faithfully and where it is not.  Hopefully the Standard reduces
the level of effort hugely, but I've never worked in a field where
conformance of any bought components to the relevant Standards could
be safely assumed.

That aside, <iostream.h> has been quite portable enough for my
needs.  I believe that some compilers now supply Standard IOStreams
even if you include <iostream.h> (MSVC++?), which is of course
significantly different from the classical IOstreams which you
might expect if you included <iostream.h>.  Having said that,
Standard IOStreams are close enough to being a pure extension
of classical IOStreams that this might not be a problem.

Probably I overstated the differences between the various pre-Standard
iostreams implementations.  The context might justify this exaggeration;
my post was a reply to a mesage from Cyd which asked why there was any
need for the C++ Standard, given that people had already been using
C++.

-- James Dennett

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

In article <86lmr24b13.fsf@alex.gabi-soft.de>,
James Kanze  <kanze@gabi-soft.de> wrote:
>comeau@panix.com (Greg Comeau) writes:
>|>  <iostream> does not mean it's built into the language.
>
>The fact that it is defined in the standard does mean that it's build
>into the language.  The same as is <stdio.h> in C, for example.

<iostream> is part of the core language?  Sorry, I must disagree
with you on this, as does the Standard (AFAIR).  Ditto for <stdio.h>,
in C++ and in C.
--
Greg Comeau                   Comeau C/C++ 4.2.44 "so close"
ONLINE COMPILER ==>           http://www.comeaucomputing.com/tryitout
4.2.45 during February!       NEW ONLINE: Try out our C99 mode!
comeau@comeaucomputing.com    http://www.comeaucomputing.com

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

In article <86itm64at1.fsf@alex.gabi-soft.de>,
James Kanze  <kanze@gabi-soft.de> wrote:
>James Dennett <jdennett@acm.org> writes:
>|>  Because <iostream.h> already existed on a lot of systems and its
>|>  contents were not standardised; the <iostream.h> headers are not
>|>  compatible except at a very simplistic level.
>
>Several people have seemed to imply this in the past, but this is the
>first time I've seen it said so explicitly.  I know that there were
>incompatibilities; I've had to program around them.  But they were
>generally of no great importance, and I've written user defined
>streambuf which effectively worked on a number of systems (GreenHills,
>CFront based, g++ and the post CFront Sun CC) without modifications.
>
>Do you consider user defined streambuf's just a simplistic level, or
>have I just been incredibly lucky?  My impression was that most vendors
>considered the USL implementation delivered with CFront as a de facto
>standard, and made their implementations compatible, even to the point
>of implementing the same bugs.

Yes and no.  I mean, some vendors also tried to be compatible with the
language part of cfront too, but certainly that didn't put an end
to standardizing the core language.

Anyway, I suspect you were lucky.  Of course, there were bugs
in every implementation, but as mentioned there were also pure
incompatibilities.  Furthermore, there were holes in the
"iostream classic" documentation.  Even w/o the header file
name changes, standardizing it was a necessity.  There were also
new interactions due to new aspect the the C++ SL.  And of course,
header file names across the board were changed because namespaces
were added to the core language.  As, ugh, Martha Stewart says
"This is a good thing."
--
Greg Comeau                   Comeau C/C++ 4.2.44 "so close"
ONLINE COMPILER ==>           http://www.comeaucomputing.com/tryitout
4.2.45 during February!       NEW ONLINE: Try out our C99 mode!
comeau@comeaucomputing.com    http://www.comeaucomputing.com

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

comeau@panix.com (Greg Comeau) writes:

|>  In article <86itm64at1.fsf@alex.gabi-soft.de>,
|>  James Kanze  <kanze@gabi-soft.de> wrote:
|>  >James Dennett <jdennett@acm.org> writes:
|>  >|>  Because <iostream.h> already existed on a lot of systems and its
|>  >|>  contents were not standardised; the <iostream.h> headers are not
|>  >|>  compatible except at a very simplistic level.

|>  >Several people have seemed to imply this in the past, but this is
|>  >the first time I've seen it said so explicitly.  I know that there
|>  >were incompatibilities; I've had to program around them.  But they
|>  >were generally of no great importance, and I've written user
|>  >defined streambuf which effectively worked on a number of systems
|>  >(GreenHills, CFront based, g++ and the post CFront Sun CC) without
|>  >modifications.

|>  >Do you consider user defined streambuf's just a simplistic level,
|>  >or have I just been incredibly lucky?  My impression was that most
|>  >vendors considered the USL implementation delivered with CFront as
|>  >a de facto standard, and made their implementations compatible,
|>  >even to the point of implementing the same bugs.

|>  Yes and no.  I mean, some vendors also tried to be compatible with
|>  the language part of cfront too, but certainly that didn't put an
|>  end to standardizing the core language.

Well, I certainly wouldn't argue against standardization.  Just the
opposite.  It's one thing when a number of vendors happen to do the same
thing (for whatever reasons), and quite another when there is a written
document, approved by an international organization.  That said,
however, even today, in portable code, I use the classic iostream,
because it is pretty much everywhere.  (Actually, the two are close
enough that it is fairly simple to write code which works with both,
without #ifdef's.)

|>  Anyway, I suspect you were lucky.  Of course, there were bugs in
|>  every implementation, but as mentioned there were also pure
|>  incompatibilities.  Furthermore, there were holes in the "iostream
|>  classic" documentation.

I'm aware of the incompatibilities and the holes in the documentation.
There are degrees of compatibility, and even the standard won't (and
doesn't try to) guarantee perfect compatibility.  Globally, I think that
the implementations of the classic iostream were more than just
superficially compatible.

I'm not arguing against standardization; I'm just curious if anyone
knows of cases where there were real compatibility problems, which
couldn't easily be avoided by careful programming, or which required a
#ifdef to handle.  Because I'm not aware of any.  (And I realize,
afterwards, that I picked the wrong thread to ask the question.  I am
very much in favor of standardization, and my major criticism of the
standard is that we didn't have it earlier.)

|>  Even w/o the header file name changes, standardizing it was a
|>  necessity.  There were also new interactions due to new aspect the
|>  the C++ SL.  And of course, header file names across the board were
|>  changed because namespaces were added to the core language.  As,
|>  ugh, Martha Stewart says "This is a good thing."

I know.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

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

"James Kuyper Jr." <kuyper@wizard.net> writes:

|>  James Kanze wrote:

|>  > comeau@panix.com (Greg Comeau) writes:

|>  > |>  <iostream> does not mean it's built into the language.

|>  > The fact that it is defined in the standard does mean that it's
|>  > build into the language.  The same as is <stdio.h> in C, for
|>  > example.

|>  <stdio.h> is built into the C standard; that's not quite the same
|>  thing as being built into the C language. Both the C and C++
|>  standards make a clear distinction between the standard library and
|>  the language proper.  They both give implementors the freedom to
|>  blur that distinction, but <iostream> can be and usually is
|>  implemented separately from the core language.

The C standard starts out: "This International Standard specifies the
form and establishes the interpretation of programs written in the C
programming language."  Nothing else.  The C++ standard is even more
categoric: "This International Standard specifies requirements for
implementations of the C++ programming language."  In both cases, the
standard specifies a language.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

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

comeau@panix.com (Greg Comeau) writes:

|>  In article <86lmr24b13.fsf@alex.gabi-soft.de>,
|>  James Kanze  <kanze@gabi-soft.de> wrote:
|>  >comeau@panix.com (Greg Comeau) writes:
|>  >|>  <iostream> does not mean it's built into the language.

|>  >The fact that it is defined in the standard does mean that it's
|>  >build into the language.  The same as is <stdio.h> in C, for
|>  >example.

|>  <iostream> is part of the core language?  Sorry, I must disagree
|>  with you on this, as does the Standard (AFAIR).  Ditto for
|>  <stdio.h>, in C++ and in C.

If it's specified in the standard, it's part of the language.  You may,
for various reasons, divide the language into a core language and a
library, but they are both part of the language.  See my other posting;
it's the first sentence in both standards.

The libraries are part of the language.  If you don't provide
<iostream>, you haven't provided an implementation of the C++ language
(or at least not a hosted implementation).

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

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

In article <86ofvxf4wo.fsf@alex.gabi-soft.de>,
James Kanze  <kanze@gabi-soft.de> wrote:
>comeau@panix.com (Greg Comeau) writes:
>|>  In article <86lmr24b13.fsf@alex.gabi-soft.de>,
>|>  James Kanze  <kanze@gabi-soft.de> wrote:
>|>  >comeau@panix.com (Greg Comeau) writes:
>|>  >|>  <iostream> does not mean it's built into the language.
>|>  >The fact that it is defined in the standard does mean that it's
>|>  >build into the language.  The same as is <stdio.h> in C, for
>|>  >example.
>|>  <iostream> is part of the core language?  Sorry, I must disagree
>|>  with you on this, as does the Standard (AFAIR).  Ditto for
>|>  <stdio.h>, in C++ and in C.
>
>If it's specified in the standard, it's part of the language.  You may,
>for various reasons, divide the language into a core language and a
>library, but they are both part of the language.  See my other posting;
>it's the first sentence in both standards.
>
>The libraries are part of the language.  If you don't provide
><iostream>, you haven't provided an implementation of the C++ language
>(or at least not a hosted implementation).

<iostream> is certainly not part of [the] COBOL [programming language],
so to that extent it is certainly part of [the] C++ [programming language].
Clearly so.

However, it is not part of the language of the programming language.
Clearly so.

I may divide C++ in such a way and talk about it as such, because,
as mentioned, the Standard let's me do so.  See 1.5 for C++
(I'm certain C has similar narrative) and IMO this does not
dispute the first sentence of the standard.
--
Greg Comeau                   Comeau C/C++ 4.2.44 "so close"
ONLINE COMPILER ==>           http://www.comeaucomputing.com/tryitout
4.2.45 during February!       NEW ONLINE: Try out our C99 mode!
comeau@comeaucomputing.com    http://www.comeaucomputing.com

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

James Kanze wrote:
>
> "James Kuyper Jr." <kuyper@wizard.net> writes:
>
> |>  James Kanze wrote:
>
> |>  > comeau@panix.com (Greg Comeau) writes:
>
> |>  > |>  <iostream> does not mean it's built into the language.
>
> |>  > The fact that it is defined in the standard does mean that it's
> |>  > build into the language.  The same as is <stdio.h> in C, for
> |>  > example.
>
> |>  <stdio.h> is built into the C standard; that's not quite the same
> |>  thing as being built into the C language. Both the C and C++
> |>  standards make a clear distinction between the standard library and
> |>  the language proper.  They both give implementors the freedom to
> |>  blur that distinction, but <iostream> can be and usually is
> |>  implemented separately from the core language.
>
> The C standard starts out: "This International Standard specifies the
> form and establishes the interpretation of programs written in the C
> programming language."  Nothing else.  The C++ standard is even more
> categoric: "This International Standard specifies requirements for
> implementations of the C++ programming language."  In both cases, the
> standard specifies a language.

Yes, it specifies "the interpretation of programs written in the C
language"; that includes the "syntax and constraints of the C language",
but the language itself is only one part of what you need to interpret
programs written in it. Why would they title chapter 6 as "Language",
distinct from chapter 7, which is titled "Library", if the whole thing
defines the language? The C standard even foreshadows that distinction
in items 5 and 6 of the introduction.

The C++ standard has no section titled "Language", and no single section
titled "Library". However, every section from 17 to 29, and not one of
the other top-level sections, contains the word "library", leaving
chapters 1 through 16 to define the language itself.

This is not just just a theoretical distinction. While the standards do
allow a blurring of the distinction, few implementation blur it very
much. With most implementations, of C or C++, the language is
implemented almost entirely by the compiler, while the standard library
is implemented almost entirely by separate header and library files that
can be modified or even replaced if the user wants to do so (and has
enough technical understanding of the implementation to handle the
difficulties implied by my use of the word "almost").

By the way, can anyone describe the "1984 /usr/group Standard" referred
to in item 6 of the C standard's introduction? I'd never heard of it
before.

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

I have two questions for the group:
1. For the program to work, wouldn't there have to be a "using namespace
std" prior to the "cout" according to the new standard?
2. I've scanned the FAQ and I'm even more confused. I'm not trying to be
smart or anything, but why is there a new standard if people have been
teaching/learning/using C++ for years? Will it ever be finalized?  Until
now, I had been using <iostream.h> and no namespace on Borland C++ 5.  And
why <iostream>? isn't it better to have extensions in separate files rather
than having them built into the language?

<dalroth@my-deja.com> wrote in message news:95cqdu$jft$1@nnrp1.deja.com...
> The following piece of code compiles successfully under g++ 2.95.2 and
> Microsoft Visual C++ 6.0a, however I believe it is a violation of the
> ANSI C++ standard.  Towards the end, there is a comment that points out
> the offending piece of code, and the changes I believe I have to make
> for this program to be valid ANSI C++.  If I make these changes, this
> code compiles and works with Microsoft Visual C++ 6.0a, but no longer
> works with g++.
>
> Is this a violation of the ANSI C++ standard or not?  I'm just not
> familiar enough with the standard to be able to say whether it is or
> not with 100% certainty.
>
> Thanks!
> Bryan
>
> ---<SNIP>---------------------------------------------------------
>
> #include <iostream.h>
>
> template<class T>
> struct map_inner_t
> {
>   int id;
>   void (T::*handler)();
> };
>
> class interface
> {
> public:
>   virtual void inner_execute() = 0;
> };
>
> template<class T>
> class inner_implementation: public interface
> {
> protected:
>   static const map_inner_t<T> inner[];
>
> public:
>   virtual void inner_execute();
> };
>
> template<class Y> class outer_implementation;
> template<class Y> class outer_implementation: public
> inner_implementation< outer_implementation< Y > >
> {
> public:
>   virtual void InnerHandler1() { cout << "Inner 1" << endl; };
>   virtual void InnerHandler2() { cout << "Inner 2" << endl; };
>   virtual void InnerHandler3() { cout << "Inner 3" << endl; };
> };
>
> class child;
> class child: public outer_implementation< child >
> {
> };
>
> template<class T>
> void inner_implementation< T >::inner_execute()
> {
>   T *innerp;
>
>   for (int i=0; inner[i].handler; i++)
>   {
>     cout << inner[i].id << ": ";
>     innerp = dynamic_cast<T *>(this);
>     (innerp->*inner[i].handler)();
>   }
> };
>
> template<class T >
> const map_inner_t< T >
>     inner_implementation< T >::inner[] =
> {
> // I believe the next four lines violate the ANSI C++ standard.
> // When initializing an array of pointers to structures, shouldn't
> // the values for those structures be contained within braces?
> 6, & T ::InnerHandler1,
> 7, & T ::InnerHandler2,
> 8, & T ::InnerHandler3,
> 0, 0
> };
>
> // I think the following code is how this SHOULD be according to
> // my interpretation of the standard:
> /*
> template<class T >
> const map_inner_t< T >
>     inner_implementation< T >::inner[] =
> {
> { 6, & T ::InnerHandler1 },
> { 7, & T ::InnerHandler2 },
> { 8, & T ::InnerHandler3 },
> { 0, 0 }
> };
> */
>
> int main(int argc, char **argv)
> {
>   child  c;
>
>   c.inner_execute();
>
>   return 0;
> };
>
>
> Sent via Deja.com
> http://www.deja.com/
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
>


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

In article <3a8ef071_4@news.velocity.net>, Cyd <nospam@me.net> wrote:
>I have two questions for the group:
>1. For the program to work, wouldn't there have to be a "using namespace
>std" prior to the "cout" according to the new standard?

Not if you use <iostream.h>, which is an extension, because,
perhaps it does it itself and so you don't have too, or perhaps
it doesn't support cout in a namespace at all (again, as an
extension).

>2. I've scanned the FAQ and I'm even more confused. I'm not trying to be
>smart or anything, but why is there a new standard if people have been
>teaching/learning/using C++ for years?

The short answer is because there would be incompatibilities.

>Will it ever be finalized?

Will what be finialized?  Notwithstanding defect reports,
Standard C++ was technically finalized in 1997.

>Until
>now, I had been using <iostream.h> and no namespace on Borland C++ 5.
>And why <iostream>?

Because changes were made, and is was consider to "make a break".
As well, namespaces were introduced into the language, and at that
point a whole new scheme was considered.  Check out

   http://www.comeaucomputing.com/techtalk/#cnames

>isn't it better to have extensions in separate files rather
>than having them built into the language?

<iostream> does not mean it's built into the language.
That said, theoretically <iostream> or <iostream.h> can
be built into a particular _implementation_, that is,
a real file per se is not a requirement.
--
Greg Comeau                   Comeau C/C++ 4.2.44 "so close"
ONLINE COMPILER ==>           http://www.comeaucomputing.com/tryitout
4.2.45 during February!       NEW ONLINE: Try out our C99 mode!
comeau@comeaucomputing.com    http://www.comeaucomputing.com

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

Cyd wrote:
>
> I have two questions for the group:
> 1. For the program to work, wouldn't there have to be a "using namespace
> std" prior to the "cout" according to the new standard?

And <iostream.h> would need to be changed to <iostream> because the C++
language does not include <iostream.h>.  Most compilers which still ship
<iostream.h> (all C++ compilers?) put facilities into the global
namespace
when it is used.  Many use pre-Standard IOStreams in that case, but at
least one uses Standard IOStreams but dumps them in the global
namespace.

> 2. I've scanned the FAQ and I'm even more confused. I'm not trying to be
> smart or anything, but why is there a new standard if people have been
> teaching/learning/using C++ for years?

Why have a Standard?  So that portable code can be written, so that
there is a legal contract between compiler users and compiler vendors,
so that our *knowledge* of C++ is portable between different systems.
Probably a lot more good reasons.

> Will it ever be finalized?

The Standard was finished and published in 1998.  It has flaws, but
it's infinitely better than having no Standard.  The C++ Standard will
be revised in the future as time and understanding (and ISO rules)
allow.

The C++ language won't be "finalized" until its use is so small that
no need for change is perceived.  I don't see that happening for a
long time, but it does appear that C++ will be a much more stable
creature now that there is an ISO Standard.

> Until
> now, I had been using <iostream.h> and no namespace on Borland C++ 5.  And
> why <iostream>?

Because <iostream.h> already existed on a lot of systems and its
contents were not standardised; the <iostream.h> headers are not
compatible except at a very simplistic level.  Standard IOStreams
are a cleaned-up, templated version, quite different internally
from pre-Standard IOStreams.  In order to avoid confusion with the
non-portable <iostreams.h> and other non-portable headers, the C++
Standards Committee chose to use header names which were not in
pre-existing use.  Putting the Standard library in the std::
namespace also helps to avoid clashes with pre-Standard code, apart
from being a Good Thing in its own right.

> isn't it better to have extensions in separate files rather
> than having them built into the language?

Extensions, by definition, aren't built in to the language.  I'm
afraid I don't see the point of this last question, so I won't
comment any further.

-- James Dennett <jdennett@acm.org>

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

In article <3a8ef071_4@news.velocity.net>, Cyd <nospam@me.net> writes
>2. I've scanned the FAQ and I'm even more confused. I'm not trying to be
>smart or anything, but why is there a new standard if people have been
>teaching/learning/using C++ for years? Will it ever be finalized?  Until
>now, I had been using <iostream.h> and no namespace on Borland C++ 5.  And
>why <iostream>? isn't it better to have extensions in separate files rather
>than having them built into the language?

There is, and only ever has been, one C++ Standard. Everything that
existed prior to 1998 was akin to 0.x releases of a product under
development. As we all know, such releases can often be useful and the
feedback from them helps determine the nature of the first official,
complete release.

If you think of the first standard as being 1.0, then when we add the
corrections agreed in the Toronto TC we have 1.0.1. Eventually there
will be a 2.0 (seven or eight years time).

Why do people have problems with this sort of thing? Why are authors
still writing, and readers still buying books that are based on the pre-
standard versions of C++? Try going to your friendly local retailer of
books and ask them for a book on Photoshop 2, or MSWord 4, or Fortran 1V
any other long superseded product.

Any book that mentions that it is about Standard C++ anywhere on the
cover, introduction, preface etc. and uses .h headers should be returned
as not meeting its specifications. Any book on C++ that purports to
teach the language (rather than showing techniques in using it) that
does not claim to describe Standard C++ should be immediately
remaindered as being out of date.

Oh, perhaps readers could add their own sprinkling of emoticons.

--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)

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

Cyd wrote:
>
> I have two questions for the group:
> 1. For the program to work, wouldn't there have to be a "using namespace
> std" prior to the "cout" according to the new standard?

Yes, but that's not sufficient. It would also have to use <iostream>
rather than <iostream.h>. There is no <iostream.h> in the C++ standard.
Since the traditional <iostream.h> was defined before namespaces, it
usually dumps its symbols in what is now called the global namespace.
Therefore, code which does use <iostream.h> doesn't need "using
namespace std" or "std::" to access its features. In fact, a "std::"
prefix would guarantee that you're NOT using an <iostream.h> feature.

> 2. I've scanned the FAQ and I'm even more confused. I'm not trying to be
> smart or anything, but why is there a new standard if people have been
> teaching/learning/using C++ for years? Will it ever be finalized? ...

There's a standard in order to standardize what it is they've been
teaching/learning/using. No, the standard will never be finalized.
Someday it will die when no one pays any more attention to it, but I
fully expect it to die with some changes planned that were never
implemented. However, particular releases of the standard do get
finished, and the first one has already been released, back in late
1998. The committee is watching it be implemented, and they're listening
to complaints, so they can find and correct its defects. This part of
the cycle will last a few more years. Then they'll start work on the
next release of the standard, which will take several more years before
completion. I've heard that the complete cycle is expected to take about
ten years, so expect the next release around 2008.

> ... Until
> now, I had been using <iostream.h> and no namespace on Borland C++ 5.  And
> why <iostream>? isn't it better to have extensions in separate files rather
> than having them built into the language?

<iostream> is no more and no less of an extension than most of the other
standard headers. There's a clear distinction between the language,
described by sections 1-16, and the standard library, described by
sections 17-27. There's a few of the standard library features, such as
std::typeinfo, which are needed to support the language, but most of
them are seperable from it and could be called extensions. However,
officially the term "extension" refers only to things that go beyond the
standard, without violating it; the library is entirely within the
standard. <iostream.h> would technically be considered an extension, but
it would need a significant re-design to make it a conforming extension.

Getting back to what I think is your real point: <iostream.h> was not
retained in the C++ standard, because there were so many different and
incompatible versions of it. The new <iostream> library is not fully
compatible with any of the previously existing <iostream.h>
implementations. Existing code can #include <iostream.h> and use it
without any std:: prefixes, since it pre-dates namespaces. The correct
functioning of that code is a guarantee that you'll have to get from the
C++ implementor; the standard makes no such guarantee. New or updated
code should be changed, if possible, to use <iostream>, and to use
either use "std::", or "using namespace std".

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

James Dennett <jdennett@acm.org> writes:

|>  Because <iostream.h> already existed on a lot of systems and its
|>  contents were not standardised; the <iostream.h> headers are not
|>  compatible except at a very simplistic level.

Several people have seemed to imply this in the past, but this is the
first time I've seen it said so explicitly.  I know that there were
incompatibilities; I've had to program around them.  But they were
generally of no great importance, and I've written user defined
streambuf which effectively worked on a number of systems (GreenHills,
CFront based, g++ and the post CFront Sun CC) without modifications.

Do you consider user defined streambuf's just a simplistic level, or
have I just been incredibly lucky?  My impression was that most vendors
considered the USL implementation delivered with CFront as a de facto
standard, and made their implementations compatible, even to the point
of implementing the same bugs.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

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

"Cyd" <nospam@me.net> writes:

|>  I have two questions for the group:

    [...]

|>  2. I've scanned the FAQ and I'm even more confused. I'm not trying
|>     to be smart or anything, but why is there a new standard if
|>     people have been teaching/learning/using C++ for years? Will
|>     it ever be finalized?  Until now, I had been using
|>     <iostream.h> and no namespace on Borland C++ 5.  And why
|>     <iostream>? isn't it better to have extensions in separate files
|>     rather than having them built into the language?

First, when we speak of a "new" standard, we are speaking in a strictly
temporal sense; there isn't an old standard which the new standard is
replacing.  C++ sort of struggled by without a standard for many years.

Secondly, the standard says nothing about how the standard headers are
implemented.  Traditionally, it has been by means of separate files (and
the change in the name will not change anything here).  But there has
never been anything to require this, even in C.  All that is required is
that after the line #include <iostream>, a certain number of symbols are
defined (in a certain way, of course).

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

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

comeau@panix.com (Greg Comeau) writes:

|>  <iostream> does not mean it's built into the language.

The fact that it is defined in the standard does mean that it's build
into the language.  The same as is <stdio.h> in C, for example.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

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

Francis Glassborow <francis.glassborow@ntlworld.com> writes:

|>  Why do people have problems with this sort of thing? Why are authors
|>  still writing, and readers still buying books that are based on the
|>  pre- standard versions of C++?

Because 2 years isn't a particularly long lead time.  I would hope that
no one is currently writing a book based on the pre-standard C++, but of
the books I generally recommend, many appeared before the standard.  And
I'm not about to tell anyone to throw Scott Meyers (or James Coplien, or
Barton and Nackman) out the window, just because they happened to write
their book too soon.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

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

In article <86g0ha4aob.fsf@alex.gabi-soft.de>, James Kanze <kanze@gabi-
soft.de> writes
>Because 2 years isn't a particularly long lead time.  I would hope that
>no one is currently writing a book based on the pre-standard C++, but of
>the books I generally recommend, many appeared before the standard.  And
>I'm not about to tell anyone to throw Scott Meyers (or James Coplien, or
>Barton and Nackman) out the window, just because they happened to write
>their book too soon.

Nor am I, but those books do not purport to teach C++, they assume you
already know the basics (and my wording was intended to allow such books
to continue to be recommended :)


--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)

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

James Kanze wrote:
>
> comeau@panix.com (Greg Comeau) writes:
>
> |>  <iostream> does not mean it's built into the language.
>
> The fact that it is defined in the standard does mean that it's build
> into the language.  The same as is <stdio.h> in C, for example.

<stdio.h> is built into the C standard; that's not quite the same thing
as being built into the C language. Both the C and C++ standards make a
clear distinction between the standard library and the language proper.
They both give implementors the freedom to blur that distinction, but
<iostream> can be and usually is implemented separately from the core
language.

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

The following piece of code compiles successfully under g++ 2.95.2 and
Microsoft Visual C++ 6.0a, however I believe it is a violation of the
ANSI C++ standard.  Towards the end, there is a comment that points out
the offending piece of code, and the changes I believe I have to make
for this program to be valid ANSI C++.  If I make these changes, this
code compiles and works with Microsoft Visual C++ 6.0a, but no longer
works with g++.

Is this a violation of the ANSI C++ standard or not?  I'm just not
familiar enough with the standard to be able to say whether it is or
not with 100% certainty.

Thanks!
Bryan

---<SNIP>---------------------------------------------------------

#include <iostream.h>

template<class T>
struct map_inner_t
{
  int id;
  void (T::*handler)();
};

class interface
{
public:
  virtual void inner_execute() = 0;
};

template<class T>
class inner_implementation: public interface
{
protected:
  static const map_inner_t<T> inner[];

public:
  virtual void inner_execute();
};

template<class Y> class outer_implementation;
template<class Y> class outer_implementation: public
inner_implementation< outer_implementation< Y > >
{
public:
  virtual void InnerHandler1() { cout << "Inner 1" << endl; };
  virtual void InnerHandler2() { cout << "Inner 2" << endl; };
  virtual void InnerHandler3() { cout << "Inner 3" << endl; };
};

class child;
class child: public outer_implementation< child >
{
};

template<class T>
void inner_implementation< T >::inner_execute()
{
  T *innerp;

  for (int i=0; inner[i].handler; i++)
  {
    cout << inner[i].id << ": ";
    innerp = dynamic_cast<T *>(this);
    (innerp->*inner[i].handler)();
  }
};

template<class T >
const map_inner_t< T >
    inner_implementation< T >::inner[] =
{
// I believe the next four lines violate the ANSI C++ standard.
// When initializing an array of pointers to structures, shouldn't
// the values for those structures be contained within braces?
 6, & T ::InnerHandler1,
 7, & T ::InnerHandler2,
 8, & T ::InnerHandler3,
 0, 0
};

// I think the following code is how this SHOULD be according to
// my interpretation of the standard:
/*
template<class T >
const map_inner_t< T >
    inner_implementation< T >::inner[] =
{
 { 6, & T ::InnerHandler1 },
 { 7, & T ::InnerHandler2 },
 { 8, & T ::InnerHandler3 },
 { 0, 0 }
};
*/

int main(int argc, char **argv)
{
  child  c;

  c.inner_execute();

  return 0;
};


Sent via Deja.com
http://www.deja.com/

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

<dalroth@my-deja.com> wrote in message news:95cqdu$jft$1@nnrp1.deja.com...
> The following piece of code compiles successfully under g++ 2.95.2 and
> Microsoft Visual C++ 6.0a, however I believe it is a violation of the
> ANSI C++ standard.  Towards the end, there is a comment that points out
> the offending piece of code, and the changes I believe I have to make
> for this program to be valid ANSI C++.  If I make these changes, this
> code compiles and works with Microsoft Visual C++ 6.0a, but no longer
> works with g++.
>
> Is this a violation of the ANSI C++ standard or not?  I'm just not
> familiar enough with the standard to be able to say whether it is or
> not with 100% certainty.
>

> template<class T>
> struct map_inner_t
> {
>   int id;
>   void (T::*handler)();
> };
>

[snipped other lines of code]
>
> template<class T >
> const map_inner_t< T >
>     inner_implementation< T >::inner[] =
> {
> // I believe the next four lines violate the ANSI C++ standard.
> // When initializing an array of pointers to structures, shouldn't
> // the values for those structures be contained within braces?
> 6, & T ::InnerHandler1,
> 7, & T ::InnerHandler2,
> 8, & T ::InnerHandler3,
> 0, 0
> };
>
> // I think the following code is how this SHOULD be according to
> // my interpretation of the standard:
> /*
> template<class T >
> const map_inner_t< T >
>     inner_implementation< T >::inner[] =
> {
> { 6, & T ::InnerHandler1 },
> { 7, & T ::InnerHandler2 },
> { 8, & T ::InnerHandler3 },
> { 0, 0 }
> };
> */
>
> int main(int argc, char **argv)
> {
>   child  c;
>
>   c.inner_execute();
>
>   return 0;
> };

Both are permitted by the standard. The fully braced version is the "normal"
form, but the braces may be omitted (8.5.1p11):
"Braces can be elided in an initializer-list as follows. If the
initializer-list begins with a left brace, then the succeeding
comma-separated list of initializers initializes the members of a
subaggregate; it is erroneous for there to be more initializers than
members. If, however, the initializer-list for a subaggregate does not begin
with a left brace, then only enough initializers from the list are taken to
initialize the members of the subaggregate; any remaining initializers are
left to initialize the next member of the aggregate of which the
current subaggregate is a member."

--
Anthony Williams
Software Engineer, Nortel Networks
The opinions expressed in this message are mine and do not represent those
of my employer



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

dalroth@my-deja.com wrote:
>
> The following piece of code compiles successfully under g++ 2.95.2 and
> Microsoft Visual C++ 6.0a, however I believe it is a violation of the
> ANSI C++ standard.

It's not, if I understand your qutestion.

Omitting all your templates and other complex issues, what you're
asking is:

struct A {
   int a;
   int b;
};

A a[] = {
   1, 2,
   3, 4,
   5, 6,
};

Is the above valid?  Sure is.  You can omitt the braces and just enough
intiailizers are consumed to fill the subobject of the aggregate.  In
this case, you initialize 3 elements of type a in A.  This is in the
standard in 8.5.1/11

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

Proclaimed dalroth@my-deja.com from the mountaintops:

> The following piece of code compiles successfully under g++ 2.95.2 and
> Microsoft Visual C++ 6.0a, however I believe it is a violation of the
> ANSI C++ standard.  Towards the end, there is a comment that points out
> the offending piece of code, and the changes I believe I have to make
> for this program to be valid ANSI C++.  If I make these changes, this
> code compiles and works with Microsoft Visual C++ 6.0a, but no longer
> works with g++.

I suspect you found a bug in g++.

> template<class T >
> const map_inner_t< T >
>     inner_implementation< T >::inner[] =
> {
> // I believe the next four lines violate the ANSI C++ standard.
> // When initializing an array of pointers to structures, shouldn't
> // the values for those structures be contained within braces?
> 6, & T ::InnerHandler1,
> 7, & T ::InnerHandler2,
> 8, & T ::InnerHandler3,
> 0, 0
> };
>
> // I think the following code is how this SHOULD be according to
> // my interpretation of the standard:
> /*
> template<class T >
> const map_inner_t< T >
>     inner_implementation< T >::inner[] =
> {
> { 6, & T ::InnerHandler1 },
> { 7, & T ::InnerHandler2 },
> { 8, & T ::InnerHandler3 },
> { 0, 0 }
> };
> */

I'm not reading the Standard right now, but I can't conceive of a rule that
aggregate array elements containing addresses of methods should have more
restrictive brace rules than anything else.

The rules are if you account for all the members the first form of array
initialization is correct.

Complain to the authors of g++ (if it's the latest version). You'l find
them much more receptive than MS to your feedback.

--
  Phlip                          phlip_cpp@my-deja.com
============ http://c2.com/cgi/wiki?PhlIp ============
  --  Who needs a degree when we have Web e-search engines?  --

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

dalroth@my-deja.com wrote:
...
> template<class T >
> const map_inner_t< T >
>     inner_implementation< T >::inner[] =
> {
> // I believe the next four lines violate the ANSI C++ standard.
> // When initializing an array of pointers to structures, shouldn't
> // the values for those structures be contained within braces?
>         6, & T ::InnerHandler1,
>         7, & T ::InnerHandler2,
>         8, & T ::InnerHandler3,
>         0, 0
> };

Section 8.5.1p11: "Braces may be elided in an _initializer-list_ as
follows. If the _initializer-list_ begins with a left brace, then the
succeeding comma-seperated list of _initializers_ initializes the
members of a subaggregate; it is erroneous for there to be more
initializers than members. If, however, the _initializer-list_ for a
subaggregate does not begin with the a left brace, then only enough
_initializers_ from the list are taken to initialize the member of the
subaggregate, any remaining _initializers_ are left to initialize the
next member of the aggregate of which the current subaggregate is a
member. [_Example:

 float y[4][3] = {
  { 1, 2, 5},
  { 2, 4, 6},
  { 3, 5, 7},
 };

is a completely-braced initialization: 1, 3, and 5 initialize the first
row of the array y[0], namely y[0][0], y[0][1], and y[0][2]. Likewise
the next two lines initialize y[1] and y[2]. The initializer ends early
and therefore y[3]'s elements are initialized as if explicitly
initialized with an expression of the form float(), that is, are
initialized with 0.0. In the following example, braces in the
_initializer-list_ are elided; however the _initializer-list_ has the
same effect as the completely-braced _initializer-list_ of the above
example,

 float y[4][3] = {
  1, 3, 5, 2, 4, 6, 3, 5, 76
 };

The initializer for y begins with a left brace, but the one for y[0]
does not, therefore three elements from that list are used. Likewise the
next three are taken successively for y[1] and y[2]. -- _end example_]"


Note that "aggregate" is a technical term used by the standard that
includes both structures and arrays, so the above section applies to
your example. map_inner_t<T> is a structure which is a sub-aggregate of
the inner[] array, which is itself an aggregate.


> // I think the following code is how this SHOULD be according to
> // my interpretation of the standard:
> /*
> template<class T >
> const map_inner_t< T >
>     inner_implementation< T >::inner[] =
> {
>         { 6, & T ::InnerHandler1 },
>         { 7, & T ::InnerHandler2 },
>         { 8, & T ::InnerHandler3 },
>         { 0, 0 }
> };

Good style, but not mandatory.

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

<dalroth@my-deja.com> wrote...
> The following piece of code compiles successfully under g++ 2.95.2 and
> Microsoft Visual C++ 6.0a, however I believe it is a violation of the
> ANSI C++ standard.  Towards the end, there is a comment that points
out
> the offending piece of code, and the changes I believe I have to make
> for this program to be valid ANSI C++.  If I make these changes, this
> code compiles and works with Microsoft Visual C++ 6.0a, but no longer
> works with g++.
>
> Is this a violation of the ANSI C++ standard or not?  I'm just not
> familiar enough with the standard to be able to say whether it is or
> not with 100% certainty.
>
> [...]
> template<class T >
> const map_inner_t< T >
>     inner_implementation< T >::inner[] =
> {
> // I believe the next four lines violate the ANSI C++ standard.
> // When initializing an array of pointers to structures, shouldn't
> // the values for those structures be contained within braces?
> 6, & T ::InnerHandler1,
> 7, & T ::InnerHandler2,
> 8, & T ::InnerHandler3,
> 0, 0
> };
>
> // I think the following code is how this SHOULD be according to
> // my interpretation of the standard:
> /*
> template<class T >
> const map_inner_t< T >
>     inner_implementation< T >::inner[] =
> {
> { 6, & T ::InnerHandler1 },
> { 7, & T ::InnerHandler2 },
> { 8, & T ::InnerHandler3 },
> { 0, 0 }
> };
> */

Actually, paragraph 11 of 8.5.1, Aggregates, says
<<Braces can be elided in an initializer-list as follows. If the
  initializer-list begins with a left brace, then the succeeding
  comma-separated list of initializers initializes the members of
  a subaggregate; it is erroneous for there to be more initializers
  than members. If, however, the initializer-list for a subaggregate
  does not begin with a left brace, then only enough initializers
  from the list are taken to initialize the members of the
  subaggregate; any remaining initializers are left to initialize
  the next member of the aggregate of which the current subaggregate
  is a member.>>

I think that according to that, it is possible to drop the inner
braces if you have the right number of initialisers.

Victor
--
Please remove capital A's from my address when replying by 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]