www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1425] New: Feature Request: call stack reflection

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1425

           Summary: Feature Request: call stack reflection
           Product: D
           Version: unspecified
          Platform: All
               URL: http://www.digitalmars.com/webnews/newsgroups.php?art_gr
                    oup=digitalmars.D.learn&article_id=9099
        OS/Version: All
            Status: NEW
          Severity: blocker
          Priority: P2
         Component: Phobos
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: tortoise_74 yahoo.co.uk


For improved support for assertions, logging code and stack traces it would be
useful to have means of identifying the calling frame of reference. This would
also have the advantage of rendering __LINE__ and its ilk redundant.
For example it is not currently possible to implement a cppunit like
assertEqual function.
The best I can achieve is:

void assertEqual(Type)(Type actual_, Type expected_, 
                       char[] file_, 
                       uint line_) {
   if (actual_ != expected_) {
      writefln("Equality assertion failed");
      writefln("actual:   '", actual_, "'");
      writefln("expected: '", expected_, "'");
   }
   _d_assert(file_,line_);
}

Which has to be used as:

assertEqual!(string)("foo","bar",cast(char[])(__FILE__),__LINE__);

It should be possible to achieve a more natural syntax like:

assertEqual("foo","bar");

Several proposals seem have been made on the newsgroups but none has been
raised as a request here.
I personally think the best approach is to have a library function

stackFrame[] callStack = std.trace();

By default the calling frmae would be something like:

class stackFrame {
   stackFrame* parent;
   object[]    arguments;
}

When functions request source identification the compiler would have to
include mapping information so its not a pure library issue.
E.g

class SourceStackFrame: public StackFrame {
// inherited
//   stackFrame* parent;
//   object[]    arguments;
   uint        parentLine;
   string*     parentFile;
   string*     parentFunction;   
}

I imagine two ways of creating such a structure.
Use of an analogue to __FILE__ e.g. the so called "context" keyword
would tell the compiler to use the special stack frame for a specific call
only.
A command line switch could tell the compiler to always use the source stack
frame format - with resulting code bloat.


--
Aug 16 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1425


tortoise_74 yahoo.co.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |enhancement





For the case of using __FILE__ & __LINE__ there is a workaround as follows:

void assertEqual (T) (T actual, T expected, char[] file, uint line) {
   if (actual != expected) {
     writeln("Equality assertion failed.");
     writefln("  actual:   '%s'", actual);
     writefln("  expected: '%s'", expected);
     _d_assert(file, line); //or other assert wrapper
   }
}

template MAssertEqual (alias actual, alias expected) {
   const AssertEqual =
     `assertEqual!(` ~typeof(actual).stringof  ~`)(`
     ~actual.stringof~
     `, `
     ~expected.stringof~
     `, cast(char[])(__FILE__), __LINE__);`
   ;
}

unittest {
   int var5 = 1;
   int var6 = 2;

  mixin(MAssertEqual!(var5, var6)); // -> assertEqual(var5, var6, __FILE__,
__LINE__);
}


--
Aug 24 2007
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1425


nfxjfg gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nfxjfg gmail.com



Tango has this.

It doesn't include the "object[] arguments" thing, though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 29 2010