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