www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - modulename

reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
anybody know a neat trick to get the module name that a function is 
being called in a la

void foobar(size_t line = __LINE__) {
}

std.traits.moduleName looks like it almost does it, but it needs a 
symbol from the module.
Sep 04 2012
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
__FILE__?

On 9/4/12, Ellery Newcomer <ellery-newcomer utulsa.edu> wrote:

 anybody know a neat trick to get the module name that a function is
 being called in a la

 void foobar(size_t line = __LINE__) {
 }

 std.traits.moduleName looks like it almost does it, but it needs a
 symbol from the module.
Sep 04 2012
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 09/04/2012 12:41 PM, Andrej Mitrovic wrote:

 __FILE__?


It doesn't necessarily have the exact package hierarchy. e.g:

// wonka.d
module willy.wonka;

pragma(msg, __FILE__);

// end wonka.d


dmd wonka.d

gives

"wonka.d"

but

dmd willy/wonka.d

gives

"willy/wonka.d"
Sep 04 2012
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
 9/4/12, Ellery Newcomer <ellery-newcomer utulsa.edu> wrote:

 On 09/04/2012 12:41 PM, Andrej Mitrovic wrote:

 __FILE__?


 It doesn't necessarily have the exact package hierarchy.


We could really use __MODULE__ then. I think it's been asked before
but I didn't see any enhancement request in buzilla.
Sep 04 2012
parent reply captaindet <2krnk gmx.net> writes:
On 2012-09-04 15:36, Andrej Mitrovic wrote:

   9/4/12, Ellery Newcomer<ellery-newcomer utulsa.edu>  wrote:

 On 09/04/2012 12:41 PM, Andrej Mitrovic wrote:

 __FILE__?


 It doesn't necessarily have the exact package hierarchy.


 We could really use __MODULE__ then. I think it's been asked before
 but I didn't see any enhancement request in buzilla.


+1 would love this too

so far tried to get away with __FILE__ but this has issues, as noted before.


on a slightly different note, __FILE__ and __LINE__ are not quite doing what
they are supposed to do either:

http://dlang.org/template.html
Template Value Parameters
"The __FILE__ and __LINE__ expand to the source file name and line number at
the point of instantiation."

unfortunately, they only do this for functions (sort of¹), not for other
templates. dunno why, i think it is just not implemented. in fear of code
bloat? i don't get this argument though. if you use __FILE__ and such
extensively it would be only in debugging scenarios. other than that, you
shouldn't have many of those. at least this is the case in my code. and the
danger of code bloat with templates is omnipresent, no reason to single out
__FILE__ usage.

¹using funtempl(Ps)(As){...}:
+ always works in argument list (As), also in non-templated functions
+ as template parameter (P), works only when called short: funtempl()
- as template parameter(P), this does not work: funtempl!()()
Sep 05 2012
next sibling parent reply Jose Armando Garcia <jsancio gmail.com> writes:
On Sep 5, 2012, at 10:56, captaindet <2krnk gmx.net> wrote:


 On 2012-09-04 15:36, Andrej Mitrovic wrote:

  9/4/12, Ellery Newcomer<ellery-newcomer utulsa.edu>  wrote:

 On 09/04/2012 12:41 PM, Andrej Mitrovic wrote:

 __FILE__?


 It doesn't necessarily have the exact package hierarchy.


 We could really use __MODULE__ then. I think it's been asked before
 but I didn't see any enhancement request in buzilla.


 +1 would love this too

 so far tried to get away with __FILE__ but this has issues, as noted =20=



 before.


 on a slightly different note, __FILE__ and __LINE__ are not quite =20
 doing what they are supposed to do either:

 http://dlang.org/template.html
 Template Value Parameters
 "The __FILE__ and __LINE__ expand to the source file name and line =20
 number at the point of instantiation."

 unfortunately, they only do this for functions (sort of=C2=B9), not =


for o=20

 ther templates.


It should work for templates too; std.log uses this extensively. Or at =20=

least it used to work. Can you post the code sample where it doesn't =20
work?=
Sep 05 2012
parent captaindet <2krnk gmx.net> writes:
On 2012-09-05 13:05, Jose Armando Garcia wrote:

 On Sep 5, 2012, at 10:56, captaindet <2krnk gmx.net> wrote:


 On 2012-09-04 15:36, Andrej Mitrovic wrote:

 9/4/12, Ellery Newcomer<ellery-newcomer utulsa.edu> wrote:

 On 09/04/2012 12:41 PM, Andrej Mitrovic wrote:

 __FILE__?


 It doesn't necessarily have the exact package hierarchy.


 We could really use __MODULE__ then. I think it's been asked
 before but I didn't see any enhancement request in buzilla.


 +1 would love this too

 so far tried to get away with __FILE__ but this has issues, as
 noted before.


 on a slightly different note, __FILE__ and __LINE__ are not quite
 doing what they are supposed to do either:

 http://dlang.org/template.html Template Value Parameters "The
 __FILE__ and __LINE__ expand to the source file name and line
 number at the point of instantiation."

 unfortunately, they only do this for functions (sort of¹), not for
 other templates.


 It should work for templates too; std.log uses this extensively. Or
 at least it used to work. Can you post the code sample where it
 doesn't work?



