Re: [Alephmodular-devel] Organizing files wrt multiple platforms

[Br'fin <br...@ma...>]

ixNay on extensions like this.

What Bungie did with including .c files(now .cpp files) when dealing 
with Cross-platform support struck me as wrong when I realized this. 
AlephOne managed to take these areas and mangle them further.

We have classes we can use for encapsulation. We have the ability to 
define Class Foo and have platform specific subclass FooPlatform.

We have enough platform specific code that it might not fit within a 
single file so it could very well be

guiModular/
	sdl/
		sdlImplementationDisplay.h
		sdlImplementationDisplay.cpp
		...
	macosx/
		macosxImplementationDisplay.h
		macosxImplementationDisplay.cpp
		...
	display.h
	display.cpp

Now I admit that I have a better idea currently of what's wrong than 
what's right.
So I'm open to suggestions. But this is the wrong tangent.

-Jeremy Parsons

On Friday, January 3, 2003, at 02:33  PM, Michael Adams wrote:

> Extentions that I have seen used include ".inc"
> (include) and ".inl" (inline).  I have yet to see a
> definate standard.
>
> Michael D. Adams
> mdm...@ya...
>
> --- "Woody Zenfell, III" <woo...@sb...>
> wrote:
>> I'm finally getting around to posting some thoughts
>> I had sent to Br'fin
>> before the AM list was in place.  This is one such
>> message.
>>
>> The following is a message I sent to the M-Dev list
>> about a year ago,
>> but it seems relevant now again.  There's nothing
>> terribly exciting or
>> clever here, but it may spark some discussion.
>>
>> Note that with a movement toward classes and
>> objects, a lot of this
>> material may need to be rethought, FWIW.
>>
>> Woody
>>
>> ----- Original Message -----
>> From: "Woody Zenfell" <woo...@ho...>
>> Sent: Thursday, January 17, 2002 7:55 PM
>>
>>> Personally, I'd like to see some standardization
>> on the handling of
>>> chunks
>>> of code that differ for different platforms.
>> There are currently many,
>>> MANY
>>> ways this is done, which gets to be awfully
>> confusing.
>>>
>>> In my code, <basefilename>.cpp contains code for
>> both (all) platforms.
>>> <basefilename>_macintosh.cpp has code for the Mac
>> OS version;
>>> <basefilename>_sdl.cpp has code for the SDL
>> version.  I even tried to
>>> name
>>> ones that only apply to the SDL version
>> <whatever>_sdl.cpp to maintain
>>> this
>>> convention.  A .cpp file never #includes any other
>> .cpp file, so a
>>> project
>>> file will incorporate the
>> <basename>_<platform>.cpp AND <basename>.cpp
>>> (if
>>> it exists).
>>>
>>> One (non-trivial) drawback to my approach is that
>> elements that used to
>>> be
>>> file-private can no longer be (if they need to be
>> seen by both shared
>>> code
>>> and platform-specific code).  In those cases, I
>> made
>>> <basename>_private.h
>>> that's intended to be #included only by one or two
>> files.  <basename>.h
>>> continues to provide "externally visible" elements
>> to the rest of the
>>> code
>>> base.  This is still a sort of global namespace
>> pollution, and if the
>>> project got big enough, we could start to have
>> linkage problems as names
>>> conflict, but so far it seems to be OK.
>>>
>>> In some cases, there's like <basefilename>.cpp,
>> that #includes
>>> <basefilename>_<platform>.cpp depending on
>> preprocessor conditionals.
>>> This
>>> lets shared code and platform-specific code keep
>> their private elements
>>> private ("static").  But when managing the project
>> files, it's somewhat
>>> confusing - if you compile both <basename>.cpp and
>>> <basename>_<myplatform>.cpp, you have problems.
>>>
>>> In other cases, there's like
>> <basename>_<platform>.cpp, which #includes
>>> <basename>.cpp or <basename>_shared.cpp.  I
>> actually like this better
>>> than
>>> the above - it feels better having the project
>> files choose the branch
>>> rather than the preprocessor.  This, like the
>> previous one, preserves
>>> "privacy", but has the same multiple-definition
>> problem.  Unfortunately,
>>> it's more likely to produce errors at link-time
>> than compile-time,
>>> compared
>>> to the above.  (Earlier errors are better.
>> <basename>.cpp is more
>>> likely to
>>> compile on its own than <basename>_<platform>.cpp
>> would be, I think.)
>>>
>>> In general, I'd prefer to see .cpp files that are
>> #included by other
>>> .cpp
>>> files have a different extension.  I'm sure
>> there's one in standard use
>>> out
>>> there for this purpose (something like ".ipp"?).
>> It would make it
>>> clearer
>>> which one a project file should reference
>> directly, and which ones will
>>> get
>>> rolled in some other way.
>>>
>>> In still OTHER cases, there's like <basename>.cpp,
>> which gives
>>> Mac-specific
>>> routines, and <basename>_sdl.cpp, which gives
>> SDL-specific routines.  I
>>> don't like this, although (given the CVS and
>> project file hassles
>>> involved
>>> with renaming something) I understand how the
>> practice developed.
>>> Still, if
>>> someone's going to be massively reworking this
>> stuff, I'd prefer to see
>>> this
>>> cleaned up while the opportunity is at hand.
>>>
>>> I'm sure there are still a couple MORE conventions
>> used to combat this
>>> problem (base class/derived classes?  preprocessor
>> conditionalization
>>> within
>>> a single source file?), but those are all I
>> remember off the top of my
>>> head,
>>> and I think they're sufficient to illustrate the
>> problem.
>>>
>>> I guess I'd prefer to see something that allows
>> separate compilation but
>>> manages namespaces explicitly, like encapsulation
>> in classes or use of
>>> the
>>> C++ namespace construct.  But, it could be a major
>> pain to
>>> retroactively fit
>>> this onto existing code.  As a second choice, I
>> might like using
>>> <basename>_<platform>.cpp, which #includes
>>> <basename>.<included-source-extension> or
>>> <basename>_shared.<included-source-extension>.  As
>> a third choice, I
>>> like
>>> the other way around (basename.cpp #includes
>>> basename_platform.included-source-extension).
>> Note that perhaps oddly,
>>> I'm
>>> not too keen on my own scheme!  Oh well, it made
>> sense at the time, and
>>> I do
>>> like it better than the #include mechanisms if
>> included files have a
>>> .cpp
>>> extension (which, note, they did when I used my
>> scheme).
>>>
>>> Another option (not currently used) would be to
>> have subdirectories of
>>> each
>>> major source directory for Mac, SDL, etc.  Shared
>> code would live in the
>>> major source directory; platform-specific code
>> would live in one of the
>>> subdirectories.  It might still be nice for the
>> source files to have
>>> _sdl or
>>> _macintosh after them, though, to make it doubly
>> clear what file you're
>>> working with in your editor/build system.  I don't
>> know whether the
>>> subdirectories would be worth it, but it's
>> something to consider.
>>>
>>> Oh sure, heck, while we're airing out such things,
>> could I also say it
>>> annoys me that so many headers cover so many
>> source-files?  I mean,
>>> MSVC is
>>> smart enough to not recompile source files if no
>> "relevant" changes were
>>> made in the header, but most build systems aren't,
>> so changing a source
>>> file
>>> and an entry in its related header file forces you
>> to rebuild like half
>>> the
>>> project.  I mean, yeah yeah, interfaces are
>> supposed to be stable, etc.
>>
> === message truncated ===
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alephmodular-devel mailing list
> Ale...@li...
> https://lists.sourceforge.net/lists/listinfo/alephmodular-devel
>