Bronek Kozicki wrote:
Peter Dimov wrote:
How does your compiler help you spot duplicate tags?
compiler (or actually language) provides tools to organize names in open (namespaces) or closed (nested types) hierarchies. These tools so far worked rather well, allowing users to define unique names (where sane design and source code organization are in place).
Of course, if you do not want to use these tools, you do not have to. For incomplete types it's OK to redeclare tag whenever you want to use it, and it's almost no different that using literals (although slightly annoying and one has to be careful of scope). However, once you want to organize names, tags have many advantages over strings. I tried to explain these advantages in previous messages. I believe that users will want to organize tags in all but most trivial projects, as exceptions handling begs for such organization due to its distributed nature.
I've been thinking about how you might organize the tags. Consider the header that defines class file_read_error: //file_read_error.h: #include "read_error.h" class tag_file_name; //string class tag_function_name; //string class file_read_error: public read_error { }; This looks like the natural place to declare the tags. But what happens if someone looks at read_error.h: //read_error.h #include "io_error.h" class read_error: public io_error { }; The problem I see here is that if you're looking at read_error.h, it is not at all clear that some read_error exceptions have file name and function name info in them. In addition, as other pointed out as well, the compiler can not help you with avoiding typos. So really, the only way you can "organize" the tag types is by specifying them in the documentation, but you can do the same with strings. It's not like I disagree with you, after all right now the proposed Boost Exception lib uses tag types. But when you think about it, the *only* difference between the tag types and string identifiers is that strings are value types and as such they can be manipulated, read from files, etc. I think that not being able to do this stuff with the exception info identifiers is a good thing, but I don't think it's a big problem. --Emil