Writing Compile-time Independent Code

[Scott Brady Drummonds]

Hi, everyone,

I'm working on a software project that contains some C++ code that I would
like to be common to two separate projects. Ideally, I'd like to have each
of these separate projects conditionally compile and link the common code
per environment configuration. However, I feel that the very nature of this
common code (that it is mutually compile- and link-time dependent with the
software projects) precludes this type of setup. As such, I think that the
solution may fall into the realm of programming instead of build environment
configuration.

In an independent discussion I've been having in a build environment mailing
list, someone mentioned that I should investigate a plugin type architecture
for this solution. I believe the implication here is that stub header files
are provided, perhaps in conjunction with dummy libraries, that serve as
interfaces to real libraries that might be statically or dynamically linked
later, or even executed as a separate process. However, I'm not quite
certain.

Can anyone recommend a book, webpage, or example code that would show me how
I can break physical dependencies in logically dependent C++ code? I've
enjoyed some of the techniques in the John Lakos book
(_Large_Scale_C ++_Programming_ , I belive) but think that I need another
physical-minded C++ design book to help me out.

Thank you for your help!
Scott

--
Remove ".nospam" from the user ID in my e-mail to reply via e-mail.

[Nick Keighley]

Re: Writing Compile-time Independent Code

"Scott Brady Drummonds" <scott.b.drummo nds.nospam@inte l.com> wrote in message news:<bfn2tf$nt 2$1@news01.inte l.com>...

there are bits of your post I didn't quite follow.
[color=blue]
> I'm working on a software project that contains some C++ code that I would
> like to be common to two separate projects.[/color]

sounds straight forward. Make the common code into a library
(or libraries). Suppose project-A has a big lump of code to manage say,
sockets. And you now need project-B to also manage sockets. Create a socket
library from the project-A code. Compile and link it with the two
projects.
[color=blue]
> Ideally, I'd like to have each
> of these separate projects conditionally compile and link the common code
> per environment configuration.[/color]

not sure where the conditional compilation came from. I've sometimes
found it hard to manage. I think I need to know more about what you're
trying to do.
[color=blue]
> [...] However, I feel that the very nature of this
> common code (that it is mutually compile- and link-time dependent with the
> software projects) precludes this type of setup.[/color]

lost me.

[color=blue]
> [...] As such, I think that the
> solution may fall into the realm of programming instead of build environment
> configuration.[/color]

?

[color=blue]
> In an independent discussion I've been having in a build environment mailing
> list, someone mentioned that I should investigate a plugin type architecture
> for this solution. I believe the implication here is that stub header files
> are provided, perhaps in conjunction with dummy libraries, that serve as
> interfaces to real libraries that might be statically or dynamically linked
> later, or even executed as a separate process. However, I'm not quite
> certain.[/color]

ask the person who sugested this

<snip>


--
Nick Keighley