Topic: point in triangle

[pkohut]

But then I would need to test the error status again if I wanted to return out of the function on != eOk right?

Oh, I see what the macros are doing, all three are different.  So yes you would need the test.

[It's Alive!]

see I get a nice little statck trace 

Code: [Select]

  static Acad::ErrorStatus foofar( void )
  {
    return Acad::eNoDatabase;
  }

  static Acad::ErrorStatus foo( void )
  {
    TRYRETES(foofar())
    //...
  }

  static Acad::ErrorStatus foobar( void )
  {
    TRYRETES(foo())
    //...
  }

  // - RxlRxLib._getPoint command (do not rename)
  static void RxlRxLib_getPoint(void)
  {
    TRYRETVOID(foobar())
    //..
  }


[pkohut]

Here's a tweeked version of your macros.  This allows the continued use
of the macro feature you use.

Code: [Select]

__declspec(noinline) void EsPrint(Acad::ErrorStatus es)
{
    acutPrintf(_T("\nError: Line %ld [%s]\nIn function %s"),
        __LINE__, acadErrorStatusText(es), _T(__FUNCTION__));
}

//returns ES
#define TRYRETES(statement)    { Acad::ErrorStatus st = (statement); if (st != Acad::eOk){\
    EsPrint(st);\
    return st;}}

// returns void
#define TRYRETVOID(statement)  { Acad::ErrorStatus st = (statement); if (st != Acad::eOk){\
    EsPrint(st);\
    return;}}

// only prints es message
#define TRYMSG(statement)      { Acad::ErrorStatus st = (statement); if (st != Acad::eOk){\
    EsPrint(st);\
    }}


[It's Alive!]

hmmm, This is what I get

[It's Alive!]

maybe

Code: [Select]

__declspec(noinline) void EsPrint(Acad::ErrorStatus es, LPCTSTR func)
{
  acutPrintf(_T("\nError: Line %ld [%s]\nIn function %s"),
    __LINE__, acadErrorStatusText(es), func);
}

//returns ES
#define TRYRETES(statement)    { Acad::ErrorStatus st = (statement); if (st != Acad::eOk){\
  EsPrint(st,_T(__FUNCTION__));\
  return st;}}

// returns void
#define TRYRETVOID(statement)  { Acad::ErrorStatus st = (statement); if (st != Acad::eOk){\
  EsPrint(st,_T(__FUNCTION__));\
  return;}}

// only prints es message
#define TRYMSG(statement)      { Acad::ErrorStatus st = (statement); if (st != Acad::eOk){\
  EsPrint(st,_T(__FUNCTION__));\
}}