i had a quick look at std.log and it seems to use __LINE__ and __FILE__ only as
function argument defaults or parameter defaults for templated functions. these
are the only cases where it actually works (with the one syntax catch though).
however, it does not work for bare/mixin tamplates, templated structs or
templated classes. (so i ended up writing factory functions for my code)

here a test program:
/**
__LINE__ testing for
F := function   S := struct     C := class      T := template
MT := mixin template

as
A := function value argument    P := template value parameter

using dmd2.060 /windows prints:
Instantiating Code starts line: 63

F(A)
OK : captured line = 67

T(P)
FAIL : captured line = 43

MT(P)
FAIL : captured line =  46

TF()(A)
OK : captured line = 78

TF(P)(): short call syntax: TF_P()
OK : captured line = 82

TF(P)(): longer call syntax: TF_P!()()
FAIL : captured line = 52

TS(P)
FAIL : captured line = 55

TC(P)
FAIL : captured line = 58
**/

module testline;
import std.stdio;

size_t F_A( size_t l = __LINE__ ){
	return l; }
	
template T_P( size_t l = __LINE__ ){
	enum size_t t_p = l; }
	
mixin template MT_P( size_t l = __LINE__ ){
	enum size_t mt_p = l; }
	
size_t TF_A()( size_t l = __LINE__ ){
	return l; }
	
size_t TF_P( size_t l = __LINE__ )(){
	enum size_t _l = l; return _l; }
	
struct TS_P( size_t l = __LINE__ ){
	size_t _l = l; }
	
class TC_P( size_t l = __LINE__ ){
	size_t _l = l; }
	
	
void main(){
	size_t L = __LINE__;		// if things work: __LINE__ > L
	writeln("\nInstantiating Code starts line: ", L);
	
	writeln("\nF(A)");
	auto l_f_a = F_A();
	writeln((l_f_a>L)?"OK":"FAIL", " : captured line = ", l_f_a);

	writeln("\nT(P)");
	writeln((T_P!().t_p>L)?"OK":"FAIL", " : captured line = ", T_P!().t_p);
	
	writeln("\nMT(P)");
	mixin MT_P!();
	writeln((mt_p>L)?"OK":"FAIL", " : captured line =  ", mt_p);
	
	writeln("\nTF()(A)");
	auto l_tf_a = TF_A!()();
	writeln((l_tf_a>L)?"OK":"FAIL", " : captured line = ", l_tf_a);

	writeln("\nTF(P)(): short call syntax: TF_P()");
	auto l_tf_p = TF_P();
	writeln((l_tf_p>L)?"OK":"FAIL", " : captured line = ", l_tf_p);

	writeln("\nTF(P)(): longer call syntax: TF_P!()()");
	auto l_tf_p2 = TF_P!()();
	writeln((l_tf_p2>L)?"OK":"FAIL", " : captured line = ", l_tf_p2);

	writeln("\nTS(P)");
	TS_P!() ts_p;
	writeln((ts_p._l>L)?"OK":"FAIL", " : captured line = ", ts_p._l);

	writeln("\nTC(P)");
	auto tc_p = new TC_P!();	
	writeln((tc_p._l>L)?"OK":"FAIL", " : captured line = ", tc_p._l);
}
Sep 05 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, September 05, 2012 11:05:10 Jose Armando Garcia wrote:

 It should work for templates too; std.log uses this extensively. Or at
 least it used to work. Can you post the code sample where it doesn't
 work?


Regardless of whether it works, __FILE__ and __LINE__ should be used as 
template arguments with extreme caution, because you end up with a new 
instantiation for _every_ use (at least if you use both together).

If it's broken, it should certainly be fixed, but it's not a feature to be used 
lightly.

- Jonathan M Davis
Sep 05 2012
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/5/12, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 Regardless of whether it works, __FILE__ and __LINE__ should be used as
 template arguments with extreme caution, because you end up with a new
 instantiation for _every_ use (at least if you use both together).


Honestly it would be much better if the file and line were symbols you
could retrieve at any point in your function, e.g.:

void foo()
{
    string file = __FILE__;  // file of inside
    int line = __LINE__;  // line inside foo

    string callFile = __INFILE__;  // file of invocation
    int line = __INLINE__;  // line of invocation
}

That way you don't have to mess with your CT/RT parameters if all you
want to do is printf-style debugging.
Sep 05 2012
prev sibling parent =?ISO-8859-1?Q?Jos=E9_Armando_Garc=EDa_Sancio?= <jsancio gmail.com> writes:
On Tue, Sep 4, 2012 at 1:36 PM, Andrej Mitrovic
<andrej.mitrovich gmail.com>wrote:


  9/4/12, Ellery Newcomer <ellery-newcomer utulsa.edu> wrote:

 On 09/04/2012 12:41 PM, Andrej Mitrovic wrote:

 __FILE__?


 It doesn't necessarily have the exact package hierarchy.


 We could really use __MODULE__ then. I think it's been asked before
 but I didn't see any enhancement request in buzilla.


