Re: [boost] Re: Next revision of boost::thread amp;amp;amp;amp;OS error code.
Peter Dimov said: From: William E. Kempf [EMAIL PROTECTED] Might be true for Boost.Filesystem. The path values may be useful in some cases, for instance. I'm not 100% sure about the who() string, though. The meaning of the path values is context dependent, and who() provides the context, although perhaps who() doesn't need to be a std::string, a const char * could do. (If the current what() semantics are dropped, what() can be made to carry the function name (what failed), and who() will become redundant.) If what returns the function name that caused the exception, replacing who, you've not eliminated dynamic allocations where they matter. But I don't understand the utility of who(), i.e. what good is it to get a single function name that originated the error? The user isn't going to care about this information, and the developer is going to want a call stack, not the originator (which may be buried several calls deep in the interface the developer is actually dealing with!). I don't understand the value add for this payload. I think the paths are similar to this, though I can think of more scenarios where they might still be useful to the developer, and once in a while possibly to the end user. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread amp;amp;amp;amp;OS error code.
From: William E. Kempf [EMAIL PROTECTED] Peter Dimov said: From: William E. Kempf [EMAIL PROTECTED] Might be true for Boost.Filesystem. The path values may be useful in some cases, for instance. I'm not 100% sure about the who() string, though. The meaning of the path values is context dependent, and who() provides the context, although perhaps who() doesn't need to be a std::string, a const char * could do. (If the current what() semantics are dropped, what() can be made to carry the function name (what failed), and who() will become redundant.) If what returns the function name that caused the exception, replacing who, you've not eliminated dynamic allocations where they matter. But I don't understand the utility of who(), i.e. what good is it to get a single function name that originated the error? The user isn't going to care about this information, and the developer is going to want a call stack, not the originator (which may be buried several calls deep in the interface the developer is actually dealing with!). I don't understand the value add for this payload. I've already went over this a couple of times. :-) The fact that who() returns a function name is not important; it is not a mini call stack. A function name is used as a token that identifies the point of failure. What failed? An attempt to open a file? An attempt to read the contents of a directory? An attempt to copy a file? To move a file? You need this information in order to compose a meaninful error message. No such file or directory by itself isn't very helpful to the user. What is the name of the file/directory that wasn't found? What did the program try to do with it? Once you accept that the exception needs to provide an unique token that identifies the point of failure, now the question is how to choose its type and value. Integral constants don't work well since you need arbitration to prevent collisions. C++ identifiers are a good solution since the compiler enforces unique-ness. :-) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
