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 re
> 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 c
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 t
> 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 ? H
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 >
> fil
> > 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 reference
On Thu, 24 Mar 2005 09:02:30 +0100
DrDiettrich <[EMAIL PROTECTED]> 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'
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
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 matte
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.
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. C
header files can #include each other, and some more or less advanced
techniqu
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of DrDiettrich
> Sent: 16 March 2005 10:59
> To: FPC developers' list
> Subject: Re: [fpc-devel] "Friend" classes?
>
>
> Michael Van Canneyt wrote:
>
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 e
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
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
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 be
> split into
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 class
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
implemen
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 extend
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:
> > 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.
> > 3) What alternatives could be used, so that no
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 private
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 t
23 matches
Mail list logo
