While error messages are usually not a language issue but rather a
compiler issue I, however, think it would make sense to have
some custom compiler error-raising capability built into the language
(as opposed to the preprocessor errors already there). Currently,
especially when using template libraries, mistakes trigger
rather cryptic errors, often refering to lines in the original library.
This is something compilers just cannot help - after all, the error
might really be in the library and not the user code!

Well-established template libraries should, however, have some means of
generating error messages sensible to the context
of library usage. After all, there is no way a compiler can guess the
actual point of fault - the library designers can. I'm thinking of
cases of template libraries like these:

template<class T> vector<T>::push_back(const& T)
{
  compiler_error("$T must be copy-constructible",1);
  //...
  //Copy-construct T
}

When the compiler encounters these, it would know that any errors
coming up next is not due to faulty code inside, and *any* error
will produce the message "'mytype' must be copy-constructible",
overriding (and suppresing) any of the usual messages the compiler
may produce. Or, a stricter implementation could do something like
this:

template<class T> vector<T>::vector()
{
  compiler_error("$T must be default-constructible",1);
  T dummy1;
  compiler_error("$T must be copy-constructible",1);
  T dummy2=dummy1;
}

This sees that errors can be caught right at the vector declaration.
I'm consistently using the number 1 to suggest a facility that would
instruct the compiler to generate the error 1 level 'outside' - in this
case, I would like the error to point to a line where these functions
are used - rather than where they are defined. I would be replacing the
number 1 with 2 if these dummy checks are to be moved to a different
function called from every constructor of vector class - so that errors
are generated 2 levels outside. 1 level would only go upto the
constructor code then. And of course, I'm giving the $ character a new
meaning for string literals  passed to compiler_error. Things like
these should only have effect within a single scope - the containing
one.

This would not only reduce cluttered error output from most
compilers, it would leave the users with a platform-independant
way of interpreting error messages. Moreover, it will give
library designers the option to document meanings of error
messages - although the messages themselves are supposed to be
descriptive enough :)

Lastly, to facilitate the library-designing process, compilers
should give the user an ability to suppress such error-changing
requests (possibly with preprocessor directives? #defines might
help).

Any feedbacks?

Samee

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Samee Zahur wrote:
> While error messages are usually not a language issue but rather a
> compiler issue I, however, think it would make sense to have
> some custom compiler error-raising capability built into the language
> (as opposed to the preprocessor errors already there). Currently,
> especially when using template libraries, mistakes trigger
> rather cryptic errors, often refering to lines in the original
library.
> This is something compilers just cannot help - after all, the error
> might really be in the library and not the user code!
>
> Well-established template libraries should, however, have some means
of
> generating error messages sensible to the context
> of library usage. After all, there is no way a compiler can guess the
> actual point of fault - the library designers can. I'm thinking of
> cases of template libraries like these:
>
> template<class T> vector<T>::push_back(const& T)
> {
>   compiler_error("$T must be copy-constructible",1);

There exists a proposal for something similar to this, called
"static_assert"
(http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1604.html),
and from what I understand, it will likely be added to the "working
paper" ("draft standard") for C++0x, so some facility for this will
likely end up in the next version of the standard.

However, there are some larger proposals, for adding support for
"concepts" to C++, that may end up in C++ as well (or instead of
static_assert), where you may declare that e.g. T must be
copy-constructible, etc., and it gets checked by the compiler. With it,
you might write something like:

template<ValueType T> vector<T>::push_back(const& T)

where "ValueType" is a concept that requires T to be
copy-constructible, etc.

Regards,

Terje

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

> However, there are some larger proposals, for adding support for
> "concepts" to C++

Cool!  Can you give me links to the places where this particular
proposal is described in greater details?

Samee

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

tslettebo@hotmail.com wrote:
>
> There exists a proposal for something similar to this, called
> "static_assert"
> (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1604.html),
> and from what I understand, it will likely be added to the "working
> paper" ("draft standard") for C++0x, so some facility for this will
> likely end up in the next version of the standard.
>

It was approved at the last meeting, and is part of the
not-yet-available latest version of the working draft.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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.jamesd.demon.co.uk/csc/faq.html                       ]

Samee Zahur wrote:
> > However, there are some larger proposals, for adding support for
> > "concepts" to C++
>
> Cool!  Can you give me links to the places where this particular
> proposal is described in greater details?

Sure. You can go here:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/, and search for
papers with "concepts" in the title. The most recent versions of the
two current proposals are:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1758.pdf

and a paper that unfortunately didn't make it in time for the
pre-Lillehammer mailing (N1782 - "A concept design"), but which will
likely be in the post-Lillehammer mailing. However, you can find its
predecessor in the 2003 papers (N1510, N1522 and N1536).

Regards,

Terje

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]