Hallo.
Given the importance acquired by template metaprogramming techniques in
the recent past, I wonder if the next version of the standard shouldn't
include some explicit support for compile time diagnostics.

One idea could be a static_assert metafunction, which could take a bool
expression and a string literal as arguments. If the bool expression
evaluates to false during compilation the string literal would be
printed as compiler diagnostic.

I would consider this an improvement over the kludge of making the
compiler issue error messages that mention hopefully meaningful
identifiers.

Best regards,
Nicola Musatti

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

Nicola Musatti wrote:
>
> Hallo.
> Given the importance acquired by template metaprogramming techniques in
> the recent past, I wonder if the next version of the standard shouldn't
> include some explicit support for compile time diagnostics.
>
> One idea could be a static_assert metafunction, which could take a bool
> expression and a string literal as arguments. If the bool expression
> evaluates to false during compilation the string literal would be
> printed as compiler diagnostic.
>
> I would consider this an improvement over the kludge of making the
> compiler issue error messages that mention hopefully meaningful
> identifiers.

Agreed!  I wanted to suggest it several times, but even a little bit
more difficult stuff... and I have never ever had the time.

I actually was thinking about the opportunity to add some kind of
"rules" to class interfaces, how do I allow them to work.  I cannot
remember what was the exact thing in my code, but there is one for the
string class:

const char *T::getFQDN() {
   string ret=String2Upper( mFQDN);
   return ret.c_str();
}

Now the compiler has _no_way_ (in case of a non-standard library stuff)
to know that the memory area pointed by the pointer returned by
::c_str() actually has the same lifetime as the object.  Now if I
_could_ tell this to the compiler, the compiler could issue a
diagnostic: returning pointer to a temporary or something like that.

It would be nice if I could indicate the ownership (lifetime, whatever)
of the returned pointers and compilers could use it to "debug" my code
while compiling.

Attila

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