#1055 common subdir for parallelization related headers

I think this is a very good idea. Indeed, dune/common is very crowded and in my opinion, we should think about moving most headers into suitable subdirectories.

We currently have headers related to c++11 - static_assert.hh nullptr.hh tuples.hh shared_ptr.hh typetraits.hh io - debugstream.hh stdstreams.hh (+cc) indent.hh path.hh ios_state.hh (+cc) container - array.hh arraylist.hh bitsetvector.hh sllist.hh iterator - genericiterator.hh iteratorfacades.hh parallel - collectivecommunication.hh mpicollectivecommunication.hh mpiguard.hh mpihelper.hh mpitraits.hh math - float_cmp.hh (+cc) matvectraits.hh math.hh gmpfield.hh precision.hh fassign.hh math/matrix - densematrix.hh dynmatrix.hh fmatrix.hh fmatrixev.hh (+cc) math/vector - densevector.hh dotproduct.hh dynvector.hh fvector.hh

The list is definitely neither perfect nor complete, but it gives a rough idea about the cluttered state von dune/common.

Other opinions?

I would also like to add a few directories and Matrin's suggestion looks reasonable (although math, math/vector, math/matrix is a bit more than I would have suggested...)

Feel free to improve the suggestion. I was merely trying to keep the number of headers per subdirectory small. Just a math subdirectory will be sufficient for me, too.

Putting/moving some additional parallel headers into common/parallel is something I can live with.

Concerning the other suggestions I just have to ask:

What are the actual gains of introducing yet more subdirectories?

The cons are clear to me:

Lots of user code has to be changed
more Makefile.am files have to be parsed.
Merging from branches becomes more complicated

The obvious pro is the improved structure. We can even start splitting some files, so that it is easier to find the file containing the class I seek.

As to your cons:

The changing of user code is as simple as a good sed script.
I don't think a few Makefile.am files are so interesting, especially since we're migrating to cmake.
Isn't this problem solved by using git?

I'm also not convinced by most of the cons Markus mentioned but think that 63 header files in one directory is much to much for users to find classes in the module. In addition this number has been nicely increasing over the years: headers in common | how long ago head: 63 | rev 6500: 65 | 1 year rev 6000: 55 | 2.5 years rev 5500: 47 | 3.5 years rev 5000: 40 | 5 years That looks quite linear - more than 1 header every 2 months (except the latest value no idea where those headers disappeared to - perhaps dune-geometry... extrapolating gives us about 100 headers in 2018 :-)

I second Christian's proposial. Maybe binaryfunctions.hh can be moved to parallel/, too. It is only used in ComposeMPIOps in mpicollectivecommunication.hh (see #600 (closed)).

Like Markus I don't see a benefit in creating to many folders. What is the benefit of a folder containing 2 to 4 headers? Searching for the right file is harder for me; I usually have to look in multiple folders because it is rarely obvious to what folder a header belongs. I. e. in Martin's suggestion, I'd expect array.hh in c++11.

Concerning Andreas statistics, I don't see the problem. The number of dune core modules is growing over the time, too. Many files contain useful features and I don't want to miss the features we gained in the last 5 years.

I just migrated the parallel headers to the subdirectory in my own branch (without compatibility). Using the attached script, adapting all my other modules (dune-common had to be done by hand) took only a few commits.

As we seem to agree on moving the parallel headers, you can check for yourself whether moving the headers is a problem or not. Of course, the main branch of dune-common should provide compatibility headers for one release cycle.

Attachments

chginclude.sh

@Chrsitoph: did I say I wanted to remove any feature from dune-common? I just wanted dune-common cleaned up but keeping all the functionality.

@Andreas: I think you misread/misinterpreted Christoph's post. IMHO he (like me BTW) is not seeing how finding a class is easier with more subdirectories.

I publicly declare that I am indifferent to this issue. I feel no urgent need for additional subdirectories, but I will not oppose changes either.

I don't want to mix different questions here. The proposal was to move the parallel headers into a subdirectory.

The questions about further subdirectories, I would like to keep separate and I'm also not sure yet, what I prefer.

I create a doodle for a formal vote on this topic.

All Core-Developers... please have a look at http://users.dune-project.org/doodles/2

We have 8 votes for the change and two abstentions. I'll take care of this switch.

common is updated, all other core modules are wip.

here is a script to update the headers of your module

Attachments

update-parallel-headers.sh

Status changed to closed

Property	Value
Reported by	Christian Engwer (christi@conan.iwr.uni-heidelberg.de)
Reported at	Mar 20, 2012 20:22
Type	Bug Report
Version	Git (pre2.4) [autotools]
Operating System	Unspecified / All
Last edited by	Christian Engwer (christi@conan.iwr.uni-heidelberg.de)
Last edited at	Nov 6, 2012 15:36
Closed by	Christian Engwer (christi@conan.iwr.uni-heidelberg.de)
Closed at	Nov 6, 2012 15:36
Closed in version	Unknown
Resolution	Implemented
Comment

#1055 common subdir for parallelization related headers

Metadata

Description

Designs

Child items ...

Activity

Attachments

Attachments