View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000059OpenFOAMBugpublic2010-10-21 15:482010-11-01 18:07
Reporteruser26Assigned Touser4 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status resolvedResolutionfixed 
PlatformLinuxOSOpenSuseOS Version11.3
Summary0000059: Size control in DynamicField
DescriptionIs there a possibility of having a templated size-control option (i.e., using a SizeInc/SizeMult/SizeDiv) for DynamicField, similar to the DynamicList approach? It would be better than blindly increasing the size of the field by 2, like it is right now.

I don't see this being an issue from a programming stand-point, but it would be a nice feature to have.

A less urgent feature-request would be to implement features that have been left out of DynamicField (like the remove() member, clearStorage(), etc..)
TagsNo tags attached.

Activities

user4

2010-10-22 11:42

  ~0000088

DynamicField is lagging a bit with respect to DynamicList. Feel free to add the missing bits (also the size control) and send them to me.

user26

2010-10-23 19:43

 

DynFieldModifications.tgz (4,384 bytes)

user26

2010-10-23 19:54

  ~0000089

I've uploaded the modifications with (most of) the missing bits. It mostly mimics the DynamicList functionality, but I was unsure about adding other Field functions like xfer(), transfer(), map(), rmap(), etc... I guess the inheritance hierarchy takes care of those for the moment, but pointer bugs may arise if we're not careful, so I leave that analysis to you.

I also noticed that the constructor for DynamicList specifies an over-ride for the underlying size:

template<class T, unsigned SizeInc, unsigned SizeMult, unsigned SizeDiv>
inline Foam::DynamicList<T, SizeInc, SizeMult, SizeDiv>::DynamicList
(
    const label nElem
)
:
    List<T>(nElem),
    capacity_(nElem)
{
    // we could also enforce SizeInc granularity when (!SizeMult || !SizeDiv)
    List<T>::size(0); <--- Shouldn't this not be there??
}

I agree that memory is un-initialized, but it gives the false impression that the List is sized to 'nElem', while it's artificially set to zero. Is this behaviour intentional?

user4

2010-10-29 13:36

  ~0000102

I've updated DynamicField (commit 96dcbab7e165db56d78f36d14349b7db9777e1ea).

- I've removed the tmp handling - do you need it?
- the List::size(0) is intentional. That constructor just allocates memory which you then can fill with 'append'.

user26

2010-11-01 17:07

  ~0000110

I guess this level of functionality should suffice for now, thanks.

user4

2010-11-01 18:07

  ~0000111

commit 96dcbab7e165db56d78f36d14349b7db9777e1ea

Issue History

Date Modified Username Field Change
2010-10-21 15:48 user26 New Issue
2010-10-21 16:16 henry Assigned To => user4
2010-10-21 16:16 henry Status new => assigned
2010-10-22 11:42 user4 Note Added: 0000088
2010-10-23 19:43 user26 File Added: DynFieldModifications.tgz
2010-10-23 19:54 user26 Note Added: 0000089
2010-10-29 13:36 user4 Note Added: 0000102
2010-11-01 17:07 user26 Note Added: 0000110
2010-11-01 18:07 user4 Note Added: 0000111
2010-11-01 18:07 user4 Status assigned => resolved
2010-11-01 18:07 user4 Resolution open => fixed