[MOAB-dev] r4250 - MOAB/trunk/tools/dagmc

Jason Kraftcheck kraftche at cae.wisc.edu
Thu Nov 4 12:41:52 CDT 2010


On 11/04/2010 12:11 PM, Steve Jackson wrote:
> 
> On Nov 4, 2010, at 5:05 , Tim Tautges wrote:
> 
>> 
>> 
>> On 11/03/2010 11:15 PM, Paul Wilson wrote:
>> 
>>> Theoretically, a standard-compliant replacement could be...
>>> 
>>> CartVect *coords; coords = new CartVect(nverts);
>>> 
>> 
>> The disadvantage of this usage is you have to remember to delete, which
>> can be a nuisance if you have multiple exit points.
> 
> Depending on how the compiler support for the variable-length-array
> syntax is implemented, calling new/delete may also have notably poorer
> performance.
> 

But that isn't the issue because there is no portable way to do achieve
equivalent performance.  The only portable options are std::vector and
new[], both of which very likely have exactly same cost.

Actually, I take that back.  I have encountered one case when working with
large dynamic arrays where new[] was much faster than std::vector because of
the annoying behavior of the C++ standard with respect to constructors for
intrinsic types that basically results in std::vector zeroing all values at
allocation time.

I have encountered cases in a different code where both of these were
issues.  However, they seldom really are.  Most malloc/free implementations
are quite efficient.  And you need to be frequently created/destroying very
large arrays for the zero-ing to be an issue.

Anyway, I had considered at one time implementing a class that provided the
requisite performance portably.  It would be a template container with two
arguments: the contained type and a constant hint as to a likely maximum
size.  The class would contain a fixed size array of the hint size and a
pointer to either that array or a dynamically allocated one if the hint size
was insufficient.  This could be augmented with some configure checks to
maybe use dynamic-sized arrays if configure determined that they were
supported, but they'd have to be supported as members of a struct/class and
that would likely limit the use of the class itself to a local stack
variable (no dynamic allocation or global variables or struct/class
members). Something like alloca would never be usable unless one used
preprocessor macros rather than a wrapper class for the
declaration/construction.

- jason


More information about the moab-dev mailing list