Re: Wouldn't it be good to refactor __LINE__?
On 2012-12-17 04:48, DeMarcus wrote:
There's at least one place where I can't get rid of macros; that is when
using __LINE__ and __FILE__. At the places where I need such debug
information I usually want as much information as possible, and writing
std::cout << __FILE__ << ":" << __func__ << ":" << __LINE__ <<
std::endl; everywhere is a lot of clutter.
I propose the following to be standardized:
namespace std
{
struct line_info
{
const char* file_name; // similar to __FILE__
const char* function_name; // similar to __func__
const uint32_t line_number; // similar to __LINE__
I consider a type like uint32_t as problematic, because it is not
guaranteed to exist for all systems. If you insist on some minimum
size-constraints, I suggest to use uint_least32_t instead.
// ... possible other parameters that could be of use in a
// future stack trace functionality.
};
} // namespace std
To be used like this:
myLineInfoPrinter( std::linfo );
where std::linfo is a line_info struct constant that the compiler
creates at the spot, just like __LINE__.
We have already standardized __FILE__ and __LINE__ so this struct
wouldn't be too problematic I guess, and it would be nice to remove yet
another macro from the code.
What do you think about my idea?
I like the general idea, but I would like to see implementation
experience of the proposal. Your idea bases on a mixture of current
preprocessor concepts and high-language concepts and I would like to
know about the impact on existing preprocessor implementations. At the
current moment exists no library component with such a strong binding
between these different worlds and all existing emulations of what you
describe above finally end up in involving explicit usage of a macro.
Obviously, std::linfo cannot be such a macro.
- Daniel
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]