Board index » cppbuilder » Disabling Auto-dependencies in BCB 2006

Disabling Auto-dependencies in BCB 2006


2005-12-22 10:49:32 PM
cppbuilder21
Within the BCB 2006 IDE it seems there is no way of disabling
auto-dependencies, which can be very frustrating when it comes to making
small changes and compiling the software. This appeared to be the same
in BCB 6. In Borland C++ 5.02 you could disable auto-dependencies.
i.e. when a cpp file includes a header file
If I change the header file, I would like to choose whether the cpp file
is recompiled or not. There are many circumstances when a recompile of
large sections of a project is not required.
The -X option does not seem to achieve this, as I believe this is
primarily to do with the contents of the object files rather than
whether to re-create them in the first place.
Thanks for any advice. Hopefully I am missing something obvious.
Regards
Charles
 
 

Re:Disabling Auto-dependencies in BCB 2006

"Charles Pope" < XXXX@XXXXX.COM >wrote in message
Quote
i.e. when a cpp file includes a header file
If I change the header file, I would like to choose whether the
cpp file is recompiled or not. There are many circumstances
when a recompile of large sections of a project is not required.
If you change an .h file, then every .cpp file that uses that .h file has to
be recompiled. There is no option to avoid that, other than to not have
large .h files in the first place.
Gambit
 

Re:Disabling Auto-dependencies in BCB 2006

Charles Pope < XXXX@XXXXX.COM >writes:
Quote
Within the BCB 2006 IDE it seems there is no way of disabling
auto-dependencies, which can be very frustrating when it comes to making
small changes and compiling the software. This appeared to be the same
in BCB 6. In Borland C++ 5.02 you could disable auto-dependencies.
It is not possible for the compiler to know if your change is "small"
or not, and if code depends on a header that changes, then effectively
the .cpp file also changed and needs recompilation.
If you can change a header in such a way that it doesn't affect source
code that includes it, it makes me wonder a few things:
* why does a source file include a header if it doesn't need to be
recompiled when the header changes?
* do you really need to include the header in the first place?
* does your change actually belong in this header?
* can you use incomplete types and forward declarations instead of
including the header?
It's hard to put a finger on what it is, but something about your
question just seems a bit strange to me. Can you give an example of
why/when this situation arises, and what's a valid reason to not need
to compile your code that includes a changed header?
--
Chris (TeamB);
 

{smallsort}

Re:Disabling Auto-dependencies in BCB 2006

