Marco van de Voort wrote:
Do you mean that only one level of dependencies must be checked with
uses, whereas even the indirectly #included files must be checked for
changes?
You always have to do the #include. Always. Pre-compiled headers are
possible, not trivial, since it requires a
Marco van de Voort wrote:
The definitions of templates, inline procedures or macros do not
immediately contribute to the size of a compiled module, only when they
are *used* in code modules.
That goes for all routines.
I'm not sure what you mean. A global procedure, exported in the
Marco van de Voort wrote:
immediately contribute to the size of a compiled module, only when they
are *used* in code modules.
That goes for all routines.
I'm not sure what you mean. A global procedure, exported in the
interface section of a unit, always must be be compiled.
Micha Nelissen wrote:
Perhaps you missed that in C/C++ the preprocessor is typically (99.999%)
used to include header files, not source files. This is comparable to
Pascal uses, not to {$Include}!
What's the difference between a 'header' file, and a source file ? Header
files often
Micha Nelissen wrote:
Perhaps you missed that in C/C++ the preprocessor is typically (99.999%)
used to include header files, not source files. This is comparable to
Pascal uses, not to {$Include}!
What's the difference between a 'header' file, and a source file ? Header
files
The only *disadvantage* of units are the current Pascal compilers, which
cannot handle circular unit references :-(
No, it's an advantage: it makes the code and design clearer, plus
it increases the speed of compilation a *lot*.
note: you can have cuircular implementation references just
Florian Klaempfl wrote:
C++ creates one monster module in this case as well.
I disagree. Neither the declarations (interface, header files) nor the
definitions (implementation, code modules) must reside in one file.
How the sources are splitted doesn't matter. The compiler handles it
Micha Nelissen wrote:
The real question is: was the design of the code ok ?
Some dependencies cannot be removed by a redesign :-(
In some cases interfaces instead of classes can help, because they don't
need implementation in the same unit. But then the classes have to be
implemented as well.
DrDiettrich wrote:
Florian Klaempfl wrote:
C++ creates one monster module in this case as well.
I disagree. Neither the declarations (interface, header files) nor the
definitions (implementation, code modules) must reside in one file.
How the sources are splitted doesn't matter. The
Ales Katona wrote:
C++ requires friend only because it lacks the idea of modularity.
Since all classes are apart they need some way to tell each other I
can use you
In pascal you simply put them into 1 unit.
That's why the C++ model is better, there exists no requirement to
implement related
Michael Van Canneyt wrote:
sorry, but I fail to see the problem ? The above makes all protected
members of a class visible. This is normal, that is why they are
protected. If you want to avoid that, make the members private. Then
they are visible only in the same unit, even for other classes
Micha Nelissen wrote:
On Sat, 19 Mar 2005 10:04:55 +0100
DrDiettrich [EMAIL PROTECTED] wrote:
In porting C++ code to Pascal I often stumbled into circular unit
references. Then the only solution is a monster unit, that implements
all the related classes at once, where the C++ implementation can
Hi Ales,
on 2005-03-18T10:57:10+01:00 Ales wrote:
C++ requires friend only because it lacks the idea of modularity.
Since all classes are apart they need some way to tell each other I
can use you
In pascal you simply put them into 1 unit.
But IMCO this is not really a good OOP-like
DrDiettrich wrote / napísal (a):
Ales Katona wrote:
C++ requires friend only because it lacks the idea of modularity.
Since all classes are apart they need some way to tell each other I
can use you
In pascal you simply put them into 1 unit.
That's why the C++ model is better, there exists
On Wed, 16 Mar 2005, DrDiettrich wrote:
Michael Van Canneyt wrote:
type TFriendClass = class(TNotMyClass);
This is a simple descendent.
Yes and no. The only purpose of this declaration is to get access to the
protected members of the class, not to extend the class in any way.
Yes. This is OK, no
Michael Van Canneyt wrote / napísal (a):
On Wed, 16 Mar 2005, DrDiettrich wrote:
Michael Van Canneyt wrote:
type TFriendClass = class(TNotMyClass);
This is a simple descendent.
Yes and no. The only purpose of this declaration is to get access to the
protected members of the class, not to
I just came about code that uses protected members of other classes,
defined in other units. In Delphi this possible by a declaration like:
type TFriendClass = class(TNotMyClass);
After this declaration the protected (and private?) members of
TNotMyClass are accessible, using TFriendClass as an
On Tue, 15 Mar 2005, DrDiettrich wrote:
I just came about code that uses protected members of other classes,
defined in other units. In Delphi this possible by a declaration like:
type TFriendClass = class(TNotMyClass);
This is a simple descendent.
After this declaration the protected (and
18 matches
Mail list logo
