James Kuyper <kuyper@wizard.net> writes:
>> Keep in mind that #error and assert() both put user-defined text
>> into a diagnostic.

Fergus Henderson wrote:
>> You're right about #error, but assert() is defined to write text to
>> stderr, not to produce a diagnostic.

James Kuyper wrote:
> You're right - my apology. Stderr is the logical place for diagnostics
> to be sent, but that's not a requirement of the standard.

The difference, of course, is that #error produces diagnostics
during compilation, while assert() produces them during program
execution, which could exist in a completely different environment.

It makes sense for all diagnostics (except perhaps fatal internal
"should not occur" exceptions) of the compiler to be written to
stdout, since the output of the compiler is information about the
correctness of the user's program (as well as other output, such
as object files).

The runtime environment might not even have a working concept of
"standard error output stream".

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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@dresdner-bank.com wrote:
...
> Which raises another silly question: is a compiler which takes over a
> million years to compile hello world really conform, given that it
> will certainly never terminate correctly.

How do you know that that's a certainty? A high probability, I'll agree
- but not a certainty.

---
[ 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  wrote:

> It isn't even allowed to issue a diagnostic within the meaning of the
> term as applied to the Standard, they are just friendly warnings,
> questions and advice.

Actually, it is allowed to.

--

Valentin Bonnard

---
[ 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 <901mce$1prn$2@nef.ens.fr>, Valentin Bonnard
<Valentin.Bonnard@free.fr> writes
>Francis Glassborow  wrote:
>
>> It isn't even allowed to issue a diagnostic within the meaning of the
>> term as applied to the Standard, they are just friendly warnings,
>> questions and advice.
>
>Actually, it is allowed to.

Then the term diagnostic is vacuous (without substance). And as far as I
can see, most of you are arguing that I could say that the generation of
an executable is a diagnostic if I want to by virtue of the words
effective meaning being implementation defined.

>

Francis Glassborow      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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <902v1o$pd3$1@nnrp1.deja.com>, James.Kanze@dresdner-bank.com
writes
>Are you sure?  It isn't a required diagnostic, but it is still a
>diagnostic, I think.  And there is no requirement that the required
>diagnostic differ in any way from an optional one.  A compiler that
>always output '?' for all sources, and nothing else, would fulfill the
>requirements, provided that it documented the fact that '?' was a
>diagnostic in the sense of the standard.

Allowing implementations to issue diagnostics on well-formed programs
makes it impossible to fail a compiler for failing to diagnose non-well
formed programs. Just to be safe, always issue a diagnostic. Of course
there is still a requirement that it compile well-formed code, but that
is hardly enough.

This is all far from the question posed by the OP who seemed to think
that an error message and a warning were different in some way. They are
only different if I say they are :)


Francis Glassborow      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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Francis Glassborow  wrote:
> In article <901mce$1prn$2@nef.ens.fr>, Valentin Bonnard
> <Valentin.Bonnard@free.fr> writes

>>Actually, [the compiler] is allowed to [issue a diagnostic
>>at any time].
>
> Then the term diagnostic is vacuous (without substance).

Yes.

But it is not defect, by your definition.

--

Valentin Bonnard

---
[ 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.     ]

On Wed, 29 Nov 2000 23:22:13 GMT, Francis Glassborow
<francis.glassborow@ntlworld.com> wrote:

> Then the term diagnostic is vacuous (without substance). And as far as I
> can see, most of you are arguing that I could say that the generation of
> an executable is a diagnostic if I want to by virtue of the words
> effective meaning being implementation defined.

It's not that bad, really.  My favorite is the gcc (not any more)
warning about binding an rvalue to a non-const reference.  It issued
a diagnostic for an ill-formed program, yet produced an executable
which worked just fine since the value was not modified.  Gcc complied
by generating a diagnostic, yet accepted old, not const correct code.

John

---
[ 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 wrote:
...
> Then the term diagnostic is vacuous (without substance). And as far as I
> can see, most of you are arguing that I could say that the generation of
> an executable is a diagnostic if I want to by virtue of the words
> effective meaning being implementation defined.

The standard says that diagnostics are an implementation-defined subset
of an implementation's output messages. I don't see offhand how an
executable could count as a message, but I won't say that it's
impossible.

However, you've got the basic principle correct. The more freedom the
standard gives an implementation, the less useful the standard's
guarantees are to a programmer. The standard gives so much freedom in
the definition of diagnostics as to allow them to be quite useless. It's
purely a QoI issue whether they're any use whatsoever.

Let's look at it from the opposite point of view. If a message is a
diagnostic only if the standard makes it mandatory, then there's no way
to tell by looking at a message whether or not it's a diagnostic. All
real implementations of C++ issue some "Error" messages under
circumstances where it's unclear whether or not the diagnostic is
mandatory.

There's a simple reason for this; sometimes it's just too difficult to
determine whether or not a diagnostic is mandatory. Periodically someone
makes the claim that the C or C++ standard can't be implemented, because
deciding whether a given diagnostic is mandatory is mathematically
equivalent, in some circumstances, to solving the halting problem (in
fact, given that we're talking about a programming language, sometimes
it actually requires solving the halting problem.) The reason why those
people are wrong is that a diagnostic is never prohibited. Therefore,
it's sufficient to detect that situation, and issue a diagnostic,
whether or not it's 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.     ]

In article <7LXr+iB+6YJ6EwfN@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <901mce$1prn$2@nef.ens.fr>, Valentin Bonnard
> <Valentin.Bonnard@free.fr> writes
> >Francis Glassborow  wrote:

> >> It isn't even allowed to issue a diagnostic within the meaning of
> >> the term as applied to the Standard, they are just friendly
> >> warnings, questions and advice.

> >Actually, it is allowed to.

> Then the term diagnostic is vacuous (without substance).

Not at all.  A diagnostic is a message that the compiler is required,
in certain cases, to emit.  The fact that it is sometimes required to
emit the message does not forbid it from emitting it otherwise.  To be
conform, it is sufficient that a compiler *always* output a single '?'
when compiling, and that this be documented as the diagnostic for all
cases where the standard requires a diagnostic.  (And I stress the
"always"; the '?' is output, whether the compiler detects an error or
not.)  Furthermore, since the compiler can do whatever it wants if an
error actually occurs, or if any resource limits have been exceeded,
it could very easily generate an executable whose semantic had nothing
to do with the original program, say by generating a program which
formats the disk.

Finally, who is to say when the resource limits have been exceeded.
I'm not particularly gifted in space optimization, and my compiler
requires 2 Gigabytes of memory per user symbol.

Such a compiler would be conforming.  It probably wouldn't sell very
well, however.  So in the end, it is only market forces which protect
us.  (Which has always been true.  The only reason any compiler vendor
has to try for standards conformance is that it is a good selling
point.  And when full conformance might hurt sales, as is the case
with one compiler we know, conformance doesn't occur.)

> And as far as I can see, most of you are arguing that I could say
> that the generation of an executable is a diagnostic if I want to by
> virtue of the words effective meaning being implementation defined.

In the past, the C standards group have posed the question as to
whether lighting the lamp on the front of the disk for n seconds per
Gigabyte of disk would be an acceptable diagnostic (provide it is
documented as such).  Say by means of an external command "format
c:".  While such a compiler would probably be conforming, and would
certainly encourage care in writing the programs, I suspect that it
wouldn't sell particularly well.

--
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


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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 wrote:
>
> Allowing implementations to issue diagnostics on well-formed programs
> makes it impossible to fail a compiler for failing to diagnose non-well
> formed programs. Just to be safe, always issue a diagnostic.

Yes, that has always been the case. A compiler that always issued exactly
one message, "This program might contain errors," would conform to
all diagnosis requirements.  (It's an old joke in the C committee.)

Unless you also want to specify how messages are emitted and what form
they take, it's pretty hard to say more about diagnostic messages.

Even if we said that required diagnostics must be differentiated from
non-required messages, you still have the problem of determining
conformance when an erroneous program could be viewed in different ways,
with only some interpretations requiring a diagnostic message.

I think this area is best left entirely as a QOI issue, just as are
performance issues.

For comparison:  The standard places no limits on the resources
needed to compile or run a program. If an implementation required
100Gb of memory and 48 hours of computer time to compile the program
 int main() { }
it could still be conforming. I don't think we should try to write
language that renders the implementation non-conforming.

The marketplace can sort out implementations that correctly claim
conformance but aren't useful for real work. For that matter, it is
so difficult to produce a conforming implementation, a perverse
implementation that conforms but isn't useful is unlikely to be
produced.

--
Steve Clamage, stephen.clamage@sun.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.     ]

Francis Glassborow wrote:
...
> But they both issue diagnostics, what happens after that is entirely up
> to the compiler implementor. This is always the case, once a diagnostic
> is issued a compiler can stop or go on, there is no such thing as
> correct behaviour after a diagnostic.

Citation, please? An implementation is always free to issue diagnostics
for any reason whatsoever, even for strictly conforming code. That
doesn't release it from any of the other requirements imposed by the
standard.

There is also at least one case where a mandatory diagnostic also has
mandatory behavior following it. A call to assert() with a scalar
expression that evaluates to 0 is required to produce a diagnostic, and
is then required to call abort(). You'll have to cross-reference the C
standard to verify those requirements, but they are there. abort()
includes some implementation-defined choices, but it doesn't allow
undefined behavior.

---
[ 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 <3A2300CA.69F97FA4@wizard.net>, James Kuyper
<kuyper@wizard.net> writes
>Francis Glassborow wrote:
>...
>> But they both issue diagnostics, what happens after that is entirely up
>> to the compiler implementor. This is always the case, once a diagnostic
>> is issued a compiler can stop or go on, there is no such thing as
>> correct behaviour after a diagnostic.
>
>Citation, please? An implementation is always free to issue diagnostics
>for any reason whatsoever, even for strictly conforming code.

So? Did I say otherwise? What I wrote was that once it had issued a
diagnostic (and that includes warnings) it has fulfilled any obligation
it had to tell you that your code was not conforming. BTW, there is no
concept of 'strictly conforming' in C++.

>That
>doesn't release it from any of the other requirements imposed by the
>standard.
Where did I say otherwise?

>
>There is also at least one case where a mandatory diagnostic also has
>mandatory behavior following it. A call to assert() with a scalar
>expression that evaluates to 0 is required to produce a diagnostic, and
>is then required to call abort(). You'll have to cross-reference the C
>standard to verify those requirements, but they are there. abort()
>includes some implementation-defined choices, but it doesn't allow
>undefined behavior.

What does this have to do with compilation? That is a runtime
requirement.

Francis Glassborow      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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

also sprach Gianni Luciani <gianni.luciani@tiscalinet.it>:
>[C++ Warning] ProvaDerivazioneVirtual.h(52):
> W8024 Base class 'Start' is also a base class of 'MI'

declare the classes "public virtual", not just public.

martin

[greetings from the heart of the sun]# echo madduck@!#:1:s@\@@@.net
--
please keep your hands off the secretary's reproducing equipment.

---
[ 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 wrote:
>
> In article <3A2300CA.69F97FA4@wizard.net>, James Kuyper
> <kuyper@wizard.net> writes
> >Francis Glassborow wrote:
> >...
> >> But they both issue diagnostics, what happens after that is entirely up
> >> to the compiler implementor. This is always the case, once a diagnostic
> >> is issued a compiler can stop or go on, there is no such thing as
> >> correct behaviour after a diagnostic.
> >
> >Citation, please? An implementation is always free to issue diagnostics
> >for any reason whatsoever, even for strictly conforming code.
>
> So? Did I say otherwise? What I wrote was that once it had issued a
> diagnostic (and that includes warnings) it has fulfilled any obligation
> it had to tell you that your code was not conforming.

Yes, but if your code was well-formed, the implementation still has
obligations to fulfill even after issuing a diagnostic.

> ... BTW, there is no
> concept of 'strictly conforming' in C++.

My apologies; you're correct. I should have written "well-formed".

> >That
> >doesn't release it from any of the other requirements imposed by the
> >standard.
> Where did I say otherwise?

Where you said "there is no such thing as correct behavior after a
diagnostic."

Correct behavior after issuing the diagnostic means continuing to obey
all of the requirements imposed by the standard.

...
> What does this have to do with compilation? That is a runtime
> requirement.

It wasn't clear to me that your statement was intended to apply only to
compile-time diagnostics. However, that restriction doesn't help. The
obligations imposed on an implementation by the standard for well-formed
code are independent of whether or not that implementation chooses to
issue a diagnostic. It doesn't matter whether that diagnostic is issued
at compile-time, link-time, or run-time.

---
[ 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 <CTJlYJABZwI6EwxX@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <3A2300CA.69F97FA4@wizard.net>, James Kuyper
> <kuyper@wizard.net> writes
> >Francis Glassborow wrote:
> >...
> >> But they both issue diagnostics, what happens after that is
> >> entirely up to the compiler implementor. This is always the case,
> >> once a diagnostic is issued a compiler can stop or go on, there
> >> is no such thing as correct behaviour after a diagnostic.

> >Citation, please? An implementation is always free to issue
> >diagnostics for any reason whatsoever, even for strictly conforming
> >code.

> So? Did I say otherwise? What I wrote was that once it had issued a
> diagnostic (and that includes warnings) it has fulfilled any
> obligation it had to tell you that your code was not conforming.
> BTW, there is no concept of 'strictly conforming' in C++.

I don't agree.  A compiler is required to issue diagnostics for
certain error conditions.  Having done so, what happens next is
undefined.  A compiler is free to issue any additional diagnostics
that it wishes.  However, if the program is legal, it is not free to
do anything it wishes after issuing the diagnostics.

--
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


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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
<Pine.LNX.4.21.0011252013100.803-100000@deimos.solarsystem.gnu>,
  Gianni Luciani <gianni.luciani@tiscalinet.it> wrote:

> I have some questions for You:

It would be a lot easier if you'd post each question in a separate
article, with a relevant subject line.

> a) Why does not the C++ Standard impose a standard also for compiled
> objects to avoid problems trying to use a library compiled by a
> compiler with another ???

Because it isn't practical to do so across platforms.

>    For such purpose data type's dimensions could be 'fully
>    qualified' as for example int64, ... bool8, char16, (the number
>    meaning bits) and so on ...

Either you impose a strong performance cost on some platforms, by
requiring int32 (even though the platform has 36 bit words), or you
kill portability, by requiring the code to guess the number of bits on
the target platform.

> b) Why C++ built-in data types as ints, chars, pointers
> etc... aren't initialized to a default value as in Java ?

They are, in certain cases.  In Java, they aren't *always* initialized
either, although the compiler is required to generate an error if it
cannot prove that they will be initialized before use.  The major case
where they are initialized in Java, but not in C++, is in class
objects.  In Java, it is absolutly imperitive that they be
initialized, since the virtual function mechanism allows calling a
function of an otherwise unconstructed type.  C++ doesn't have this
problem, so the initialization isn't as critical.

> c) this is a 'big compound multiquestion' that arose from the
> following context:

> given the following class hierarchy (borrowed almost as is from
> an Exsercise at pag. 1004 of Lippman's 3rd edition book 'C++ Primer')

> class Start { ... };

> class Base : public Start { ... };

> class Derived1 : virtual public Base { ... };

> class Derived2 : virtual public Base { ... };

> class MI : public Derived1, public Derived2 { ... };

> class Final : public MI, public Start { ... };
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

> and trying to compile it with Borland C++Builder 5.0 Service Pack 1,
> I obtain the following warning :

> [C++ Warning] ProvaDerivazioneVirtual.h(52):
>  W8024 Base class 'Start' is also a base class of 'MI'

> while trying to compile it with VC++ 6.0 Service Pack 'I don't
> remember, but almost surely one of the last currently available' I
> obtain the following Error code :

> c:\pal\provastampa\provaderivazionevirtual.h(56) :
> error C2584: 'Final' : direct base 'Start' is inaccessible;
> already a base of 'MI'

> What's the correct behaviour ? The Inprise's compiler one, or the
> M$'s compiler one ?

I think that the code is wrong.  Since both compilers issue a
diagnostic, both are correct.

> Then I would like to throw another question:
>    why isn't possible to use the resolution operator ( :: ) to
>    disambiguate the above situation.

Because Start:: is ambiguous.  There are two instances of Start in the
object.  MI::Start:: is not ambiguous, but there is no way, with the
immediate hierarchy, of specifying the other Start.

The obvious solution is to introduce an intermediate class:

  class RenamedStart : public Start {} ;

  class Final : public MI, public RenamedStart {} ;

This should eliminate the diagnostics, since there is only one Start
whose constructor should be called by Final directly (the virtually
inherited one), and you can disambiguate any other use by means of
MI::Start or RenamedStart::Start.

> for example stating that if pun is a Final * then
> pun->::Start::m_member1 will refer to Start member of Final directly
> accessible from the 'surface' of the object, while for example
> pun->::MI::Start ... will refer the member of the virtual inherited
> block ?  Also pun->::m_member will address a class own member while
> pun->m_member will address the possibly inherited one ?  Could the
> above approach be feasible in terms of efficiency, language
> implementation complexity etc ... ?  If this is the case why wasn't
> it be taken into account ?  On the contrary what are the main
> reasons for not allowing the above syntax ??

Why bother?  The solution, as described doesn't work, since the :: in
this case says to start looking at file scope, and not within the
hierarchy.  The problem is exceedingly rare in real code, and there is
a simple work-around.

> I also have some questions for the case one decide not to use
> virtual inheritance in the example above and so allows more than a
> copy of a Start or Base object into a derived one.

> How can I get the address of a subobject of class Derived1::Start or
> Base in case I don't use virtual inheritance ?

By using scope resolution operators to walk down the hierarchy.

> I was thinking of something like the following:
> Final aFinal;
> Derived1 * p  = &aFinal;
> Derived2 * p2 = &aFinal;
> Base * bp = p;
> Base * bp2 = p2;
> Start1 * sp1 = p;
> Start2 * sp2 = p2;

> but with VC++ 6.0 p, bp and sp1 have the same value !  and p2, bp2
> and sp2 have the same value! Is this correct ??

It might be.  The standard doesn't impose any particular layout, but
off hand, that would be what I would expect.

> Well I know that the following will work correctly:

> Final aFinal;
> Start aStart;
> Derived1 * p  = &aFinal;
> Derived2 * p2 = &aFinal;
>
> aStart.operator=(*p);// Will copy Start SubObject of Final's Derived1
SubObject
> aStart.operator=(*p2);// Will copy Start SubObject of Final's Derived2
SubObject

> while the following does the contrary:
> p->Start::operator=(aStart);// will call operator=() of Start
subobject of SubObject Derived1
> p2->Start::operator=(aStart);// ... Derived2
>
> Is this correct ???

Yes.

> Is the following statement correct ?

> aFinal::Derived1::Start::operator=() ???

> VC++ 6.0 flags it as an error:
> error C2039: 'Start' : is not a member of 'Derived1', is this correct
?

Not unless you've modified the code above other than by removing the
virtual from the inheritance.

--


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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 <3A232560.517F90E6@wizard.net>, James Kuyper
<kuyper@wizard.net> writes
>Where you said "there is no such thing as correct behavior after a
>diagnostic."

Not all messages are diagnostics within the meaning of the act. A
warning issued on well-formed code is just that and not a diagnostic.

>
>Correct behavior after issuing the diagnostic means continuing to obey
>all of the requirements imposed by the standard.

But if it is a diagnostic the code was not well formed.


Francis Glassborow      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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <900ko6$tgu$1@nnrp1.deja.com>, James.Kanze@dresdner-bank.com
writes
> However, if the program is legal, it is not free to
>do anything it wishes after issuing the diagnostics.

It isn't even allowed to issue a diagnostic within the meaning of the
term as applied to the Standard, they are just friendly warnings,
questions and advice.


Francis Glassborow      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://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:

>James Kuyper <kuyper@wizard.net> writes
>>Where you said "there is no such thing as correct behavior after a
>>diagnostic."
>
>Not all messages are diagnostics within the meaning of the act.

That's true, in general.

>A warning issued on well-formed code is just that and not a diagnostic.

Whether or not any given message is a diagnostic is implementation-defined.
An implementation is free to define a warning that it issues on
well-formed code (e.g. "warning: today is wednesday") as a diagnostic
if it wishes.  See 1.3.2 [defns.diagnostic].

>>Correct behavior after issuing the diagnostic means continuing to obey
>>all of the requirements imposed by the standard.
>
>But if it is a diagnostic the code was not well formed.

I'm pretty sure you're wrong about that.  Please cite chapter and verse.
The defition of "diagnostic" just says that it is implementation-defined
and does not say anything that would restrict a compiler from issuing
diagnostics for code that is well-formed.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

---
[ 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 <ETtkYEBWMAJ6EwYg@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <900ko6$tgu$1@nnrp1.deja.com>,
James.Kanze@dresdner-bank.com
> writes
> > However, if the program is legal, it is not free to
> >do anything it wishes after issuing the diagnostics.

> It isn't even allowed to issue a diagnostic within the meaning of
> the term as applied to the Standard, they are just friendly
> warnings, questions and advice.

Are you sure?  It isn't a required diagnostic, but it is still a
diagnostic, I think.  And there is no requirement that the required
diagnostic differ in any way from an optional one.  A compiler that
always output '?' for all sources, and nothing else, would fulfill the
requirements, provided that it documented the fact that '?' was a
diagnostic in the sense 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


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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 wrote:
>
> In article <3A232560.517F90E6@wizard.net>, James Kuyper
> <kuyper@wizard.net> writes
> >Where you said "there is no such thing as correct behavior after a
> >diagnostic."
>
> Not all messages are diagnostics within the meaning of the act. A
> warning issued on well-formed code is just that and not a diagnostic.

The standard says defines a diagnostic as  (1.3.2) "a message belonging
to an implementation-defined subset of an implementation's output
messages". It says that (1.4p2) "If a program contains a violation of
any diagnosable rule, a conforming implementation shall issue at least
one diagnostic message, ...". In context, it would seem that "any
diagnosable rule" refers only to rules contained in the standard itself;
but I could be mistaken in that interpretation.

It also gives a large number of cases where a diagnostic is not
required. It never prohibits diagnostics, and it says nothing to
indicate that a message is a diagnostic only if it's mandatory. Can you
point to any section of the standard that is violated by an
implementation that exercises it's right to define the subset, by
defining it to include messages that are not mandatory diagnostics?

> >Correct behavior after issuing the diagnostic means continuing to obey
> >all of the requirements imposed by the standard.
>
> But if it is a diagnostic the code was not well formed.

Citation please?

---
[ 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@dresdner-bank.com wrote:

[...]

> In the C group, I once heard it proposed that the diagnostic could be
> that your hard disk is reformatted.  I suppose that if it is
> documented, that would also be conform.

It certainly would make programmers be very careful to write
error-free programs (and to make regular backups) ;-)

BTW: Does the standard demand the diagnostic in finite time?
Otherwise we could define "the compiler never finishes" as a diagnostic.
;-)

---
[ 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.     ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:

| James.Kanze@dresdner-bank.com wrote:
|
| [...]
|
| > In the C group, I once heard it proposed that the diagnostic could be
| > that your hard disk is reformatted.  I suppose that if it is
| > documented, that would also be conform.
|
| It certainly would make programmers be very careful to write
| error-free programs (and to make regular backups) ;-)

Hmm, that would imply that C++ does not fully support the Debugger
Oriented Programming paradigm ;-)

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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 <3A2BF0AB.FA22B793@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> James.Kanze@dresdner-bank.com wrote:

> [...]

> > In the C group, I once heard it proposed that the diagnostic could
> > be that your hard disk is reformatted.  I suppose that if it is
> > documented, that would also be conform.

> It certainly would make programmers be very careful to write
> error-free programs (and to make regular backups) ;-)

> BTW: Does the standard demand the diagnostic in finite time?
> Otherwise we could define "the compiler never finishes" as a
> diagnostic.  ;-)

