On 26 Apr 2010, at 03:27, David Emerson wrote:
It would be nice if move would give a compiler warning or note if it
receives a
pointer-pointer. I guess that would require move doing type-
checking... but at
compile-time, is there anything wrong with move doing such a type-
check and
issuing
Dear FreePascal,
I have some questions when I am using Free Pascal
>> firstly , I find that I Can't use hot-key "Ctrl+N" to add
a new line in the IDE.
and I think the Free Pascal's ide is not very stable,
I am using fpc under a MS-DOS 7.1, sometimes when I am editing
my sourse code
On 26/04/2010 8:23 AM, Joseph Montanez wrote:
I would suggest you checkout the latest copy of the documentation
SubVersion repository:
http://svn.freepascal.org/svn/fpcdocs/trunk
Then submit code examples for the various units.
Are you seriously want everyone that wants to help out b
Florian Klaempfl wrote:
> If you mess with move and have no clue about internals, then you get
> burned. Period. Proper dyn. array code uses copy(...) instead of move.
I wish there was a type-checked equivalent to what move does. copy creates a
new
array, and I don't want to do that: I already h
All the talk about the Pascal parser in fcl-passrc got me interested
recently. I did some experiments, and I thought I mention here:
1. I added a simplest example how to use fcl-passrc to the wiki:
http://wiki.freepascal.org/fcl-passrc
2. And reported a couple of bugs found in fpdoc (tested on P
> I don't see a benefit in having fragmented documentation over various
> websites and locations. This makes it near impossible for a end-user to find
> help.
The language itself is even worst, this is the biggest pitfall of
Pascal in general. I can't tell you how hard it is to find anything on
On 25 April 2010 21:48, Joseph Montanez wrote:
> Since there hasn't been a clear response on this I've started my own
> website, to start documenting more of the use of each library.
The class documentation generated by fpdoc has support for examples.
FPC's policy is to only publish documentation
Okay,
Since there hasn't been a clear response on this I've started my own
website, to start documenting more of the use of each library. However
doing so I am finding some clear issues, and that is some of these
units are not finished all the way. Is there some list of missing
functionality somew
Hello FPC-Pascal,
Sunday, April 25, 2010, 6:29:26 PM, you wrote:
>> I think there is a great difference between normal arrays and dynamic ones
JH> Yes, but it should not be like that. If you first declare a
JH> static array and then decide to make it a dynamic array then *no*
JH> code change shou
Jürgen Hestermann schrieb:
>>> Then it should be possible to use "MyArray" as a parameter for
>>> move/fillchar but obviously this is not the case.
>> No. Because it does not mean the *array's data* but the *array*.
>
> So it doesn't mean anything? What exactly is the *array* if not it's data?
A
On 25 Apr 2010, at 19:32, Jürgen Hestermann wrote:
>>> There is a lot of ambigouity with dynamic arrays.
>> There certainly is if you expect them to work like regular arrays. They are
>> a quite different datatype.
>
> At least it should always mean the same independent from context.
It does a
Then it should be possible to use "MyArray" as a parameter for
move/fillchar but obviously this is not the case.
No. Because it does not mean the *array's data* but the *array*.
So it doesn't mean anything? What exactly is the *array* if not it's data?
___
But currently move *does* handle dynamic arrays differently than other
procedures.
It handles it exactly the same as any other function/procedure that takes a
untyped/formal "var" parameter. Formal var parameters always take on the
address of whatever you pass.
That's not true!
Well, it is.
Jürgen Hestermann schrieb:
>>> True. As I said: There is no common logic what the identifier "MyArray"
>>> means if it is a dynamic array (but there is for static arrays).
>> It means the whole array (which is an opaque type). No more no less.
>
> Then it should be possible to use "MyArray" as a p
True. As I said: There is no common logic what the identifier "MyArray"
means if it is a dynamic array (but there is for static arrays).
It means the whole array (which is an opaque type). No more no less.
Then it should be possible to use "MyArray" as a parameter for move/fillchar
but obvious
On 25 Apr 2010, at 18:24, Jürgen Hestermann wrote:
>>> But currently move *does* handle dynamic arrays differently than other
>>> procedures.
>> It handles it exactly the same as any other function/procedure that takes a
>> untyped/formal "var" parameter. Formal var parameters always take on th
Jürgen Hestermann schrieb:
>
>
>>> But currently move *does* handle dynamic arrays differently than
>>> other procedures.
>> It handles it exactly the same as any other function/procedure that
>> takes a untyped/formal "var" parameter. Formal var parameters always
>> take on the address of whatev
I think there is a great difference between normal arrays and dynamic ones
Yes, but it should not be like that. If you first declare a static array and
then decide to make it a dynamic array then *no* code change should be
required. But now it is for move and fillchar.
is OK, but in dynamic
But currently move *does* handle dynamic arrays differently than other
procedures.
It handles it exactly the same as any other function/procedure that takes a
untyped/formal "var" parameter. Formal var parameters always take on the
address of whatever you pass.
That's not true! There is a
On 25 Apr 2010, at 17:38, Jürgen Hestermann wrote:
>>> It would be possible to allow this syntax :
>>> move(data ...
>>> in addition to the current :
>>> move(data[0] ...
>>> There is no fundamental reason why it wouldn't be possible.
>> There is: there is no reason why move should be handled
Hello FPC-Pascal,
Sunday, April 25, 2010, 5:38:48 PM, you wrote:
JH> But currently move *does* handle dynamic arrays differently
JH> than other procedures. You can use an array as parameter for a
JH> function or procedure and it does not matter whether it's dynamic
JH> or not. So the identifier m
Simply because dereferencing a dyn. arrays makes no sense because
it is more than just a simply data collection.
Realy? What else is happening in the background?
Reference counting (also of the stored data), automatic length storage.
But that has nothing to do with the fact that the identifier
It would be possible to allow this syntax :
move(data ...
in addition to the current :
move(data[0] ...
There is no fundamental reason why it wouldn't be possible.
There is: there is no reason why move should be handled differently than other
procedures.
But currently move *does* handle d
Juha Manninen schrieb:
>> This is plainly wrong. When indexing a dyn. array, the compiler
>> generates the correct code to access the data, no more no less.
>
> It would be possible to allow this syntax :
> move(data ...
> in addition to the current :
> move(data[0] ...
>
> There is no fundam
> This is plainly wrong. When indexing a dyn. array, the compiler
> generates the correct code to access the data, no more no less.
It would be possible to allow this syntax :
move(data ...
in addition to the current :
move(data[0] ...
There is no fundamental reason why it wouldn't be possibl
Jürgen Hestermann schrieb:
>> Florian Klaempfl schrieb:
>> Simply because dereferencing a dyn. arrays makes no sense because
>> it is more than just a simply data collection.
>
> Realy? What else is happening in the background?
Reference counting (also of the stored data), automatic length storag
Florian Klaempfl schrieb:
Simply because dereferencing a dyn. arrays makes no sense because
it is more than just a simply data collection.
Realy? What else is happening in the background?
This is plainly wrong. When indexing a dyn. array, the compiler
generates the correct code to access the
Jürgen Hestermann schrieb:
>> David Emerson schrieb:
>> I *am* checking sizes before the move, which is why it surprised me
>> that things were going out of bounds -- the trouble is I forgot the
>> array index [0]
>
> Yes, that happens quite often. Unfortunately, Borland gave up the clear
> und pr
David Emerson schrieb:
I *am* checking sizes before the move, which is why it surprised me that things
were going out of bounds -- the trouble is I forgot the array index [0]
Yes, that happens quite often. Unfortunately, Borland gave up the clear und
predictable context independend Pascal synt
29 matches
Mail list logo
