[MOAB-dev] Discussion on return type of MOAB routines

[Tim Tautges (ANL)]

On 01/22/2014 10:16 AM, Jed Brown wrote:
> "Wu, Danqing" <wuda at mcs.anl.gov> writes:
>
>> The object contains an enum type ErrorCode and std::string. The size
>> of this object is fixed, like 16 bytes in my test. However,
>> std::string is essential like a wrapped pointer implemented by
>> STL.
>
> Yes, do you really want your error handler to use dynamic memory allocation?
>

This depends on how often it happens.  In all cases, IMO, a success condition should result in nothing more than a 
POD-sized object (and I should add, no virtual table).  If it's a non-success condition that is "expected" (normal 
condition that's handled by the calling code), IMO this shouldn't print anything by default.  If it's a non-success 
that's also unexpected, printing is fine (including stack trace).

The problem with not passing back more than just an enum is that often more information is needed, and the place where 
it's available can't tell whether it's expected or unexpected.

But, going back to Vijay's timing information, I'm not sure it's worth the extra 5 orders of magnitude in cost (though 
I'm also curious why it's that large).

- tim

>> Here I think the "size" Tim mentions is related to the length of the
>> string, which will affect the performance of the copy constructor of
>> std::string, when this object is returned by value from MOAB routines.
>
> You could use a pointer so that there is no copy, but you have to
> allocate the string somewhere.
>


-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
  phone (gvoice): (608) 354-1459      1500 Engineering Dr.
             fax: (608) 263-4499      Madison, WI 53706