>>> But that wasn't the problem. The problem I mean is that:
>>>
>>> procedure p (out c : tc2)
>>> begin
>>>c := tc3.create;
>> This breaks already here if I assume the type definitions I used.
>
> I assumed a tc1 -> tc2 -> tc3 inheritance, sorry if I missed something here.
Yes, the type dec
Jonas Maebe :
> On 18 May 2010, at 20:06, Vinzent Höfler wrote:
>
> > Florian Klaempfl :
> >
> >> Vinzent Höfler schrieb:
> >>> Florian Klaempfl :
> >>
> >> With a function result one can easily use the as-operator.
> >
> > Yes, and then instead of doing the "undefined behaviour" thingie, it
>
Until a few moments ago i would say yes because it seems logical and fpc
raises an exception when trying to set the value programatically.
But while investigating why TAutoIncField.ReadOnly always returns false,
i found that, regardless of FReadOnly being set to true in the
constructor, this v
Jonas Maebe :
> On 18 May 2010, at 15:25, Vinzent Höfler wrote:
>
> > But that wasn't the problem. The problem I mean is that:
> >
> > procedure p (out c : tc2)
> > begin
> > c := tc3.create;
> > end;
> >
> > var
> > c1 : tc1;
> >
> > begin
> > p(c1);
> > end.
> >
> > seems not to be allowed
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> Vinzent Höfler schrieb:
>>> Florian Klaempfl :
>> With a function result one can easily use the as-operator.
>
> Yes, and then instead of doing the "undefined behaviour" thingie, it
> would cause an RTE instead. Not much of an improvement, I'd say
On 18 May 2010, at 20:06, Vinzent Höfler wrote:
> Florian Klaempfl :
>
>> Vinzent Höfler schrieb:
>>> Florian Klaempfl :
>>
>> With a function result one can easily use the as-operator.
>
> Yes, and then instead of doing the "undefined behaviour" thingie, it would
> cause an RTE instead. Not
Florian Klaempfl :
> Vinzent Höfler schrieb:
> >>
> >> was allowed and this code is simply broken, the compiler has to
> >> complain and this was fixed.
> >
> > Agreed. But in that case a function result of type tc1 wouldn't be
> > allowed to be assigned to tc3 either. So your previous statement
Florian Klaempfl :
> Vinzent Höfler schrieb:
> > Florian Klaempfl :
>
> With a function result one can easily use the as-operator.
Yes, and then instead of doing the "undefined behaviour" thingie, it would
cause an RTE instead. Not much of an improvement, I'd say.
> I thought
> such simple thin
On Monday 17 May 2010 22:22:13 Den Jean wrote:
> Hi,
>
> I am investigating why Qt on armel has problems.
>
> I think that one of the problems is
> that when c-functions are called from
> pascal that the parameters are not passed
> correctly (or not as I expected and accommodated for).
>
On Tu
On Tue, May 18, 2010 at 3:39 AM, Graeme Geldenhuys
wrote:
> Florian Klaempfl het geskryf:
>> http://en.wikipedia.org/wiki/Factory_method_pattern
>>> Sorry for the sarcasm,
>>
>> Sarcasm? For sarcasm, you need to have a clue.
>
> No need to be rude.
>
At first I thought it was rude too. But thinki
Florian Klaempfl wrote:
>
> Nobody doubts this, this is also why I wrote "normally" in my initial
> post. Nevertheless I didn't see a single valid reason yet why
> implementing the factory method pattern cannot be done using a function:
> - it is one of the basic programming principles: if a resul
Jonas Maebe schrieb:
>
> It does not apply in the case of classes. Finalisation is only inserted,
> at the caller side (hence, where the exact type is known), in case of
> reference counted types.
Actually automated types as well (variants).
___
fpc-dev
On 18 May 2010, at 15:25, Vinzent Höfler wrote:
But that wasn't the problem. The problem I mean is that:
procedure p (out c : tc2)
begin
c := tc3.create;
end;
var
c1 : tc1;
begin
p(c1);
end.
seems not to be allowed anymore.
I guess you mean tc2.create instead of tc3.create. You're cor
Vinzent Höfler schrieb:
>>
>> was allowed and this code is simply broken, the compiler has to
>> complain and this was fixed.
>
> Agreed. But in that case a function result of type tc1 wouldn't be
> allowed to be assigned to tc3 either. So your previous statement
> ("use a function instead") didn
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> Nobody doubts this, this is also why I wrote "normally" in my
>> initial post. Nevertheless I didn't see a single valid reason yet
>> why implementing the factory method pattern cannot be done using a
>> function: - it is one of the basic programmi
Vinzent Höfler het geskryf:
> types needing no finalization, so the compiler should not insert
> finalization code when classes are involved (despite of the history of
> "out" coming from reference counted COM objects or whatever).
I don't understand this finalization thing about out parameters e
On Tue, May 18, 2010 at 11:52, Florian Klaempfl wrote:
> Maybe (and really only maybe) the proper solution in this case are C++
> styled template methods.
Different languages deal with this problem in different ways:
- C++ (Java) have powerful enough template (generics) system which can
handle t
Florian Klaempfl :
> Nobody doubts this, this is also why I wrote "normally" in my initial
> post. Nevertheless I didn't see a single valid reason yet why
> implementing the factory method pattern cannot be done using a function:
> - it is one of the basic programming principles: if a result is re
Florian Klaempfl :
> Vinzent Höfler schrieb:
> > Florian Klaempfl :
> >
> >
> > You wouldn't *need* typecasts. It's a pointer and the instance it is
> > pointing to will be initialized by the subroutine you're calling. And
> > that one *knows* the size of the class it created. So there's
> > typ
Florian Klaempfl het geskryf:
>
> I see, we should change the constructor syntax for you as well ;)
I normally (90% of the time) use function return value as the instance of a
Factory Method. But as stated, there are other alternatives which might be
used to make code easier to read if errors occ
Graeme Geldenhuys schrieb:
> On 18 May 2010 10:12, Florian Klaempfl wrote:
>> - it is one of the basic programming principles: if a result is returned
>> by a subroutine, use a function
>
> The function might return a boolean (success/fail), or an error code
> etc.. The function result doesn't nee
On 18 May 2010 10:12, Florian Klaempfl wrote:
>
> - it is one of the basic programming principles: if a result is returned
> by a subroutine, use a function
The function might return a boolean (success/fail), or an error code
etc.. The function result doesn't need to return the new instance
create
Micha Nelissen schrieb:
> Florian Klaempfl wrote:
>>
>> ... and one uses normally a function and not a var/out parameter.
>
> That also would need a typecast since the function would return a parent
> class of the real class that was created, but the somehow the callee
> knows it's a descendent, s
On 05/17/2010 10:22 PM, Den Jean wrote:
> ""
>
Does the compiler digest this ?
Up till now I thought it's impossible to use any common object ABI
between Pascal and C++, so that any C function needs to be called by
Pascal using a "flattened" non-Object based interface, because the
Pascal and C+
Florian Klaempfl wrote:
... and one uses normally a function and not a var/out parameter.
That also would need a typecast since the function would return a parent
class of the real class that was created, but the somehow the callee
knows it's a descendent, so needs a cast to get to it (or us
Graeme Geldenhuys schrieb:
> Florian Klaempfl het geskryf:
>> http://en.wikipedia.org/wiki/Factory_method_pattern
>>> Sorry for the sarcasm,
>> Sarcasm? For sarcasm, you need to have a clue.
>
> No need to be rude.
>
> Maybe I can chip in, because design patterns are right up my alley. Maybe
> y
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> Vinzent Höfler schrieb:
>>> Florian Klaempfl :
>>>
Graeme Geldenhuys schrieb:
> This compiler change will play havoc on the Simple Factory
> Method
>> design
> pattern as well - a base class is used as the parameter type,
>>
27 matches
Mail list logo
