On 5/26/2011 6:05 AM, Jose Armando Garcia wrote:

It is. Probably it's a good idea to use module name, which is unique across
an application, unlike the (directory-less) file name.
https://www.owasp.org/index.php/Fuzzing#File_format_fuzzing
Yes. It should be, there is a defense contractor that I used to work with as a client ask if there is anyway to check for such code.
That is from another language but the principles are the same.


Actually, '.stringof' is not good enough for my use case. I would
really like __MODULE__! The nice thing about the __FILE__ and __LINE__
is that they are evaluated at the call site. It doesn't matter if you
use them in the value of template parameter or in the value of
function parameter. '.stringof' is getting evaluated in the module
where the function is declared so it is not really useful as a default
value. In other words I can't use it for std.log without polluting the
API.

void func() { grabModuleName(); }
void main() { func(); }
$ ./test_module
module test_module2
not really useful
Yes, I would have to agree as not really useful. Most of us will be writing a log library and to record the calling module info.

May I also add this.
__BLOCKNAME__ // Since in D, as I have seen within the phobos, the source file are huge. class/struct/interface/template... name.

and if there is any refactoring donem,within the webproject, on the existing source in the future, how do we track by just __FILE__ __LINE__ when it might have changed without changing the class/struct/interface name to else where?


Reading this and trying out the sample.
http://www.digitalmars.com/d/archives/digitalmars/D/FUNCTION_implemented_with_mixins_and_mangles_92055.html

 // Parsing mangles for fun and profit.
string _getJustName(string mangle){
     size_t idx = 1;
     size_t start = idx;
     size_t len = 0;
     while(idx < mangle.length && mangle[idx] >= '0' &&
           mangle[idx] <= '9'){
         int size = mangle[idx++] - '0';
         while(mangle[idx] >= '0' && mangle[idx] <= '9')
             size = (size * 10) + (mangle[idx++] - '0');
          start = idx;
         len = size;
         idx += size;
     }
     if(start < mangle.length)
         return mangle[start .. start + len];
     else
         return "";
 }

 // Eheheh, I has a __FUNCTION__.
 const string FuncNameMix = "static if(!is(typeof(__FUNCTION__)))"
 "{ struct __FUNCTION {} const char[] __FUNCTION__ ="
 "_getJustName(__FUNCTION.mangleof); }";

static this(){
         mixin(FuncNameMix);
         writeln("This is run within: ",__FUNCTION__);
}

class MyClassB {
        this(){
         mixin(FuncNameMix);
          writeln("This is run within: ",__FUNCTION__);
        }
        
        ~this(){
         mixin(FuncNameMix);
          writeln("This is run within: ",__FUNCTION__);               
        }
}

class MyClassA {
        this()
{ mixin(FuncNameMix); writeln("This is run within: ",__FUNCTION__); }
        
        ~this(){
         mixin(FuncNameMix);
          writeln("This is run within: ",__FUNCTION__);               
        }
        
        void showInfo(){
         mixin(FuncNameMix); // ### each mixin insert binary
          writeln("This is run within: ",__FUNCTION__);               
        }
}


 void main(string[] args){
        funcMyFuncA();
        writeln("Creating MyClassA()...");            
        MyClassA objA=new MyClassA();
        objA.showInfo();
MyClassB objB=new MyClassB(); // ### How to tell the output of this from A __ctor??
        writeln("Done running MyClassA()...");                

 }

__FUNCTION__ seems to only work for a functions and not:
1) Class/struct/interface where there are perhaps over 20 methods each. Mixin 20 times?? that will take up lots of binary code size with the dll/exe.
2) How to tell which block of code that __FUNCTION__ message belongs to?

Thanks for the source code and URL from these places. It does open up eye for me about code interacting with D compiler directly. However, I and think many others would sure like if there is more build in compiler generated information like __FILE__ automatically WITHOUT using mixin all over the places as overhead to the runtime instead of compile time.


--
Matthew Ong
email: [email protected]

Reply via email to