+1. std.log would love this feature.
Sep 04 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, September 04, 2012 21:41:24 Andrej Mitrovic wrote:

 __FILE__?


That'll mostly work, but it's perfectly possible to give a module a name which 
is completely different from the file name.

But it looks like we now have std.traits.moduleName, so presumably that will 
do the trick.

- Jonathan M Davis
Sep 04 2012
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 09/04/2012 01:16 PM, Jonathan M Davis wrote:

 On Tuesday, September 04, 2012 21:41:24 Andrej Mitrovic wrote:

 __FILE__?


 That'll mostly work, but it's perfectly possible to give a module a name which
 is completely different from the file name.

 But it looks like we now have std.traits.moduleName, so presumably that will
 do the trick.

 - Jonathan M Davis


moduleName needs a symbol
Sep 04 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/4/12, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 But it looks like we now have std.traits.moduleName, so presumably that will
 do the trick.


How will that do the trick if you don't have the reference to the
invoking module?
Sep 04 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, September 04, 2012 22:40:19 Andrej Mitrovic wrote:

 On 9/4/12, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 But it looks like we now have std.traits.moduleName, so presumably that
 will do the trick.


 
 How will that do the trick if you don't have the reference to the
 invoking module?


Clearly, I didn't read the OP clearly enough.

Unless you can get code to be generated in the calling scope (e.g. with 
mixins), then the _only_ access that you have to anything in the calling scope 
is with __FILE__ and __LINE__. And they only work that way because they're 
treated as special cases (they _don't_ work that way in C/C++). Pretty much by 
definition, anything that you type is in the scope that you type it.

You _might_ be able to get it to work by having the caller explicitly pass 
something via an alias template parameter, but if you wanted something 
explicit, you could have the caller just pass a string with the module's name. 
I pretty darn sure that there's no way to get the compiler to tell you what 
you're looking for without the caller doing something.

- Jonathan M Davis
Sep 04 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Jos=E9_Armando_Garc=EDa_Sancio?= <jsancio gmail.com> writes:
On Tue, Sep 4, 2012 at 2:00 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:


 On Tuesday, September 04, 2012 22:40:19 Andrej Mitrovic wrote:

 On 9/4/12, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 But it looks like we now have std.traits.moduleName, so presumably that
 will do the trick.


 How will that do the trick if you don't have the reference to the
 invoking module?


 Clearly, I didn't read the OP clearly enough.

 Unless you can get code to be generated in the calling scope (e.g. with
 mixins), then the _only_ access that you have to anything in the calling
 scope
 is with __FILE__ and __LINE__. And they only work that way because they're
 treated as special cases (they _don't_ work that way in C/C++).



C/C++ may not need __FILE__ and __LINE__ to get evaluated at the call site
because C/C++ have preprocessor macros to get around this problem.
Sep 04 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, September 05, 2012 20:46:08 Andrej Mitrovic wrote:

 On 9/5/12, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 Regardless of whether it works, __FILE__ and __LINE__ should be used as
 template arguments with extreme caution, because you end up with a new
 instantiation for _every_ use (at least if you use both together).


 
 Honestly it would be much better if the file and line were symbols you
 could retrieve at any point in your function, e.g.:
 
 void foo()
 {
 string file = __FILE__; // file of inside
 int line = __LINE__; // line inside foo
 
 string callFile = __INFILE__; // file of invocation
 int line = __INLINE__; // line of invocation
 }
 
 That way you don't have to mess with your CT/RT parameters if all you
 want to do is printf-style debugging.


That would be _way_ harder to implement. As it is, it's trivial to insert the 
__FILE__ and __LINE__ as default arguments at the call site. Doing __INFILE__ 
or __INLINE__ would require providing additional, invisible arguments to the 
function for the __FILE__ and __LINE__ at the call site, and it would 
invisibly change the function's signature depending on whether __INFILE__ 
and/or __INLINE__ were used in the function or not. I'd be very surprised if 
that sort of thing were considered acceptable by the compiler devs.

With how C linkage is designed, it doesn't care about the call site at all. A 
function has no idea where it's called from and doesn't care. The only reason 
that we got __FILE__ and __LINE__ to work like they do with default arguments 
is because it was trivial to change it so that they used the values at the 
call site rather than the declaration site, because those values are copy-
pasted at the call site anyway. Anything which would require the function 
itself actually having access to the scope that it was called from would 
complicate things considerably.

- Jonathan M Davis
Sep 05 2012
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/5/12, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 That would be _way_ harder to implement.


Right, this would only work for templated functions, but maybe not
worth adding then.
Sep 05 2012