Prev: Stack overflow using boost::operators
Next: Code Optimization
From: Goran Pusic on 16 Dec 2009 21:02
Hi all!

>From time to time, I find myself using extern declaration for small
utility functions used sparsely in different places in the code base
(e.g. having it in one *.cpp, but also calling it in one/two others).
It's itching me somewhat. A text book would recommend having a header
containing relevant external declarations, and including that.

However, that opens the question of granularity of such "utility"
headers. E.g. I find "one to rule them all" unacceptable (on the code
base I have here), because that would produce one hell of a mix of
concerns and downright silly compile-time dependencies. On the other
hand, having dozens of headers, each with a couple of functions, if
that, seems like a monumental waste of file system's directory
entries.

So... Any opinions, sentiments, cut-off numbers, for one or the other
approach?

Goran.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Bo Persson on 17 Dec 2009 07:48
Goran Pusic wrote:
> Hi all!
>
>> From time to time, I find myself using extern declaration for small
> utility functions used sparsely in different places in the code base
> (e.g. having it in one *.cpp, but also calling it in one/two
> others). It's itching me somewhat. A text book would recommend
> having a header containing relevant external declarations, and
> including that.
>
> However, that opens the question of granularity of such "utility"
> headers. E.g. I find "one to rule them all" unacceptable (on the
> code base I have here), because that would produce one hell of a
> mix of concerns and downright silly compile-time dependencies. On
> the other hand, having dozens of headers, each with a couple of
> functions, if that, seems like a monumental waste of file system's
> directory entries.
>
> So... Any opinions, sentiments, cut-off numbers, for one or the
> other approach?
>
> Goran.

Directory entries are cheap!

The separate extern declarations work fine, until one day when you
make a spelling mistake. The time it takes to find out why nothing
works anymore, might be worth a whole box of hard disks.

If you have only one copy of the declaration, it will surely be
identical everywhere.


Bo Persson



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Francis Glassborow on 17 Dec 2009 07:49
Goran Pusic wrote:
> Hi all!
>
>>From time to time, I find myself using extern declaration for small
> utility functions used sparsely in different places in the code base
> (e.g. having it in one *.cpp, but also calling it in one/two others).
> It's itching me somewhat. A text book would recommend having a header
> containing relevant external declarations, and including that.
>
> However, that opens the question of granularity of such "utility"
> headers. E.g. I find "one to rule them all" unacceptable (on the code
> base I have here), because that would produce one hell of a mix of
> concerns and downright silly compile-time dependencies. On the other
> hand, having dozens of headers, each with a couple of functions, if
> that, seems like a monumental waste of file system's directory
> entries.
>
> So... Any opinions, sentiments, cut-off numbers, for one or the other
> approach?
>
> Goran.
>

Look at the Standard C++ Library. That seems a reasonable compromise wrt
granularity.

Another thing worth considering is to have fairly fine granularity at
the lowest level but then batch them together user level header files.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Tony Delroy on 18 Dec 2009 21:44
On Dec 17, 11:02 pm, Goran Pusic <gor...(a)cse-semaphore.com> wrote:
> Hi all!
>
> >From time to time, I find myself using extern declaration for small
>
> utility functions used sparsely in different places in the code base
> (e.g. having it in one *.cpp, but also calling it in one/two others).
> It's itching me somewhat. A text book would recommend having a header
> containing relevant external declarations, and including that.
>
> However, that opens the question of granularity of such "utility"
> headers. E.g. I find "one to rule them all" unacceptable (on the code
> base I have here), because that would produce one hell of a mix of
> concerns and downright silly compile-time dependencies. On the other
> hand, having dozens of headers, each with a couple of functions, if
> that, seems like a monumental waste of file system's directory
> entries.
>
> So... Any opinions, sentiments, cut-off numbers, for one or the other
> approach?

- don't arbitrarily aim to minimise compile-time dependencies: match
the aggressiveness of your efforts to the problems/benefits involved,
as it takes time and involves other compromises
- consider separate forward-declaration headers where useful (ala
<iosfwd>)
- should be co-located with and included by the normal header
- create headers based on their physical dependencies: grouping stuff
with small or similar downstream #includes
- create higher-level headers based on logical grouping: these include
a set of the headers mentioned in the line above
- design to control the way downstream code changes force client code
recompilation, and how much downstream implementation is in the
headers
- pImpl idiom
- interfaces
- separate headers / out-of-line implementation for common
instantiations of template/inline code
etc.

Cheers,
Tony


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 | 
Pages: 1
Prev: Stack overflow using boost::operators
Next: Code Optimization