Ales Katona wrote:
> I think that pascal typesystem requires a bit overhaul when it comes to
> integers.
>
> First of all Integer should be size independent, that is, xy bits
> depending on the platform. All others should be specific.
I agree with an application wide integer/cardinal type, but t
Linuxer Wang wrote:
>
> Hello,
>
> Can anybody tell me how can I know which specific type an instance of
> class is?
Check the ClassType or ClassName.
> The "is" operator seems weird when interface is used.
Add a GetObject method to your interfaces, that returns the object that
implements the
> >Sometimes I added a GetUnderObject() to my interfaces to get the actual
> >object. But it's a choice up to the interface author.
> >BTW I needed it to release the object through the interface.
> >I suspect that if you shouldn't ever need to know the actual class when
> > using interfaces (maybe
On Mon, 18 Apr 2005, Andres K. Foerster wrote:
> Am Montag, dem 18. Apr 2005 schrieb Marco van de Voort:
>
> > > > > Or better rewrite it to be usable with a standard-shell.
> > > >
> > > > I prefer not, it is not worth the effort.
> > >
> > > I'm going have a look at it this week.
> > > Sha
> Am Montag, dem 18. Apr 2005 schrieb Marco van de Voort:
>
> > > Shall I send it to the list, or to whom?
> >
> > Look first what needs to be done. The result must be maintainable. (keep in
> > mind that most other devels must be able to maintain and test it)
>
> Oh, I'm surprised myself. There
> Vinzent Hoefler wrote / nap?sal (a):
> >>In a few years when 64 bits are normal, what will cardinal become?
> >>who knows..
> >>
> >>
> >
> >That's why Pascal has range types. Define the range you need, and don't
> >use "just some type" which has the range you think you will need.
> >
> And
Uberto Barbini wrote:
It does not seem right to declare var inst: TMyInterface if you
want inst to have circles and squares as values. I would expect
that you also have a class TFigure, of which TCircle and TSquare
both are descendants. These could also implement TMyInterface.
You then declare va
Am Montag, dem 18. Apr 2005 schrieb Marco van de Voort:
> > > > Or better rewrite it to be usable with a standard-shell.
> > >
> > > I prefer not, it is not worth the effort.
> >
> > I'm going have a look at it this week.
> > Shall I send it to the list, or to whom?
>
> Look first what needs t
> It does not seem right to declare var inst: TMyInterface if you
> want inst to have circles and squares as values. I would expect
> that you also have a class TFigure, of which TCircle and TSquare
> both are descendants. These could also implement TMyInterface.
>
> You then declare var inst: TF
Vinzent Hoefler wrote / napĂsal (a):
On Sunday 17 April 2005 10:45, Ales Katona wrote:
First of all Integer should be size independent, that is, xy bits
depending on the platform.
I second that.
Second, we should "force people in a friendly way" to use more
readible names like:
sint32,
On Monday 18 April 2005 10:32, Marco van de Voort wrote:
> > On Monday 18 April 2005 09:02, Marco van de Voort wrote:
> > >
> > > I typically use enums. They suffer from the same to-disk problem
> > > though, but that can be remedied using the proper directives.
> >
> > Well, I don't think I will e
> Hello,
>
>I've been working on the PPC64-port for the Linux on Power contest
> for some time now, and finally have some questions I'd like to ask for
> here:
>
> Some introduction: I am trying to use the PPC64-ELF ABI for all
> generated methods, first because of compatibility issues (I belie
Hello,
I've been working on the PPC64-port for the Linux on Power contest
for some time now, and finally have some questions I'd like to ask for here:
Some introduction: I am trying to use the PPC64-ELF ABI for all
generated methods, first because of compatibility issues (I believe it's
neede
>
> > bash is a superset of a sh shell, the .sh extension for bash scripts is
> > common, and has nothing to do with GNU. It was already that way on 4.4BSD.
>
> 4.4BSD had bash???
No. Even FreeBSD still has bash as port. However it was commonly installed.
> And why do you say, it has nothing to
> On Monday 18 April 2005 09:02, Marco van de Voort wrote:
> > > Well, and I actually do this in a major app at work. Not on
> > > everything, of course, but it can heavily simplify some stuff, for
> > > instance because I can use the Low and High-attribu^Wfunctions on
> > > the type which is safer
Hello,
first of all, please don't get me wrong. I didn't want to complain.
All in all I find FPC is really great.
I wrote this just to show how it could be further improved.
Am Montag, dem 18. Apr 2005 schrieb Marco van de Voort:
> bash is a superset of a sh shell, the .sh extension for bash
On Monday 18 April 2005 09:02, Marco van de Voort wrote:
> > > > That's why Pascal has range types. Define the range you need,
> > > > and don't use "just some type" which has the range you think
> > > > you will need.
> > >
> > > I actually tried this in a major app at work.
> >
> > Well, and I a
On Monday 18 April 2005 08:46, Jonas Maebe wrote:
> They are, but ptrint and ptruint are just regular types. The compiler
> cannot know they are properly defined in each RTL unit, and you can
> override them to be something completely different. That's why it
> gave and still gives a warning.
Yep
> > > That's why Pascal has range types. Define the range you need, and
> > > don't use "just some type" which has the range you think you will
> > > need.
> >
> > I actually tried this in a major app at work.
>
> Well, and I actually do this in a major app at work. Not on everything,
> of course
> Oh, but while we're at it: fpc1.9.6 still gives me the Hint, that this
> PtrUInt/Address-Conversion isn't portable:
>
> | WriteLn ('Runtime error ', ExitCode,
> | ' at 16#',
> | SysUtils.IntToHex (PtrUint(ErrorAddr),
> |
On 18 apr 2005, at 10:40, Vinzent Hoefler wrote:
Oh, but while we're at it: fpc1.9.6 still gives me the Hint, that this
PtrUInt/Address-Conversion isn't portable:
| WriteLn ('Runtime error ', ExitCode,
| ' at 16#',
| SysUtils.IntToHex (PtrUint(ErrorAddr),
|
On Monday 18 April 2005 07:29, Peter Vreman wrote:
> > On Sunday 17 April 2005 10:45, Ales Katona wrote:
> >> First of all Integer should be size independent, that is, xy bits
> >> depending on the platform.
> >
> > I second that.
>
> This is useless. Your code
That doesn't matter. If I'd want the
On Monday 18 April 2005 07:22, Marco van de Voort wrote:
> > On Sunday 17 April 2005 10:45, Ales Katona wrote:
> > > First of all Integer should be size independent, that is, xy bits
> > > depending on the platform.
> >
> > I second that.
>
> It is now. It just happens to be the same.
:) Ok, good
On Sun, Apr 17, 2005 at 12:01:36PM -0700, Linuxer Wang wrote:
>
> Can anybody tell me how can I know which specific type an instance of
> class is? The "is" operator seems weird when interface is used.
>
> Suppose TMyInterface is a interface, and classes TCircle and TSquar
> both implements TMyIn
Some notes.
> This is useless. Your code and runtime checks will then vary for the kind
> of processor (32 or 64bit) you are compiling for. Even 'int' in C is
> always 4 bytes.
This is not true. Most recent 64-bit machines indeed are LP64, but e.g.
several Crays are ILP64. Moreover, the C stand
> On Sunday 17 April 2005 10:45, Ales Katona wrote:
>
>> First of all Integer should be size independent, that is, xy bits
>> depending on the platform.
>
> I second that.
This is useless. Your code and runtime checks will then vary for the kind
of processor (32 or 64bit) you are compiling for. Ev
> On Sunday 17 April 2005 10:45, Ales Katona wrote:
> > First of all Integer should be size independent, that is, xy bits
> > depending on the platform.
>
> I second that.
It is now. It just happens to be the same. However keep in mind that the
strict integer=wordsize bond of the past no longer g
> I really had trouble installing FPC on FreeBSD.
Ah?
> I downloaded the big tar archive and unpacked it. Then I saw the
> file "install.sh" there. Because of the file-extension ".sh" I
> thought it was a simple shellscript for sh. So I tried to start it with
> "sh install.sh". That didn't wo
28 matches
Mail list logo