Loki vs EDG on legal template definition

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!

Here is the code ...

// The following comes from the Loki library v0.1.6 file
static_check.h
namespace Loki
{
template<int> struct CompileTimeError;
template<> struct CompileTimeError<true> {};
}

// Complete definition of class template Test
template<typename T>
class Test {};

// Specialization to inhibit Test with a Pointer Parameter
template<typename T>
class Test<T*> {
public:
~Test()
{
// These lines arise from invoking this Loki macro:
// LOKI_STATIC_CHECK(0, msg);
{
Loki::CompileTimeError<((0) != 0)> ERROR_msg;
(void)ERROR_msg;
};
}
};

int main()
{
Test<int> t; // Gets diagnostic Loki library does NOT
expect
// Test<int *> pt; // Gets diagnostic Loki library DOES expect
return 0;
}

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.

Background ... I work at Texas Instruments with the compiler
development group. We use the EDG front end. We supply it to our
customers with strict ANSI/ISO mode on by default. Many of our
customers build systems where reliability is a big deal. Think anti-
lock braking systems. Telling them to use some non-strict parsing
mode is just impossible. At the same time, I would hate to steer them
away from something as useful as Loki.

Thanks and regards,

-George


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

On Aug 31, 12:28 am, gm...@ti.com wrote:

[...]

>
> "file.cpp", line 21: error: incomplete type is not allowed
> Loki::CompileTimeError<((0) != 0)> ERROR_msg;
> ^
>
> So, who is incorrect? EDG or Loki?
>

Yes, como, when used in strict mode, also rejects the above code
for the same reason.

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

Well, IMHO the problem has little to do with the bullet you quoted,
and EDG rejects the above test based on the deduction for template
argument.

In your example, the template argument ((0) != 0) yields a non-type
argument, and the compiler will try to do the necessary conversion
to get the corresponding template parameter. However, for your
test program the compiler will choose type int, instead of bool, based
on the rules stated in 14.3.2 . That is, the specialized complete
type
for value "true" will not be selected for your above test, therefore
you get the incomplete type error. Actually the result of evaluation
, false (0 for integral type), make things worse in my mind.


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


Well, somehow I agree with you EDG is correct, but I am also
not definitely sure.

> Background ... I work at Texas Instruments with the compiler
> development group. We use the EDG front end. We supply it to our
> customers with strict ANSI/ISO mode on by default.


This is a good new for me( I am a customer of your compiler. ;-) )
I was thinking cl6x is derived from GCC or its variants.

Sorry maybe this is off-topic, but do you/your team have
plans to add more support for ccs's standard library
(STL, for example) in the recent future?

> -George

Jiang


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

gmock@ti.com wrote:
> Thus, I conclude the Loki library is in error. Obviously, I'm not
> confident of that conclusion. That's why I seek more input.

Basically the same as

<http://lists.boost.org/Archives/boost/2004/06/66983.php>

The relevant standard requirement is in Name Resolution [temp.res]
(search for "no valid specialization can be generated").

--
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 Aug 31, 11:49 pm, Jiang <goo.mai...@yahoo.com> wrote:
> On Aug 31, 12:28 am, gm...@ti.com wrote:
>
> > "file.cpp", line 21: error: incomplete type is not allowed
> > Loki::CompileTimeError<((0) != 0)> ERROR_msg;
> > ^
>
> > So, who is incorrect? EDG or Loki?
>
> Yes, como, when used in strict mode, also rejects the above code
> for the same reason.

That isn't actually a separate data-point. como is based on the EDG
front-end.

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

On Sep 1, 4:03 pm, Gennaro Prota <gennaro/pr...@yahoo.com> wrote:
> gm...@ti.com wrote:
> > Thus, I conclude the Loki library is in error. Obviously, I'm not
> > confident of that conclusion. That's why I seek more input.
>
> Basically the same as
>
> <http://lists.boost.org/Archives/boost/2004/06/66983.php>
>
> The relevant standard requirement is in Name Resolution [temp.res]
> (search for "no valid specialization can be generated").
>

Would you please elaborate on this ? I failed to see why
no valid specialization can be generated for the original
example code.

BTW, the LOKI_STATIC_CHECK is not exactly same as
BOOST_STATIC_ASSERT.

[quote loki]

15 #ifndef LOKI_STATIC_CHECK_INC_
16 #define LOKI_STATIC_CHECK_INC_
17
18 // $Id$
19
20
21 namespace Loki
22 {

23 ////////////////////////////////////////////////////////////////////////////////
24 // Helper structure for the STATIC_CHECK macro

25 ////////////////////////////////////////////////////////////////////////////////
26
27 template<int> struct CompileTimeError;
28 template<> struct CompileTimeError<true> {};
29 }
30

31 ////////////////////////////////////////////////////////////////////////////////
32 // macro STATIC_CHECK
33 // Invocation: STATIC_CHECK(expr, id)
34 // where:
35 // expr is a compile-time integral or pointer expression
36 // id is a C++ identifier that does not need to be defined
37 // If expr is zero, id will appear in a compile-time error
message.

