Reducing dependencies

[Slawek]

Hi,

I know that this is one of the topics that are most popular but I just have
to ask.
Can anyone give me some links, info etc about following question:
- how to reduce code dependencies
- make the code less vurnelable for changes (interfaces?)

Question is becaues I'm starting a new project and I was wandering how to
design classes to make to reduce dependencies.

Also some links with explanation about how exactly compiling work what the
actual difference between global variables and those allocated via 'operator
new'.

This question came up becaues I read that in order to reduce dependencies I
can do something like this:

class CFile;

class CLog
{
CFile *m_pFile

public
..... //code.... ble ble
}

but if I do this I have to dynamically create CFile?

I started to think about It... and I get to conclusion that me C++ skills
are to pure.... to explain myslef what is better
(other option is:)

#include "File.h"

class CLog
{
CFile m_File

public
..... //code.... ble ble
}

this is not only think.... so some good resources about differences in
memory allocation.. (I understand the concept of operator new, but I want to
understand the consequences of it....)
Thanks for any help...

regards,
Slawek

[Gianni Mariani]

Slawek wrote:

Hi,

I know that this is one of the topics that are most popular but I just have
to ask.
Can anyone give me some links, info etc about following question:
- how to reduce code dependencies
- make the code less vurnelable for changes (interfaces?)

Microsoft's COM has a methodology that provides for managging interface
revisions.

All of COM's classes inherit from "IUnknown" and you can convert from
IUnknown to another interface using the QueryInterface method.

This can be achieved using standard C++ mechanisms and I have used them
in non-COM based systems.

Another mechanism is PIMPL. You can look that up on google.

[peter steiner]

> class CFile;

class CLog
{
CFile *m_pFile

public
.... //code.... ble ble
}

let me try to explain the difference between your two examples:

in the first definition CLog only contains a pointer to CFile, which is
why the type doesn't have to be fully known at declaration time
(forward declaration suffices, no include necessary).

the difference to your latter example, storing an instance of CFile, is
that the compiler knows to work with pointers without complete type
information as long as you don't dereference them (by using ptr->member
or *ptr). e.g. pointers are always the same size, regardless of their
pointee type, so by looking at the above declaration the compiler knows
how to store m_pFile in the CLog binary signature. this is not true if
you store instances, as in your latter example.

imagine that you add a member to CFile during later development. CFile
will grow in memory size because of the new member. CLog's signature
will not change if you chose a pointer to CFile, but it would have had
you chosen to store a CFile instance in CLog. thus, a change to CFile
does not require a recompilation of any classes that store a pointer to
CFile instances, all classes that store the instances themselves have
to be recompiled.

unfortunately tricks like this one or others like the more general
pimpl idiom are only valid if you work with one specific version of one
compiler, as the application binary interface of the implementation may
change over different versions and different compiler vendors do not
guarantee inter-compatibility. this also applies to the STL. you may
want to look into interface specs like CORBA or COM or use C linkage
(extern "C"...) for your visible interfaces if you strive for total
compatibility.

the following kde design doc gives more information on c++ binary
compatibility gotchas:
http://webcvs.kde.org/*checkout*/dev...atibility.html

-- peter