Charles Pope wrote:
Quote
Within the BCB 2006 IDE it seems there is no way of disabling
auto-dependencies, which can be very frustrating when it comes to making
small changes and compiling the software.
I recommend that you break your units into smaller pieces. For example,
most complex classes have some helper declarations, such as constants
and types used by the large class. If everything is in a single unit,
you have no choice but to include the large .h file, and every time you
make the smallest change to the implementation, you have to recompile
all dependents. However, a lot of your application code won't even need
to include the large class, you just need a few types and constants.
It's better to separate those two things, like this:
// MySuperViewerCommon.h
const int MaxItems = 256;
enum ListType { SmallList, LargeList };
struct SearchResult
{
int Relevance;
std::string Caption;
};
typedef std::deque<SearchResult>SearchResultCollection;
------------------------------------
// MySuperViewer.h
#include "MySuperViewerCommon.h"
class TMySuperViewer: public TGraphicControl
{
// [...]
There's one more concept called the pimpl idiom:
www.gotw.ca/gotw/024.htm
www.gotw.ca/publications/mill05.htm
The basic idea is to create a small wrapper for those large classes that
have too many dependencies, and use forward declaration to avoid
including unnecessary implementation details that change too often. You
need to do some extra typing, but you'll save time in the long run.
Also, this concept forces you to design a well thought-out interface,
instead of taking short-cuts which help only in the very short term, but
introduce maintenance nightmare in the long run.
Tom
 

Re:Disabling Auto-dependencies in BCB 2006

Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote:
Quote
If you can change a header in such a way that it doesn't affect source
code that includes it, it makes me wonder a few things:

* why does a source file include a header if it doesn't need to be
recompiled when the header changes?
I can think of one reason: because C++ doesn't allow you to declare
partially complete types. Say, for instance, your header does one thing
- it declares a class, with the member functions, inline accessors, data
members and whatever other things a client needs to know.
And then you want to add an extra private member function, one to help
the internals of implementation, one that no client actually wants to
know about.
Unfortunately, all the clients think they need to recompile. Even if its
a change no client could actually detect - the declaration of a new
member function that is not virtual, that doesn't cause any namespace
clashes, no nothing.
It's a problem that, IMO, only allowing the reopening of a class
definition would allow one to get round - that, or a sufficiently
intelligent compiler that can determine that there is no effective
change in the result.
Quote
* do you really need to include the header in the first place?
In the above case - yes.
Quote
* does your change actually belong in this header?
In the above case - yes.
Quote
* can you use incomplete types and forward declarations instead of
including the header?
Sometimes, you can. But eventually, something often wants to know what a
class actually looks like. You can't hide behind pimpls for ever.
Derived classes, for instance.
Of course, that may not be the case here.
Alan Bellingham
--
Team Thai Kingdom
<url:www.borland.com/newsgroups/>Borland newsgroup descriptions
<url:www.borland.com/newsgroups/netiquette.html>netiquette
 

Re:Disabling Auto-dependencies in BCB 2006

Alan, Chris, Remy & Tamas. Thank you for the comments.
Quote
>If you can change a header in such a way that it doesn't affect source
>code that includes it, it makes me wonder a few things:
>
>* why does a source file include a header if it doesn't need to be
>recompiled when the header changes?

If you are using precompiled headers, then it can be more efficient to
have a standard set of headers so that they are just precompiled once.
This was the technique we used with Borland C++ 5.02 to get fast compile
times. Here there was the option to turn off auto-dependencies.
It is a bit frustrating that you cannot manually override the IDE. I
understand it is trying to help - but sometimes I would like to manually
decide what to do.
Quote

I can think of one reason: because C++ doesn't allow you to declare
partially complete types. Say, for instance, your header does one thing
- it declares a class, with the member functions, inline accessors, data
members and whatever other things a client needs to know.

And then you want to add an extra private member function, one to help
the internals of implementation, one that no client actually wants to
know about.

Unfortunately, all the clients think they need to recompile. Even if its
a change no client could actually detect - the declaration of a new
member function that is not virtual, that doesn't cause any namespace
clashes, no nothing.

It's a problem that, IMO, only allowing the reopening of a class
definition would allow one to get round - that, or a sufficiently
intelligent compiler that can determine that there is no effective
change in the result.


>* do you really need to include the header in the first place?


In the above case - yes.


>* does your change actually belong in this header?


In the above case - yes.


>* can you use incomplete types and forward declarations instead of
>including the header?


Sometimes, you can. But eventually, something often wants to know what a
class actually looks like. You can't hide behind pimpls for ever.
Derived classes, for instance.

Of course, that may not be the case here.

Also, simple changes such as adding comments force a recompile.
However, it mainly relates to our use of precompiled headers which are
to some extent in conflict with the principle of minimal includes.
I appreciate all the help.
Thanks
Charles
 

Re:Disabling Auto-dependencies in BCB 2006

Charles Pope < XXXX@XXXXX.COM >wrote:
Quote
However, it mainly relates to our use of precompiled headers which are
to some extent in conflict with the principle of minimal includes.
On the whole, precompiled headers are (a) a good idea, and (b) should
not include anything that's going to change. I agree with minimal
include and, every now and then, disable the PrecompiledHeaders.h file.
I'd drop windows.h, vector, string, anything supplied by libraries that
I include more than once.
Alan Bellingham
--
Team Thai Kingdom
<url:www.borland.com/newsgroups/>Borland newsgroup descriptions
<url:www.borland.com/newsgroups/netiquette.html>netiquette
 

Re:Disabling Auto-dependencies in BCB 2006

"Alan Bellingham" < XXXX@XXXXX.COM >wrote in message
Quote
And then you want to add an extra private member function, one
to help the internals of implementation, one that no client actually
wants to know about.
To avoid recompiling, you could make the function be a non-member function,
place it in the .cpp file, and pass the object as a parameter. The .h file
wouldn't know anything about it.
Quote
Unfortunately, all the clients think they need to recompile. Even if
its a change no client could actually detect - the declaration of a
new member function that is not virtual, that doesn't cause any
namespace clashes, no nothing.
It does, however, potentially change the VMT even if it is not a virtual
method, and thus the offsets of the other methods in the class are effected,
and thus does effect thecompilation of any code that uses the class.
Quote
It's a problem that, IMO, only allowing the reopening of a class
definition would allow one to get round - that, or a sufficiently
intelligent compiler that can determine that there is no effective
change in the result.
There is no way to determine that, though. Making a change in a .h file
does potentially have side-effects that the compiler simply cannot detect
ahead of time, so everything that uses the changed.h has to be recompiled to
make sure everything is accounted for.
Gambit
 

Re:Disabling Auto-dependencies in BCB 2006

"Remy Lebeau \(TeamB\)" < XXXX@XXXXX.COM >wrote:
Quote
>Unfortunately, all the clients think they need to recompile. Even if
>its a change no client could actually detect - the declaration of a
>new member function that is not virtual, that doesn't cause any
>namespace clashes, no nothing.

It does, however, potentially change the VMT even if it is not a virtual
method, and thus the offsets of the other methods in the class are effected,
and thus does effect thecompilation of any code that uses the class.
Exactly how does it do that?
A _virtual_ function, yes. But non-virtuals aren't (or shouldn't be)
mentioned in the VMT. A non-virtual member function is nothing
particularly magical - it may be considered to have hidden 'this'
parameter, and of course it gets access rights. But it's not like a data
member, where a pointer-to-member has an offset that does depend on the
other members.
Quote
There is no way to determine that, though. Making a change in a .h file
does potentially have side-effects that the compiler simply cannot detect
ahead of time, so everything that uses the changed.h has to be recompiled to
make sure everything is accounted for.
A sufficiently intelligent compiler could determine that no unsafe
change had taken place - on the other hand, the quickest way to do it
might be to compile and then see if the object file differed!
Alan Bellingham
--
Team Thai Kingdom
<url:www.borland.com/newsgroups/>Borland newsgroup descriptions
<url:www.borland.com/newsgroups/netiquette.html>netiquette
 

Re:Disabling Auto-dependencies in BCB 2006

Quote
>However, it mainly relates to our use of precompiled headers which are
>to some extent in conflict with the principle of minimal includes.


On the whole, precompiled headers are (a) a good idea, and (b) should
not include anything that's going to change. I agree with minimal
include and, every now and then, disable the PrecompiledHeaders.h file.

I'd drop windows.h, vector, string, anything supplied by libraries that
I include more than once.
Thanks Alan. I guess a good review is in order, although I think it
would be nice to have the ability to turn the automation off.
Charles