[It's Alive!]

works! Thanks Paul!

[pkohut]

Ha, was just replying with a similar fix.

[It's Alive!]

Question, Why would I not want EsPrint inline ?

[pkohut]

Your handlers are small enough that the extra 16 bytes they use per call
isn't a big deal, even used a 1000 times.  What if you decide the handler
should do something extra, maybe 3 extra somethings and adds a missly
64 bytes for each use.  Tough call, unless you take the advise of "Item 30
in Effective C++, by Scott Myers"

This leads to a logical strategy for determining which functions should be declared inline and which should not. Initially, don't inline anything, or at least limit your inlining to those functions that must be inlined (see item 46) or are truly trivial (such as Person::age on page 135). By employing inlines cautionsly, you facilitate your use of a debugger, but you also put inlining in its proper place: as a hand applied optimization.  Don't forget the empirically determined rule of 80-20, which states that a typical program spends 80% of its time executing only 20% of its code. It's an important rule, because it reminds you that your goal as a software developer is to identify the 20% of your code that can increase your programs overall performance. You can inline and otherwise tweak your function until the cows come home, but it's a wasted effort unless you're focusing on the right functions.

[pkohut]

Code: [Select]

...
    TRYRETVOID (pBlockTableRecord.openStatus());
    AcDbBlockTableRecordIterator* pIter;
    TRYRETVOID (pBlockTableRecord->newIterator( pIter ))
   
    for (pIter->start();!pIter->done();pIter->step())
    {
      AcDbObjectId entId;
      TRYRETVOID(pIter->getEntityId(entId));
      AcDbEntityPointer pEnt(entId,AcDb::kForRead);
...


Watch out, you leaked a pIter!

Noticed it while trying figure out an alternative error handler.

[It's Alive!]

Code: [Select]

...
    TRYRETVOID (pBlockTableRecord.openStatus());
    AcDbBlockTableRecordIterator* pIter;
    TRYRETVOID (pBlockTableRecord->newIterator( pIter ))
   
    for (pIter->start();!pIter->done();pIter->step())
    {
      AcDbObjectId entId;
      TRYRETVOID(pIter->getEntityId(entId));
      AcDbEntityPointer pEnt(entId,AcDb::kForRead);
...


Watch out, you leaked a pIter!

Noticed it while trying figure out an alternative error handler.

Doh, I had delete at the bottom, so it would have leaked if this line failed   
TRYRETVOID(pIter->getEntityId(entId));

[It's Alive!]

 added the line macro

Code: [Select]

void PrintErrorStatus(Acad::ErrorStatus es, LPCTSTR func)
{
  acutPrintf(_T("\nError: [%s]\nIn function %s"),
  acadErrorStatusText(es), func);
}

void PrintErrorStatus(Acad::ErrorStatus es, long line, LPCTSTR func)
{
  acutPrintf(_T("\nError: Line %ld [%s]\nIn function %s"),
    line, acadErrorStatusText(es), func);
}

//returns ES
#define TRYRETES(statement)    { Acad::ErrorStatus st = (statement);\
  if (st != Acad::eOk){\
  PrintErrorStatus(st,__LINE__,_T(__FUNCTION__));return st;}}\
  (void)0 //force ;

// returns void
#define TRYRETVOID(statement)  { Acad::ErrorStatus st = (statement);\
  if (st != Acad::eOk){\
  PrintErrorStatus(st,__LINE__,_T(__FUNCTION__));return;}}\
  (void)0 //force ;

// only prints es message
#define TRYMSG(statement)      { Acad::ErrorStatus st = (statement);\
  if (st != Acad::eOk){\
  PrintErrorStatus(st,__LINE__,_T(__FUNCTION__));}}\
  (void)0 //force ;


[owenwengerd]

It's interesting to watch this tracing macro conversation evolve.

I was recently looking at some code I wrote 10 years ago, where I had made an effort that looked very similar to what Daniel is doing, but I've long since abandoned the one size fits all approach in favor of more precise handling of error cases. If it's really an exception, I throw an exception; otherwise I handle it as an error by propagating it back to the caller after first cleaning up and emitting trace output. IMO nothing is gained by trying to compress all that work into a single macro: doing that just makes the code less readable and less maintainable, and the effort to compress error handling can quickly consume the programming process and divert the focus away from good code design.

I use a vararg trace function that evaluates to nothing in release builds and only emits code in debug builds. I can then use simple macros to send line, function, and state information to that function. The trace output function is then designed to emit debugger output and log output to a file or to the AutoCAD command line depending on registry settings.

[pkohut]

IMO nothing is gained by trying to compress all that work into a single macro: doing that just makes the code less readable and less maintainable, and the effort to compress error handling can quickly consume the programming process and divert the focus away from good code design.

Fully agree.  Handling error return codes is a big part of development and they should not be ignored, even if handling them makes the code "ugly".  What the macros do is allow the coder to type a little bit less, line things up nicely in the editor, loose the visual structure of the application that naturally occurs with block brackets, and create way to many exit points in functions (talking C++ here where GC is not an option).

[It's Alive!]

Thanks for the feedback guys, I will look into building some sort of trace output function.