Re: [Fresco-devel] Suggested addition to Coding Style-guide

Gabriel Dos Reis wrote:
> Neil Pilgrim <[email protected]> writes:

> |   class some_type;
> |   namespace type_space
> |   {
> |     class some_type;
> |   };
> |   /* ... */
[...]
> | In quite a few instances (if not a *lot*!) we don't currently do this;
> | it seems like a good common idea, so assuming no discussion to the
> | contrary it'd be good to add it to the coding guide. Oh, and implement
> | it ;)
[...]

> I would suggest you don't repeat declarations all over the places as
> suggested above.
> While that might be seem a reasonable practice in C, it is recommanded
> for C++ coding that you :
> 
>    (a) include the appropriate header files
>    (b) design a forward-declaration header and do (a)
> 
> The point is that C++ tends to be very picky about declarations and
> name-lookup are already complicate; it is better to include a heade
> file that provides the "true" declarations in every translation unit.
> 
> You'll also find that what you're proposing does not scale to standard
> types and functions.  It is therefore preferable to have a coding
> style that apply both to standard headers and Fresco entities.

This may be ideal, but then surely you either a) end up having a huge
number of files (one per previous header?) b) one per section?

Neither of these sounds particularly good. I appreciate that with the
standard library it is normal to just include the headers, but I see no
problem with treating the use of the standard library and our internal
libraries differently. I'm not suggesting that we predeclare data which
is described in other projects' headers (whether libstdc++ or libc - or
equivalents), since it is easier to keep portability/compatibility in
those cases (even though, for example, std::string is always
basic_string<char> IIRC). Within the project it doesn't strike me as a
great problem. Arguably Prague, Babylon, etc. are separate projects in a
way, but I'm not sure that this is important here.

Maybe build times cannot be drastically reduced with this method, but in
my limited experience it can be very useful in limiting the dead time
during development.

-- 
Neil