38 ////////////////////////////////////////////////////////////////////////////////
39
40 #define LOKI_STATIC_CHECK(expr, msg) \
41 { Loki::CompileTimeError<((expr) != 0)> ERROR_##msg;
(void)ERROR_##msg; }
42
43
44 #endif // end file guardian

[end quote loki]

Regards,

Jiang


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

On Sep 2, 4:58 am, Martin Bonner <martinfro...@yahoo.co.uk> wrote:
> On Aug 31, 11:49 pm, Jiang <goo.mai...@yahoo.com> wrote:
>
> > On Aug 31, 12:28 am, gm...@ti.com wrote:
>
> > > "file.cpp", line 21: error: incomplete type is not allowed
> > > Loki::CompileTimeError<((0) != 0)> ERROR_msg;
> > > ^
>
> > > So, who is incorrect? EDG or Loki?
>
> > Yes, como, when used in strict mode, also rejects the above code
> > for the same reason.
>
> That isn't actually a separate data-point. como is based on the EDG
> front-end.
>

Then would you please tell me why icl, another compiler uses EDG
front-end, and como non-strict mode accept above code?

Jiang


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

> On Sep 2, 4:58 am, Martin Bonner <martinfro...@yahoo.co.uk> wrote:
>> On Aug 31, 11:49 pm, Jiang <goo.mai...@yahoo.com> wrote:
>>
>> > On Aug 31, 12:28 am, gm...@ti.com wrote:
>>
>> > > "file.cpp", line 21: error: incomplete type is not allowed
>> > > Loki::CompileTimeError<((0) != 0)> ERROR_msg;
>> > > ^
>>
>> > > So, who is incorrect? EDG or Loki?
>>
>> > Yes, como, when used in strict mode, also rejects the above code
>> > for the same reason.
>>
>> That isn't actually a separate data-point. como is based on the EDG
>> front-end.
>>
>
> Then would you please tell me why icl, another compiler uses EDG
> front-end, and como non-strict mode accept above code?

ICL intentionally emulates all the bugs in MSVC.

como non-strict mode is, well, non-strict. That seems self-explanatory
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, 4:40 pm, David Abrahams <d...@boostpro.com> wrote:
> on Tue Sep 02 2008, Jiang <goo.mail01-AT-yahoo.com> wrote:
>
> > On Sep 2, 4:58 am, Martin Bonner <martinfro...@yahoo.co.uk> wrote:
> >> On Aug 31, 11:49 pm, Jiang <goo.mai...@yahoo.com> wrote:
>
> >> > On Aug 31, 12:28 am, gm...@ti.com wrote:
>
> >> > > "file.cpp", line 21: error: incomplete type is not allowed
> >> > > Loki::CompileTimeError<((0) != 0)> ERROR_msg;
> >> > > ^
>
> >> > > So, who is incorrect? EDG or Loki?
>
> >> > Yes, como, when used in strict mode, also rejects the above code
> >> > for the same reason.
>
> >> That isn't actually a separate data-point. como is based on the EDG
> >> front-end.
>
> > Then would you please tell me why icl, another compiler uses EDG
> > 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).

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

Your above statement for icl, if it is correct, supports my point, IMHO.

Maybe I did not get the exact meaning of "data-point", but I think it is
helpful adding such experiment result. Well, if it is trivial, it can be
ignored without any problem. No argument needed for it at all. ;-)


> Dave Abrahams

Regards,

Jiang


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

Hi,

gmock@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!
>
> Here is the code ...
>
> // The following comes from the Loki library v0.1.6 file
> static_check.h
> namespace Loki
> {
> template<int> struct CompileTimeError;
> template<> struct CompileTimeError<true> {};
> }
>
> // Complete definition of class template Test
> template<typename T>
> class Test {};
>
> // Specialization to inhibit Test with a Pointer Parameter
> template<typename T>
> class Test<T*> {
> public:
> ~Test()
> {
> // These lines arise from invoking this Loki macro:
> // LOKI_STATIC_CHECK(0, msg);
> {
> Loki::CompileTimeError<((0) != 0)> ERROR_msg;


[ Add }'s as appropriate ]

The above is all you need to highlight the issue. As pointed out by
Gennaro Prota in a different post, 14.6/7 says:

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

In essence this means that if a compiler detects an error in the
template then it can (but does not have to) flag the code immediately as
ill formed. In the above, "(0) != 0" evaluates to '0' therefore
ERROR_msg has type CompileTimeError<0> which is incomplete. In strict
mode, EDG warns, in relaxed mode it doesn't. In both modes EDG is fully
conforming to the standard, it's just that in one case you get the
diagnostic for the ill-formed code in the other you don't.


[...]

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

This is correct. If the definition of ERROR_msg depended on the type of
'T', then it would not be possible to know while parsing the template
definition which specialization of "CompileTimeError" will be selected,
and so the compiler will have to wait for an instantiation.

> Thus, I conclude the Loki library is in error. Obviously, I'm not
> confident of that conclusion. That's why I seek more input.

From what I can see, the LOKI_STATIC_CHECK code is OK, the problem is
that it's being used in a way which doesn't depend on a template
parameter, and so it immediately triggers the error. Is the 'Test'
class part of the Loki library too? The problem is in the usage of
LOKI_STATIC_CHECK, not the macro itself.


Regards,

Richard


--
Richard Corden

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

Jiang wrote:
>> The relevant standard requirement is in Name Resolution [temp.res]
>> (search for "no valid specialization can be generated").
>>
>
> Would you please elaborate on this ? I failed to see why
> no valid specialization can be generated for the original
> example code.

The original example code has

Loki::CompileTimeError<((0) != 0)> ERROR_msg;

which is always invalid (incomplete type), regardless of T. As simple
as that.

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