In reality, all programs finish running in a finite time.  At least on
any of the hardware I've ever seen; if the program's logic doesn't
stop it, sooner or later hardware failure does.

Which raises another silly question: is a compiler which takes over a
million years to compile hello world really conform, given that it
will certainly never terminate correctly.

--
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


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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 <kuyper@wizard.net> writes:

| Francis Glassborow wrote:
| ...
| > Then the term diagnostic is vacuous (without substance). And as far as I
| > can see, most of you are arguing that I could say that the generation of
| > an executable is a diagnostic if I want to by virtue of the words
| > effective meaning being implementation defined.
|
| The standard says that diagnostics are an implementation-defined subset
| of an implementation's output messages. I don't see offhand how an
| executable could count as a message, but I won't say that it's
| impossible.

I guess that depends on the meaning of "message".  Does an
implementation which documents "putting on the green led is a
diagnostic" conform to the Standard?  Does an
implementation which documents "not producing an executable is a
diagnostic" conform to the Standard?

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.     ]

Steve Clamage wrote:
>
> Francis Glassborow wrote:
> >
> > Allowing implementations to issue diagnostics on well-formed programs
> > makes it impossible to fail a compiler for failing to diagnose non-well
> > formed programs. Just to be safe, always issue a diagnostic.
>
> Yes, that has always been the case. A compiler that always issued exactly
> one message, "This program might contain errors," would conform to
> all diagnosis requirements.  (It's an old joke in the C committee.)

I used to use an F77 compiler that issued the message:

 "None of the errors detected."

when it ran.

I thought it was extremely realistic in the fact that it wasn't going
to pronounce my programs error free, even when they were entirely
syntactically correct.

---
[ 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.     ]

Gabriel Dos_Reis wrote:
...
> I guess that depends on the meaning of "message".  Does an
> implementation which documents "putting on the green led is a
> diagnostic" conform to the Standard?  Does an

I think so. I've heard denials of that claim, however.

Keep in mind that #error and assert() both put user-defined text into a
diagnostic. While a single LED would suffice for most mandatory
diagnostics, an implementation must provide some means of displaying
diagnostics containing arbitrary text strings. Maybe it could make the
LED blink in Morse code?

> implementation which documents "not producing an executable is a
> diagnostic" conform to the Standard?

That's less clear to me, but that is certainly pushing the limit of the
concept.

---
[ 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 <3A26B067.7191C4A9@sensor.com>, Ron Natalie  <ron@sensor.com> wrote:
>I used to use an F77 compiler that issued the message:
>
> "None of the errors detected."
>
>when it ran.
>
>I thought it was extremely realistic in the fact that it wasn't going
>to pronounce my programs error free, even when they were entirely
>syntactically correct.

Now if that isn't cute, what is?  :)

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: 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 Kuyper <kuyper@wizard.net> writes:

>Gabriel Dos_Reis wrote:
>...
>> I guess that depends on the meaning of "message".  Does an
>> implementation which documents "putting on the green led is a
>> diagnostic" conform to the Standard?  Does an
>
>I think so. I've heard denials of that claim, however.
>
>Keep in mind that #error and assert() both put user-defined text into a
>diagnostic.

You're right about #error, but assert() is defined to write text to
stderr, not to produce a diagnostic.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

---
[ 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.     ]

Fergus Henderson wrote:
>
> James Kuyper <kuyper@wizard.net> writes:
>
> >Gabriel Dos_Reis wrote:
...
> >Keep in mind that #error and assert() both put user-defined text into a
> >diagnostic.
>
> You're right about #error, but assert() is defined to write text to
> stderr, not to produce a diagnostic.

You're right - my apology. Stderr is the logical place for diagnostics
to be sent, but that's not a requirement of the standard.

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

In article <xajwvdl9o63.fsf@korrigan.inria.fr>,
  Gabriel Dos_Reis <gdosreis@korrigan.inria.fr> wrote:
> James Kuyper <kuyper@wizard.net> writes:

> | Francis Glassborow wrote:
> | ...
> | > Then the term diagnostic is vacuous (without substance). And as
> | > far as I can see, most of you are arguing that I could say that
> | > the generation of an executable is a diagnostic if I want to by
> | > virtue of the words effective meaning being implementation
> | > defined.

> | The standard says that diagnostics are an implementation-defined
> | subset of an implementation's output messages. I don't see offhand
> | how an executable could count as a message, but I won't say that
> | it's impossible.

> I guess that depends on the meaning of "message".  Does an
> implementation which documents "putting on the green led is a
> diagnostic" conform to the Standard?  Does an implementation which
> documents "not producing an executable is a diagnostic" conform to
> the Standard?

The "message" is anything the implementation documents as a message.
Suppose an implementation outputs all diagnostics to a disk file, and
doesn't generate the file if there are no diagnostics.  I would
certainly hope that would be legal, although the absense of the file
is certainly a "message" in some sense.  Suppose that the implemtation
has only one diagnostic message, and stops after the first error.  In
that case, either the file is present, with the one predefined
message, or it is absent.  And we are still definitly conforming.  Now
inverse the conditions: the "diagnostic" is the absense of the file
(which, for arguments sake, normally contains the message "no errors
found").  Where is the semantic difference?  And so on.  The standard
makes no attempt to draw the line.

In the C group, I once heard it proposed that the diagnostic could be
that your hard disk is reformatted.  I suppose that if it is
documented, that would also be conform.

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


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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.     ]

Hallo,

I have some questions for You:

a) Why does not the C++ Standard impose a standard also for compiled objects
   to avoid problems trying to use a library compiled by a compiler with
   another ???
   For such purpose data type's dimensions could be 'fully qualified' as for
   example int64, ... bool8, char16, (the number meaning bits) and so on ...

b) Why C++ built-in data types as ints, chars, pointers etc... aren't initialized
   to a default value as in Java ?

