[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