C++Talk.NET

Samee Zahur · Guest

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 ]

tslettebo@hotmail.com · Guest

Samee Zahur wrote:

Samee Zahur · Guest

Pete Becker · Guest

[email]tslettebo (AT) hotmail (DOT) com[/email] wrote:

tslettebo@hotmail.com · Guest

Samee Zahur wrote: