Loki vs EDG on legal template definition

On Aug 30, 11:28 am, gm...@ti.com wrote:
> Hello,
>
> I've come across a disagreement between the EDG parser (version 3.8)
> and the Loki library (version 0.1.6). I have been unable to find a
> clause in the C++ standard which clearly says who is correct. Help!
[...snip...]
> This builds fine when I use EDG default settings. But if I enable
> strict ANSI/ISO mode (-A), then I get ...
>
> "file.cpp", line 21: error: incomplete type is not allowed
> Loki::CompileTimeError<((0) != 0)> ERROR_msg;
> ^
>
> So, who is incorrect? EDG or Loki?
>
> I have looked through the templates part of the standard for an
> answer. It is probably there, and I just can't find it. The closest
> I come is section 14.7.1/6 which says: "If an implicit instantiation
> of a class template specialization is required and the template is
> declared but not defined, the program is ill formed." The second part
> of that statement is definitely true. I'm less sure about the first.
> I understand that template definition processing is a bit odd from a
> compiler viewpoint. Some things do have to be defined and in scope,
> particularly those which do not depend any template parameters. And
> the CompileTimeError template does not depend on T. So that is my
> basis for saying that EDG is correct in complaining that, while there
> is a declaration for CompileTimeError, there is no definition.
>
> Thus, I conclude the Loki library is in error. Obviously, I'm not
> confident of that conclusion. That's why I seek more input.

The code is ill-formed, with the diagnostic permitted but not
required. The relevant text is in 14.6 paragraph 8. The wording
is a little confusing, but the basic idea is that if a type used in
declaring a non-dependent name (like ERROR_msg in your example) is
incomplete at the point of the template definition and the declaration
requires the type to be complete, the program is ill-formed, no
diagnostic required. (This applies even if the type is completed
before any instantiation.) So the Loki library needs to find a
different mechanism for its error reporting.

--
William M. (Mike) Miller | Edison Design Group
william.m.miller@gmail.com


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

on Tue Sep 02 2008, Jiang <goo.mail01-AT-yahoo.com> wrote:

>> ICL intentionally emulates all the bugs in MSVC.
>>
>
> I was surprised by this news, do you have any hard data ?

Years of personal experience. It's also a well known fact.

> Somehow I see why icl disabled support for "export", but are there
> any reasons for icl to emulate all the bugs in MSVC( C++ parts).

You'll have to ask Intel, but "run your existing MSVC++ code without
modification and it will get faster" seems like a likely reason to me.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 2, 3:44 pm, Jiang <goo.mai...@yahoo.com> wrote:
> On Sep 2, 4:40 pm, David Abrahams <d...@boostpro.com> wrote:
> > on Tue Sep 02 2008, Jiang <goo.mail01-AT-yahoo.com> wrote:
>
> > > Then would you please tell me why icl, another compiler usesEDG
> > > front-end, and como non-strict mode accept above code?
>
> > ICL intentionally emulates all the bugs in MSVC.
>
> I was surprised by this news, do you have any hard data ?
>
> Somehow I see why icl disabled support for "export", but are there
> any reasons for icl to emulate all the bugs in MSVC( C++ parts).

