-september.org> 1f454650
From: use_my_alias_here_at_hotmail_com@tellus.orb.dotsrc.org
On 2012-12-23 17:53, Tobias Müller wrote:
> DeMarcus wrote:
>> Hi,
>>
>> 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__
>>
>> // ... 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?
>
> As long as C++ uses (at least conceptually) the two-stage design with
> preprocessor and compiler, I think macros are the right thing to do.
>
> Reasons:
> - After preprocessing, there's only one big file left. The compiler has
> (conceptually) no way to find out what's the original location of a line.
> - The preprocessor language is line oriented, C++ not. Line numbers should
> not be relevant there.
> - When should the values be substituted/fixed? When using the std::linfo
> name, when accessing its members?
It should be a compile time construct, i.e. when compiling std::linfo.
> - use as default parameter is yet another special case.
> - std::linfo cannot be plain non-volatile (because its value changes), nor
> can it be plain volatile (because else you could not pass it by reference)
> for the compiler/optimizer. A different concept is necessary. Is that
> really worth it?
>
I don't know if std::linfo is the best solution but I think it's worth to find
a standardized way to express trace points.
> void fun(std::line_info const& linfo)
> {
> bool eq = &std::linfo == &std::linfo; // same or not?
> eq = std::linfo.file_name == std::linfo.file_name // same or not?
> eq = &linfo == &linfo // same or not?
> eq = &linfo == &std::linfo // same or not?
> std::linfo const* pl0;
> std::linfo const* pl1;
> for (int i = 0; i < 2; ++i)
> {
> std::linfo const*& pl = i==0 ? pl0 : pl1;
> pl = &std::linfo;
> }
> eq = pl1 == pl2; // same or not?
> // and so on
> }
>
I would probably suggest to delete the == operator. It makes no sense to
compare two std::linfo.
> In the preprocessor everything fits better. It's plain textual substitution
> and all filenames and line numbers are known from #including the files.
>
You have a point, maybe we should investigate some kind a compile time
std::trace_point instead that doesn't mention anything about line or file but
later could be reverse engineered to provide such information.
When I think of it, a system's administrator has no use of line and file
anyway, so it would be better with a big hash value in the log. Then this hash
value could together with the right version of the source code provide the
line and file, and maybe
even the whole stack trace.
It's a wild vision but it shouldn't be impossible.
Regards,
Daniel
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
