Hi
Would there be a chance to implement "Static" or something that did
the same trick, in the compiler. Now I write my constants in an
assembler file. That´s acceptable, but it is not a very elegant way to
do it.
Regards Carsten
> > Carsten Bager wrote:
> >
> > > Hi
> > > I am programming to an
> Would there be a chance to implement "Static" or something that did
> the same trick, in the compiler. Now I write my constants in an
> assembler file. That?s acceptable, but it is not a very elegant way to
> do it.
It's not the keyword that is the problem. The whole logic for this would
have
> It's not the keyword that is the problem. The whole logic for this would
> have to be implemented. Think switches, commands to the linker, a way to
> configure the name for the segment etc. Part of this is specific for your
> device setup.
>
> If writable const is off, also variables declared w
Carsten Bager wrote:
>> It's not the keyword that is the problem. The whole logic for this would
>> have to be implemented. Think switches, commands to the linker, a way
>> to
>> configure the name for the segment etc. Part of this is specific for
>> your
>> device setup.
>>
>> If writable const i
Hello:
Just ask if there is any ppcaltivec unit for freepascal,
like mmx. If not i'll may convert the c ones from gcc so i can use
the freevec lib under pascal.
And a related question, does compiler understand inline ppc asm?
TIA
--
Hi,
On 2006.01.18, Eduardo wrote:
> Just ask if there is any ppcaltivec unit for freepascal,
> like mmx. If not i'll may convert the c ones from gcc so i can use
> the freevec lib under pascal.
PPC compiler doesn't yet supports Altivec at all. But it's on the
todo list. Any help is welc
Hi, it´s me, the guy with this internal error recently, while porting
OpenXML to FP. Meanwhile, the compiler switch -B did help me out.
Apparently by compiling all units, regardless wether they have been changed
or not, this internal error is avoided. Now I believe this B stands for
Back to hel
On 18 Jan 2006, at 21:21, Wolfram Kläger wrote:
Conclusion: never call any parameter of any procedure or function
exactly like any property of any class and its ancestors. So far I
thought, parameter names of functions and procedures are always
local, i.e. valid for this function or proced
> Conclusion: never call any parameter of any procedure or function exactly
> like any property of any class and its ancestors. So far I thought,
> parameter names of functions and procedures are always local, i.e. valid
> for this function or procedure block only. Is this a bug or feature of FPC
On Wed, 18 Jan 2006 13:39:21 -0700
L505 <[EMAIL PROTECTED]> wrote:
> > Conclusion: never call any parameter of any procedure or function exactly
> > like any property of any class and its ancestors. So far I thought,
> > parameter names of functions and procedures are always local, i.e. valid
> >
>> It's not the keyword that is the problem. The whole logic for this would
>> have to be implemented. Think switches, commands to the linker, a way
>> to
>> configure the name for the segment etc. Part of this is specific for
>> your
>> device setup.
>>
>> If writable const is off, also variables
Jonas 18.01.06 21:30:58:
> ... This error should not be reported if you switch to Delphi mode.
Unfortunately no. This kind of errors ís reported by FPC, no matter which mode,
while Delphi does not.
I understand your explanation, but don´t really understand that an
anyproc.anyparam.name can
> Prefixing an 'A' seems to be an (un)official delphi naming convention
Does this make it official?
http://www.econos.de/delphi/cs.html#ObjectPascal_Procedures_Parameters
" The 'A' prefix is a convention to disambiguate when the parameter name
is the same as a property or field name in the cla
>> Prefixing an 'A' seems to be an (un)official delphi naming convention
> Does this make it official?
> http://www.econos.de/delphi/cs.html#ObjectPascal_Procedures_Parameters
>
> " The 'A' prefix is a convention to disambiguate when the parameter name
> is the same as a property or field name
Is it possible the Apple/Mac line feed could be causing your name to be rammed
into
the text below :-)
No big deal, I just wondered from an academic perspective, whether the line
feed on
the Mac would cause this issue on a PC, or whether it was for other reasons.
Lars
-
L505 18.01.06 21:33:48:
> ... use the underscore, although a bit messy looking:
>
> function SubstringData(const Offset, Count_: Integer): WideString; virtual;
> ...
Thanks. Matches to the habit of the guy, who has written the Delphi code, that
I am working on. He usually begins each private
> > ... use the underscore, although a bit messy looking:
> >
> > function SubstringData(const Offset, Count_: Integer): WideString;
> > virtual;
> > ...
>
> Thanks. Matches to the habit of the guy, who has written
> the Delphi code, that I am working on. He usually begins
> each private class i
17 matches
Mail list logo
