A
adamcrew
Hi,
I'm not sure if this is truly a C++ question, but it's something that
has only come up now that I'm working in a C++ environment.
Essetnially, what has happened is that I've come in to a new job where
there has been no form of source control and been asked to co-ordinate
the implementation of one. I was nice and comforable with the task
until I found out about a practice that wasn't used in my previous C
programming job.
What is happening is that people are creating classes in .cpp files, as
you might expect, within a module and compiling them in there. No
problem, except that they also choose to compile them in other modules
too by making explicit references to them, e.g.
X:\devel\src\aModule\sharedclass.cpp. Notice that X:\ is a network
drive containing the master copy of our code.
This has worked fine for them in the past (even though it forces them
to make possibly untested code public), but moving over to a source
code repository instead has me scratching my head for the best way to
cope with this.
I had thought of changing the explicit references to become relative,
so ..\..\src\aModule\sharedclass.cpp, but this means that compilation
wouldn't work unless the person had checked out all modules containing
..cpp files required by the module they're really working on and have
checked out in their local area. Since the area set aside for such
files appears to be 1.2GB, I'd prefer not to have to do that.
I guess the first question I have is whether the sharing of .cpp files
like this is good C++ practice. My way of thinking would have been to
have a separate library containing the class - and maybe some others -
and having all modules that want access to it link it in. However,
this process is so widespread in the company that I'm thinking that I
must be missing something.
Even if it is bad practice, it looks like it's something I'm going to
have to account for in the short to medium term anyway. Are there
better solutions than to force everyone to constantly have the shared
area checked out and up-to-date?
As we're working with Visual C++, it's possible to easily change the
location it's looking for the shared file in during development, then
change it back before committing the change, but I'm trying to avoid
this. For one, it's a fiddle and, secondly, it's just asking for
someone - probably me - to forget to change the path back.
Any thoughts and help would be appreciated. It would be nice to be
able to come up with a good solution as opposed to the far from perfect
one I have at the moment.
Thanks,
Adam.
I'm not sure if this is truly a C++ question, but it's something that
has only come up now that I'm working in a C++ environment.
Essetnially, what has happened is that I've come in to a new job where
there has been no form of source control and been asked to co-ordinate
the implementation of one. I was nice and comforable with the task
until I found out about a practice that wasn't used in my previous C
programming job.
What is happening is that people are creating classes in .cpp files, as
you might expect, within a module and compiling them in there. No
problem, except that they also choose to compile them in other modules
too by making explicit references to them, e.g.
X:\devel\src\aModule\sharedclass.cpp. Notice that X:\ is a network
drive containing the master copy of our code.
This has worked fine for them in the past (even though it forces them
to make possibly untested code public), but moving over to a source
code repository instead has me scratching my head for the best way to
cope with this.
I had thought of changing the explicit references to become relative,
so ..\..\src\aModule\sharedclass.cpp, but this means that compilation
wouldn't work unless the person had checked out all modules containing
..cpp files required by the module they're really working on and have
checked out in their local area. Since the area set aside for such
files appears to be 1.2GB, I'd prefer not to have to do that.
I guess the first question I have is whether the sharing of .cpp files
like this is good C++ practice. My way of thinking would have been to
have a separate library containing the class - and maybe some others -
and having all modules that want access to it link it in. However,
this process is so widespread in the company that I'm thinking that I
must be missing something.
Even if it is bad practice, it looks like it's something I'm going to
have to account for in the short to medium term anyway. Are there
better solutions than to force everyone to constantly have the shared
area checked out and up-to-date?
As we're working with Visual C++, it's possible to easily change the
location it's looking for the shared file in during development, then
change it back before committing the change, but I'm trying to avoid
this. For one, it's a fiddle and, secondly, it's just asking for
someone - probably me - to forget to change the path back.
Any thoughts and help would be appreciated. It would be nice to be
able to come up with a good solution as opposed to the far from perfect
one I have at the moment.
Thanks,
Adam.