(Please note that I do not, and cannot, speak for Intel.
I'm only talking about our front end here.)

The front end we supply has a number of different modes that
affect which kinds of source constructs are accepted and which
are diagnosed as errors. We emulate, very closely, the
Microsoft and GNU dialects (in various versions -- the
language accepted by g++ 3.3 is different in a number of ways
from that accepted by g++ 4.0, for instance). We also have
significant support for the Sun C++ compiler. The reason for
this is that there is a lot of code out there that was written
by people using those compilers who don't know, or don't care,
what is Standard C++ and what is not, so that their code uses
vendor-specific extensions and may (perhaps inadvertently) rely
on compiler bugs. This most definitely includes the header
files supplied with the compilers.

Some of our customers, particularly hardware vendors, are able
to control their environment sufficiently that dialect emulation
doesn't matter all that much to them; they supply their own
language and system header files, for instance. Most of our
customers, however, must live in the native language environment,
either Windows or GNU: they provide alternative compilers that
are supposed to work like MSVC or gcc, or they have source
analysis or transformation tools, and so they have to accept the
headers and programs that were written for the dominant compiler
in that environment.

In addition to these emulations of specific versions of specific
compilers, we also supply what we call "default" and "strict"
modes. Our "strict" mode attempts to diagnose as many violations
of the Standard as possible; the "default" mode is more relaxed
so that a wider range of existing source code (that was written
using compilers that don't rigorously enforce the Standard) can
be compiled without error.

Our customers, of course, are free to choose any of these modes
for their products, depending on their needs. (If you recall,
the OP mentioned that they supply their compiler, based on our
front end, to their customers with "strict" mode enabled by
default.)

> > como non-strict mode is, well, non-strict. That seems self-explanatory
> > to me.
>
> My point is, although front-end maybe is the heart of a C++ compiler,
> they are different and it is possible we have different results with
> different compiler/options based on the same front-end.

Yes, that's true. In addition to the dialect emulations I mentioned
above, our customers receive the complete source code for our front
end. Many, if not most, of our customers do make changes that affect
the specific language constructs their products accept. There's also
the fact that different customers adopt new releases at different
rates, which can cause differences between their products. My
impression, though, is that these differences tend to be minor (I
can't speak definitively on this, as we don't monitor our customers'
products).

--
William M. (Mike) Miller | Edison Design Group
william.m.miller@gmail.com


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Thank you all for your assistance. I've learned a lot.

The post by Richard Corden, with the quote from section 14.6/7, really
nailed it for me. When my customers ask me about this situation, that
is the section I will quote.

And, I've found an answer that satisfies me. The Boost library has a
similar macro named BOOST_STATIC_ASSERT. Presuming you have Boost
installed at "root", you can find BOOST_STATIC_ASSERT documented at a
location similar to root\boost_1_34_1\doc\html
\boost_staticassert.html. At the end, it talks about how some
compilers may complain about use of the macro within a template
definition. It suggests writing BOOST_STATIC_ASSERT(sizeof(T) == 0).
Because the names defined in the macro now refer to template parameter
T, the name lookup is delayed from template definition to template
instantiation. This technique works with LOKI_STATIC_CHECK too. Yes!

Thanks again ...

-George

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

on Wed Sep 03 2008, gmock-AT-ti.com wrote:

> Thank you all for your assistance. I've learned a lot.
>
> The post by Richard Corden, with the quote from section 14.6/7, really
> nailed it for me. When my customers ask me about this situation, that
> is the section I will quote.
>
> And, I've found an answer that satisfies me. The Boost library has a
> similar macro named BOOST_STATIC_ASSERT.

It also has the mpl assertions, which generate much better error
messages.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 4, 5:50 am, william.m.mil...@gmail.com wrote:
> On Sep 2, 3:44 pm, Jiang <goo.mai...@yahoo.com> wrote:
>
> > On Sep 2, 4:40 pm, David Abrahams <d...@boostpro.com> wrote:
> > > on Tue Sep 02 2008, Jiang <goo.mail01-AT-yahoo.com> wrote:
>
> > > > Then would you please tell me why icl, another compiler usesEDG
> > > > front-end, and como non-strict mode accept above code?
>
> > > ICL intentionally emulates all the bugs in MSVC.
>
> > I was surprised by this news, do you have any hard data ?
>
> > Somehow I see why icl disabled support for "export", but are there
> > any reasons for icl to emulate all the bugs in MSVC( C++ parts).
>
> (Please note that I do not, and cannot, speak for Intel.
> I'm only talking about our front end here.)
>
> The front end we supply has a number of different modes that
> affect which kinds of source constructs are accepted and which
> are diagnosed as errors. We emulate, very closely, the
> Microsoft and GNU dialects (in various versions -- the
> language accepted by g++ 3.3 is different in a number of ways
> from that accepted by g++ 4.0, for instance). We also have
> significant support for the Sun C++ compiler. The reason for
> this is that there is a lot of code out there that was written
> by people using those compilers who don't know, or don't care,
> what is Standard C++ and what is not, so that their code uses
> vendor-specific extensions and may (perhaps inadvertently) rely
> on compiler bugs. This most definitely includes the header
> files supplied with the compilers.
>
> Some of our customers, particularly hardware vendors, are able
> to control their environment sufficiently that dialect emulation
> doesn't matter all that much to them; they supply their own
> language and system header files, for instance. Most of our
> customers, however, must live in the native language environment,
> either Windows or GNU: they provide alternative compilers that
> are supposed to work like MSVC or gcc, or they have source
> analysis or transformation tools, and so they have to accept the
> headers and programs that were written for the dominant compiler
> in that environment.
>
> In addition to these emulations of specific versions of specific
> compilers, we also supply what we call "default" and "strict"
> modes. Our "strict" mode attempts to diagnose as many violations
> of the Standard as possible; the "default" mode is more relaxed
> so that a wider range of existing source code (that was written
> using compilers that don't rigorously enforce the Standard) can
> be compiled without error.
>
> Our customers, of course, are free to choose any of these modes
> for their products, depending on their needs. (If you recall,
> the OP mentioned that they supply their compiler, based on our
> front end, to their customers with "strict" mode enabled by
> default.)
>

Thanks for elaborating on this issue.

Form the page of EDG, I also found that

[quote EDG]

A Microsoft C and C++ compatibility mode, which provides the
extensions supported by the Microsoft Visual C++ compiler
(through version 8.0, except for the Managed C++ extensions),
along with various undocumented features and bugs.

[end quote]

Yes, it seems that icl does emulate some bugs of visual C++,
but not all of them, right? ;-)

> > > como non-strict mode is, well, non-strict. That seems self-explanatory
> > > to me.
>
> > My point is, although front-end maybe is the heart of a C++ compiler,
> > they are different and it is possible we have different results with
> > different compiler/options based on the same front-end.
>
> Yes, that's true. In addition to the dialect emulations I mentioned
> above, our customers receive the complete source code for our front
> end. Many, if not most, of our customers do make changes that affect
> the specific language constructs their products accept. There's also
> the fact that different customers adopt new releases at different
> rates, which can cause differences between their products. My
> impression, though, is that these differences tend to be minor (I
> can't speak definitively on this, as we don't monitor our customers'
> products).

The previous post by David Abrahams surprised me because
I found icl can detect and diagnose quite a few bugs that can not
be done with visual C++. For the standard compliance issue,
icl is always better than visual C++ in my mind. However, I must say
for real-world code, especially for legacy code, standard compliance
has quite low priority.

Thank you and Dave for pointing this out.

> William M. (Mike) Miller | Edison Design Group

Regards,

Jiang


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 4, 5:29 am, Jiang <goo.mai...@yahoo.com> wrote:
> Yes, it seems that icl does emulate some bugs of visual C++,
> but not all of them, right? ;-)

Again, I can't say for certain what icl does or does not do.
With respect to the EDG front end, what we try to do is to
emulate all the significant bugs of our target compilers. A
bug is "significant" if some widely-used library (like the
headers supplied by the vendor or that are part of some popular
commercial or open-source package) relies on it or if it shows
up frequently in user code. We are also sensitive to our
customers' needs -- if they have a million-dollar sale that is
in danger because their prospect's code happens to use some
particular idiosyncrasy of the compiler on their system, we
will try very hard to emulate that peculiarity, as opposed to
some obscure glitch that happened to turn up in an artificial
test suite and has never been seen in real-world code.

But you're right -- the only way to be completely bug-for-bug
compatible with some other compiler would be to use the source
code for that compiler, and we obviously don't do that. We
try to be as close as pragmatically possible, though.

--
William M. (Mike) Miller | Edison Design Group
william.m.miller@gmail.com


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

gmock@ti.com wrote:
> Thank you all for your assistance. I've learned a lot.
>
> The post by Richard Corden, with the quote from section 14.6/7, really
> nailed it for me. When my customers ask me about this situation, that
> is the section I will quote.

Hmm.

> And, I've found an answer that satisfies me.

But not the standard.

> The Boost library has a
> similar macro named BOOST_STATIC_ASSERT. Presuming you have Boost
> installed at "root", you can find BOOST_STATIC_ASSERT documented at a
> location similar to root\boost_1_34_1\doc\html
> \boost_staticassert.html. At the end, it talks about how some
> compilers may complain about use of the macro within a template
> definition. It suggests writing BOOST_STATIC_ASSERT(sizeof(T) == 0).

Now, let me re-quote the section you intend to quote:

If no valid specialization can be generated for a template
definition, and that template is not instantiated, the template
definition is ill-formed, no diagnostic required.

--
Gennaro Prota | name.surname yahoo.com
Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Sep 6, 6:55 am, Gennaro Prota <gennaro/pr...@yahoo.com> wrote:
> gm...@ti.com wrote:
> > Thank you all for your assistance. I've learned a lot.
>
> > The post by Richard Corden, with the quote from section 14.6/7, really
> > nailed it for me. When my customers ask me about this situation, that
> > is the section I will quote.
>
> Hmm.
>
> > And, I've found an answer that satisfies me.
>
> But not the standard.
>
> > The Boost library has a
> > similar macro named BOOST_STATIC_ASSERT. Presuming you have Boost
> > installed at "root", you can find BOOST_STATIC_ASSERT documented at a
> > location similar to root\boost_1_34_1\doc\html
> > \boost_staticassert.html. At the end, it talks about how some
> > compilers may complain about use of the macro within a template
> > definition. It suggests writing BOOST_STATIC_ASSERT(sizeof(T) == 0).
>
> Now, let me re-quote the section you intend to quote:
>
> If no valid specialization can be generated for a template
> definition, and that template is not instantiated, the template
> definition is ill-formed, no diagnostic required.
>


[quote 14.6/p7, (p8 in N2723) ]

Knowing which names are type names allows the syntax of every
template definition to be checked. No diagnostic shall be
issued for a template definition for which a valid
specialization can be generated. If no valid specialization
can be generated for a template definition, and that template
is not instantiated, the template definition is ill-formed,
no diagnostic required. If a type used in a non-dependent
name is incomplete at the point at which a template is
defined but is complete at the point at which an instantiation
is done, and if the completeness of that type affects whether
or not the program is well-formed or affects the semantics
of the program, the program is ill-formed; no diagnostic is
required. [ Note: if a template is instantiated, errors will
be diagnosed according to the other rules in this Standard.
Exactly when these errors are diagnosed is a quality of
implementation issue. —end note ]

[end quote]

The second bullet is quite hard to parse, but I believe EDG
uses it for the diagnostic, which was elaborated by both
Richard Corden and W.M.Miller.


> --
> Gennaro Prota | name.surname yahoo.com

Regards,

Jiang


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jiang wrote:
> On Sep 6, 6:55 am, Gennaro Prota <gennaro/pr...@yahoo.com> wrote:
>> gm...@ti.com wrote:
[snip]
>>> It suggests writing BOOST_STATIC_ASSERT(sizeof(T) == 0).
>> Now, let me re-quote the section you intend to quote:
>>
>> If no valid specialization can be generated for a template
>> definition, and that template is not instantiated, the template
>> definition is ill-formed, no diagnostic required.
>>
>
>
> [quote 14.6/p7, (p8 in N2723) ]
[snip]

I think you're missing my point: the template definition is (still)
*ill-formed*, diagnostic or not.

--
Gennaro Prota | name.surname yahoo.com
Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]