On Fri, 28 May 2010, Roger Bailey wrote:
Me:
... nextcharacter := input^ ... Does FPC not support this standard Pascal
feature?
Jonas:
No, it does not. FPC mainly supports Borland-style Pascal dialects, and they
are not ISO Standard/Extended Pascal compliant.
I can live with that, bu
On 28 Mei 2010, at 23:18, Michael Van Canneyt wrote:
> Unless Joost does it first, I'll have a look at it next week. But it will be
> under control of an option, and this option will be 'off' by default.
Of course. I agree with that. It'd be nicer if the option can be set from the
config file,
On Sat, 29 May 2010, Bee Jay wrote:
On 28 Mei 2010, at 23:18, Michael Van Canneyt wrote:
Unless Joost does it first, I'll have a look at it next week. But it will be
under control of an option, and this option will be 'off' by default.
Of course. I agree with that. It'd be nicer if the op
On 29 Mei 2010, at 15:36, Michael Van Canneyt wrote:
> The FCL FastCGI class does not have a config file.
> If you want that, you must implement that yourself.
Alright then.
> It is one of the flaws of ExtPascal's implementation: everything is tied
> together, using fixed formats for config file
On Sat, 29 May 2010 00:33:00 +0200
José Mejuto wrote:
> s> But the object layer brings the biggest issue with the implicit
> s> "self" causing names external to a method to clash with local
> s> names.
>
> Hmmm... I think that this should not happend. Is the case in your
> posted example ?
I
On Sat, 29 May 2010 01:09:50 +0300
Alberto Narduzzi wrote:
> Hi,
>
> > Struct is declared as "class" so it inherits from TObject if not other
> > class is especified.
>
> is that true? I don't mean not to trust you, but is the compiler
> assuming that, or is it a FPC rule? IMO a class is a cla
On Sat, 29 May 2010, Bee Jay wrote:
On 29 Mei 2010, at 15:36, Michael Van Canneyt wrote:
The FCL FastCGI class does not have a config file.
If you want that, you must implement that yourself.
Alright then.
It is one of the flaws of ExtPascal's implementation: everything is tied
together,
On Sat, 29 May 2010, spir ☣ wrote:
On Sat, 29 May 2010 01:09:50 +0300
Alberto Narduzzi wrote:
Hi,
Struct is declared as "class" so it inherits from TObject if not other
class is especified.
is that true? I don't mean not to trust you, but is the compiler
assuming that, or is it a FPC ru
On 27/05/10 23:13, Jonas Maebe wrote:
On 27 May 2010, at 23:31, Yann Bat wrote:
The compiler always adds a VMT if an object has a constructor or destructor.
The reason is that the VMT also contains the instance size, which is used by
the constructor helper to allocate the required amount
On Sat, May 29, 2010 12:56, Frank Peelo wrote:
> On 27/05/10 23:13, Jonas Maebe wrote:
>> On 27 May 2010, at 23:31, Yann Bat wrote:
>>
>>
The compiler always adds a VMT if an object has a constructor or
destructor. The reason is that the VMT also contains the instance
size, which is
On 29 Mei 2010, at 16:52, Michael Van Canneyt wrote:
> Yes, but he chooses a very restrictive approach. As it is, you must
> convince him to change something. With the modular component approach, you
> don't need to wait.
Why should I have to wait? I got the source code, all of them. If I need s
On 29 May 2010, at 13:22, Tomas Hajny wrote:
> I believe the same is the case with FPC and _objects_ (not classes) and
> FPC is thus compatible here. The text above (mentioning constructors
> allocating the memory) probably refers to classes. In case of objects,
> constructor does not need to all
On 29 May 2010, at 12:56, Frank Peelo wrote:
> On 27/05/10 23:13, Jonas Maebe wrote:
>> On 27 May 2010, at 23:31, Yann Bat wrote:
>>
The compiler always adds a VMT if an object has a constructor or
destructor. The reason is that the VMT also contains the instance size,
which i
Hello,
Say I store class instances of various types in a TFPList. All happen to be
descendants of same superclass C and each one has a specific method "text".
When retrieving and writing an element, if they were all direct instances of C,
I would do something like:
element := C(list[index])
On Sat, 29 May 2010, spir ☣ wrote:
Hello,
Say I store class instances of various types in a TFPList. All happen to be descendants
of same superclass C and each one has a specific method "text". When retrieving
and writing an element, if they were all direct instances of C, I would do someth
On 29 May 2010, at 18:11, Michael Van Canneyt wrote:
> It depends on what you want to achieve. If you make it a static method, then
> the compiler will emit a warning "function Text hides method of parent
> class" (or something like it)
>
> If you make it virtual, then you must explicitly add "
On Sat, 29 May 2010, Jonas Maebe wrote:
On 29 May 2010, at 18:11, Michael Van Canneyt wrote:
It depends on what you want to achieve. If you make it a static method, then
the compiler will emit a warning "function Text hides method of parent
class" (or something like it)
If you make it virt
> element := C(list[index]); // casting back
> text := element.text;
> I cannot do that, even if elements all are *indirect* instances of C, because
> this calls C.text instead of the element's own proper text method.
If you use virtual methods then C.text should call the descendant's me
On Sat, 29 May 2010 10:46:45 -0700
David Emerson wrote:
> > element := C(list[index]); // casting back
> > text := element.text;
> > I cannot do that, even if elements all are *indirect* instances of C,
> > because
> > this calls C.text instead of the element's own proper text method.
On Sat 29 May 2010, spir ☣ wrote:
> I cannot do that. C0 (and all classes) instances need a text method. I also
> cannot have 2 methods (one static, one virtual) with different names.
So make a virtual method called text. Don't use a static method at all.
In my example I was trying to demonstrat
On 29 May 10, at 15:26 , spir ☣ wrote:
> I cannot do that. C0 (and all classes) instances need a text method. I also
> cannot have 2 methods (one static, one virtual) with different names. It's a
> basic feature, always called with the same name. Like getItem for a hierarchy
> of collections: ev
21 matches
Mail list logo