c) this is a 'big compound multiquestion' that arose from the following
context:

given the following class hierarchy (borrowed almost as is from
an Exsercise at pag. 1004 of Lippman's 3rd edition book 'C++ Primer')

class Start { ... };

class Base : public Start { ... };

class Derived1 : virtual public Base { ... };

class Derived2 : virtual public Base { ... };

class MI : public Derived1, public Derived2 { ... };

class Final : public MI, public Start { ... };

and trying to compile it with Borland C++Builder 5.0 Service Pack 1,
I obtain the following warning :

[C++ Warning] ProvaDerivazioneVirtual.h(52):
 W8024 Base class 'Start' is also a base class of 'MI'

while trying to compile it with VC++ 6.0
Service Pack 'I don't remember, but almost surely one of the last currently available'
I obtain the following Error code :

c:\pal\provastampa\provaderivazionevirtual.h(56) :
error C2584: 'Final' : direct base 'Start' is inaccessible;
already a base of 'MI'

What's the correct behaviour ? The Inprise's compiler one, or the M$'s compiler one ?

Then I would like to throw another question:
   why isn't possible to use the resolution operator ( :: ) to disambiguate
   the above situation for example stating that if pun is a Final * then
   pun->::Start::m_member1 will refer to Start member of Final directly
   accessible from the 'surface' of the object, while for example
   pun->::MI::Start ... will refer the member of the virtual inherited block ?
   Also pun->::m_member will address a class own member while
   pun->m_member will address the possibly inherited one ?
   Could the above approach be feasible in terms of efficiency,
   language implementation complexity etc ... ?
   If this is the case why wasn't it be taken into account ?
   On the contrary what are the main reasons for not allowing the above
   syntax ??


I also have some questions for the case one decide not to use virtual
inheritance in the example above and so allows more than a copy of a
Start or Base object into a derived one.


How can I get the address of a subobject of class Derived1::Start
or Base in case I don't use virtual inheritance ?

I was thinking of something like the following:
Final aFinal;
Derived1 * p  = &aFinal;
Derived2 * p2 = &aFinal;
Base * bp = p;
Base * bp2 = p2;
Start1 * sp1 = p;
Start2 * sp2 = p2;

but with VC++ 6.0 p, bp and sp1 have the same value !
and p2, bp2 and sp2 have the same value! Is this correct ??

Well I know that the following will work correctly:

Final aFinal;
Start aStart;
Derived1 * p  = &aFinal;
Derived2 * p2 = &aFinal;

aStart.operator=(*p);// Will copy Start SubObject of Final's Derived1 SubObject
aStart.operator=(*p2);// Will copy Start SubObject of Final's Derived2 SubObject

while the following does the contrary:
p->Start::operator=(aStart);// will call operator=() of Start subobject of SubObject Derived1
p2->Start::operator=(aStart);// ... Derived2

Is this correct ???

Is the following statement correct ?

aFinal::Derived1::Start::operator=() ???

VC++ 6.0 flags it as an error:
error C2039: 'Start' : is not a member of 'Derived1', is this correct ?

Well that's all !!!
I Hope You understand what I mean !

Best Regards and thank You very much in advance

Gianni Luciani
gianni.luciani@tiscalinet.it

---
[ 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 <Pine.LNX.4.21.0011252013100.803-100000@deimos.solarsystem.gn
u>, Gianni Luciani <gianni.luciani@tiscalinet.it> writes
>Hallo,
>
>I have some questions for You:

Well I am not going to cover the whole lot (it would be generally better
to break questions up into more digestible chunks)

>
>a) Why does not the C++ Standard impose a standard also for compiled objects
>   to avoid problems trying to use a library compiled by a compiler with
>   another ???

Because that would impose constraints that most implementors do not
want. In addition, it would effectively require that all platforms were
the same (e.g. via something such as the JVM)

>   For such purpose data type's dimensions could be 'fully qualified' as for
>   example int64, ... bool8, char16, (the number meaning bits) and so on ...

And how many types do you want? C99 is exploring this, but I do not
think it delivers very much of real use.

>
>b) Why C++ built-in data types as ints, chars, pointers etc... aren't
>initialized
>   to a default value as in Java ?

