Paul Davidson wrote on Tue, 13 Oct 2009:
OS X 10.6.1 FPC 2.2.4 Xcode 3.2 (64 bit)
Using code base that has complied correctly since 2004
Fixed $MODE OBJFPC
What exactly did you fix and how? Marco mentioned something about
duplicate mode switches, but if you want help you really have to b
OS X 10.6.1 FPC 2.2.4 Xcode 3.2 (64 bit)
Using code base that has complied correctly since 2004
Fixed $MODE OBJFPC
Current problems
1) A unit with identical first few lines as several other
successfully compiled units gives a 'Identifier not found "class"
error. Following is start of f
Florian Klaempfl wrote on Tue, 13 Oct 2009:
Feel free to create TrollPascal 1.0 :)
I guess this is a sign that it's really time to move this thread to fpc-other.
Please don't post statements like the above to fpc-pascal in the
future (and preferably not to fpc-other either, for that matter)
Feel free to create TrollPascal 1.0 :)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
When messing with pointers you've to know what to write because pointers
allow unlimited access to internal data structures.
That's not the point. It is very easy to use pointers if they behave
like this but not if they are used as if they are arrays. I need a fixed
and unambiguous syntax for
In our previous episode, Florian Klaempfl said:
> > understanding how pointers work, but a simple case of a typo which
> > couldn't be caught anymore by the compiler due to this extension.
> >
>
> What is the alternative?
Support D2009 {$pointermath on/off} that governs this, with the default as
Hi,
I try to get number of processes attached to a specific shared memory
segment.
So I read the shmctl record to retrieve this into shared memory :
type TShmid_ds = record
shm_perm: TIPC_Perm; Permissions
shm_segsz: cint; Segment size
shm_atime: time_t; Last access time
shm_dtime: time_
Florian Klaempfl wrote on Tue, 13 Oct 2009:
Jonas Maebe schrieb:
I think that "all pointers can be indexed as arrays" can easily cause
accidentantal errors though. I can't find it anymore, but I remember
Pierre once fixed a bug in the compiler sources itself where someone
accidentally used move
On Tue, 13 Oct 2009 09:42:11 +0200
Guillermo Martínez Jiménez wrote:
> If you have "p: PINTEGER" then you're assuming you're accessing to ONE
> integer.
No, YOU assume that. I assume that I am working with a memory address. If it is
a single integer or the first element of an array or the second
Jonas Maebe schrieb:
> Florian Klaempfl wrote on Tue, 13 Oct 2009:
>
>> When messing with pointers you've to know what to write because pointers
>> allow unlimited access to internal data structures. Sorry, but I can't
>> help you if you guess wrong while playing with dangerous stuff (and the
>> o
Florian Klaempfl wrote on Tue, 13 Oct 2009:
When messing with pointers you've to know what to write because pointers
allow unlimited access to internal data structures. Sorry, but I can't
help you if you guess wrong while playing with dangerous stuff (and the
original poster did so: using move i
On Tue, 13 Oct 2009 15:10:03 +0200
Jürgen Hestermann wrote:
> Pointers are great in Pascal (if the syntax wasn't influenced by C) but
> a nightmare in C.
No they are not. C/C++ has its problems, no doubt, but I would not like to code
C/C++ without them, that would be a nightmare.
As everyone sa
> From: J?rgen Hestermann
>
> (...) but Borland created these Pascal
> "extensions" and now we cannot go back (as others say) because we need
> compatibility with Delphi programs and an "easier" (which I doubt)
> convertion of C header files. So noone is willing to turn back the clock
> and remove
Jürgen Hestermann schrieb:
>
>
>> Florian Klaempfl schrieb:
Great power comes with great responsibility.
>>> Yes. Then use C or assembler. You are "responsible" for everything and
>>> you cannot expect any help from the compiler.
>> So the consequence would be to forbid pointers/@-operator/t
> Florian Klaempfl schrieb:
Great power comes with great responsibility.
Yes. Then use C or assembler. You are "responsible" for everything and
you cannot expect any help from the compiler.
So the consequence would be to forbid pointers/@-operator/type casts et.
al.
No. Only the logic has
>> Great power comes with great responsibility.
>
> Yes. Then use C or assembler. You are "responsible" for everything and
> you cannot expect any help from the compiler.
So the consequence would be to forbid pointers/@-operator/type casts et.
al. If you want pointers and all dirty stuff, use C o
About pointer arithmetic:
IMO memory is an array. So for me it is quite natural that P^ and P[0]
are the same.
You are missing the point. If you already *know* that you are dealing
with a pointer (to an array), then of course you may use this workaround
(it's nothing else, because if I want
Zitat von Florian Klaempfl :
Jürgen Hestermann schrieb:
Yes, but you cannot avoid it, if you work with dynamic arrays. You are
not even told that it's a pointer. That's just the problem.
Same for classes and strings. Classes are pointers and I'm happy that
I can write A.B instead of A^.B.
Jürgen Hestermann schrieb:
>
> Yes, but you cannot avoid it, if you work with dynamic arrays. You are
> not even told that it's a pointer. That's just the problem.
The problem is that one is playing with stuff he doesn't understand.
Explict use of pointers is always dangerous and one should reall
BTW, the expression "@DynamicArray" should really return the address of the
first element, not the address of the pointer to the array structure.
What's wrong with the current solution?
"the first element" = DynamicArray[0]
"address of the first element" -> @DynamicArray[0]
You only find this
On Mon, Oct 12, 2009 at 22:03, "Vinzent Höfler"
wrote:
> BTW, the expression "@DynamicArray" should really return the address of the
> first element, not the address of the pointer to the array structure.
What's wrong with the current solution?
"the first element" = DynamicArray[0]
"address of
BTW, the expression "@DynamicArray" should really return the address of the
first element, not the address of the pointer to the array structure. It somehow destroys
the abstraction. And I can't imagine any situation where the pointer might be of the
interest for the user of the abstraction.
> Guillermo Martínez Jiménez schrieb:
I really don't understand why Pascal "should" include C-style stuff.
PASCAL IS DIFFERENT LANGUAGE THAN C. STOP.
I fully agree with all you said but Borland created these Pascal
"extensions" and now we cannot go back (as others say) because we need
compat
Hello everybody.
My message is for both "Why use pointers to arrays?" and "Illogical
automatic deferencing".
I really don't understand why Pascal "should" include C-style stuff.
PASCAL IS DIFFERENT LANGUAGE THAN C. STOP. Actually I hate that
"C-lovers" that think all languages must use C-style st
24 matches
Mail list logo