But they are:) It is local values that are not initialised and that is a
performance choice. Initialisation of local variables can be expensive
for large arrays. C++, like C, treats programmers as responsible adults
who are able to make their own decisions.


>
>c) this is a 'big compound multiquestion' that arose from the following
>context:
>
>given the following class hierarchy (borrowed almost as is from
>an Exsercise at pag. 1004 of Lippman's 3rd edition book 'C++ Primer')
>
>class Start { ... };
>
>class Base : public Start { ... };
>
>class Derived1 : virtual public Base { ... };
>
>class Derived2 : virtual public Base { ... };
>
>class MI : public Derived1, public Derived2 { ... };
>
>class Final : public MI, public Start { ... };

The problem with this is that it now has Start as a direct base twice.
Once as the virtual base of Derived1 and Derived2 and once as a non-
virtual base. That means that all uses of members of Start() in MI are
ambiguous. I am pretty sure that needs a diagnostic.

>
>and trying to compile it with Borland C++Builder 5.0 Service Pack 1,
>I obtain the following warning :
>
>[C++ Warning] ProvaDerivazioneVirtual.h(52):
> W8024 Base class 'Start' is also a base class of 'MI'

That is a diagnostic.
>
>while trying to compile it with VC++ 6.0
>Service Pack 'I don't remember, but almost surely one of the last currently
>available'
>I obtain the following Error code :
>
>c:\pal\provastampa\provaderivazionevirtual.h(56) :
>error C2584: 'Final' : direct base 'Start' is inaccessible;
>already a base of 'MI'
And so is that.
>
>What's the correct behaviour ? The Inprise's compiler one, or the M$'s compiler
>one ?

But they both issue diagnostics, what happens after that is entirely up
to the compiler implementor. This is always the case, once a diagnostic
is issued a compiler can stop or go on, there is no such thing as
correct behaviour after a diagnostic.


Francis Glassborow      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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <Pine.LNX.4.21.0011252013100.803-100000@deimos.solarsystem.gn
u>, Gianni Luciani <gianni.luciani@tiscalinet.it> writes

  <snip>
>b) Why C++ built-in data types as ints, chars, pointers etc... aren't
>initialized
>   to a default value as in Java ?
  <snip>

Because some of us don't like compilers that add redundant instructions.
Also, because some of us think that if something needs initialising then
the source code should say so explicitly.

Some _are_ initialised, by the way.

  John
--
John Harris
  mailto:john@jgharris.demon.co.uk

---
[ 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.     ]

Would some kind soul e-mail me a copy of the C++ FAQ. I don't have FTP ...

Thanx.