On 10/01/19 20:23, Martok wrote:
Something I just found out, while changing some old code: why does that not
work?
var
u: UnicodeString = nil;
// Incompatible types: got "Pointer" expected "UnicodeString"
a: AnsiString = nil;
// Illegal Expression
c: TCharArray = '';
Am 29.12.2018 um 22:35 schrieb Jonas Maebe:
> You don't need to typecast dynamic arrays to pointer to initialise them
> with nil. Simply "arr:=nil;" works. Ideally, the compiler would remove
> this extra initialisation if you add it before it got a different value,
> but it does not yet do that.
On 02/01/19 17:05, Benito van der Zander wrote:
1) Dynamic arrays are initialised with nil, but that is an
implementation detail (required by the fact that they are reference
counted: if they would contain random data, that would cause crashes)
If there ever is a fpc version that does not ini
On 02/01/19 18:31, Martok wrote:
Am 02.01.2019 um 17:23 schrieb Sven Barth via fpc-pascal:
Even in Delphi situations can occur where a dynamic array Result variable is
non-Nil already upon entry and then SetLength will simply manipulate that
preexisting array instead of working on a new array. I
Am 02.01.2019 um 17:23 schrieb Sven Barth via fpc-pascal:
> Even in Delphi situations can occur where a dynamic array Result variable is
> non-Nil already upon entry and then SetLength will simply manipulate that
> preexisting array instead of working on a new array. In most cases that
> probably
On 29/12/2018 22:35, Jonas Maebe wrote:
1) Dynamic arrays are initialised with nil, but that is an
implementation detail (required by the fact that they are reference
counted: if they would contain random data, that would cause crashes)
Is it?
Because according to https://www.freepascal.org
Am Mi., 2. Jan. 2019, 17:05 hat Benito van der Zander
geschrieben:
> The non-initialization of 'Result' has bitten me more than once in Delphi.
>
>
> Me, too. Usually the solution was to add a call to SetLength.
>
> That makes the bullshit hints especially bad.
>
Even in Delphi situations can oc
Hi,
The current FPC trunk issues only a hint for the SetLength().
Then it is a bullshit hint ("bullshint")
1) Dynamic arrays are initialised with nil, but that is an
implementation detail (required by the fact that they are reference
counted: if they would contain random data, that
> On Jan 1, 2019, at 5:15 AM, Michael Van Canneyt
> wrote:
>
> One can discuss whether the 'variables are uninitialized' rule must be
> abandoned,
> and declare that the compiler should initialize all variables with known
> values, but that is another discussion.
I was going to say. Hasn’t
On Tue, 1 Jan 2019, Martok wrote:
I'm curious to see them, because all 'issues' reported here can be perfectly
repeated (possibly with some modifications) in Delphi.
The non-initialization of 'Result' has bitten me more than once in Delphi.
Aye. But it's rather rare in Delphi and very common
Op 2019-01-01 om 01:55 schreef Martok:
The non-initialization of 'Result' has bitten me more than once in Delphi.
Aye. But it's rather rare in Delphi and very common in FPC, so not everyone
might have encountered it (that's how I'm justifying to myself putting it on the
Portability List inst
First, I agree clearing dynarrays with :=nil is somewhat cleaner than
Setlength(0). (Small issue: I only learned that this is even a thing from the
compiler implementation of it when I was debugging #0031215! From the reactions
of other Delphi developers I showed it to, it is _very_ uncommon.) Init
Happy new year, everyone!
Am 31.12.2018 um 10:22 schrieb Michael Van Canneyt:
> Cultural note:
> For native english speakers the above may be somewhat farfetched: But in Dutch
> and French, spelling and grammar are not ruled by custom, but are strictly
> managed
> by official language committee
On Mon, 31 Dec 2018, Martok wrote:
1) Dynamic arrays are initialised with nil, but that is an
implementation detail
Is it, though? Global variables and instance fields are zero-filled, local
variables as if the local variable block was a record passed to Initialize()
(so, recursively zeroing
On 2018-12-31 02:54, Martok wrote:
There is a hint for such parameters even though the compiler knows
they
always contain a valid value, because valid in the sense of "won't
crash
the program" is not the same as "this is what the programmer
intended".
Are you baiting me, or was that accidenta
> There is a hint for such parameters even though the compiler knows they
> always contain a valid value, because valid in the sense of "won't crash
> the program" is not the same as "this is what the programmer intended".
Are you baiting me, or was that accidental? ;-)
> 1) Dynamic arrays are
On Sat, 29 Dec 2018, Jonas Maebe wrote:
On 2018-12-29 22:00, Derek Edson wrote:
Would it not be simpler to have the compiler initialize all dynamic
array variables to nil, like for string variables, which should prevent
the uninitialized warning/hint without requiring special treatment for
On 2018-12-29 22:00, Derek Edson wrote:
Would it not be simpler to have the compiler initialize all dynamic
array variables to nil, like for string variables, which should prevent
the uninitialized warning/hint without requiring special treatment for
handling the SetLength function.
It does
Surely the point of a hint/warning is to point out a potential issue that
the programmer may wish to correct.
It should therefore be possible to change your code such a way that the
hint/warning can be resolved so that it is no longer printed. This should
not entail redundant or unnecessary code.
On 29.12.2018 16:19, Benito van der Zander wrote:
Hi,
even if there's closed issue https://bugs.freepascal.org/view.php?id=34169 I
would like to ask if it can be reconsidered.
The subject is that SetLength now gives warning: Variable "dynamic array" of a managed type does not seem to be
init
Hi,
even if there's closed issue
https://bugs.freepascal.org/view.php?id=34169 I would like to ask if
it can be reconsidered.
The subject is that SetLength now gives warning: Variable "dynamic
array" of a managed type does not seem to be initialized
in 3.3.1 and 3.1.1 while it doesn't give
On 2014-07-27 13:28, Andreas Berger wrote:
I have noticed quit often here that instead of answering the question
people try to reason why in the world the author of the question would
even want to do this.
I agree that this is an annoying pattern on this list.
I would suggest everyone at least
Am 2014-07-27 19:28, schrieb Andreas Berger:
I have noticed quit often here that instead of answering the question people try to
reason why in the world the author of the question would even want to do this. Would it
not be better to tell him how to do it or at the most say "I don't know". I
I very seldom comment on this, or any, forum unless I have a good answer
and no one else seem to have one. This case is different. I have noticed
quit often here that instead of answering the question people try to
reason why in the world the author of the question would even want to do
this. W
Am 2014-07-27 12:51, schrieb Steve Gatenby:
I would find code in the form of
ArrayLen := IncLength(ArrayName, 1);
to be much more readable then
SetLength(ArrayName, Length(ArrayName)+1);
ArrayLen:= High(ArrayName);
Why? It is not clear which index ArrayLen will receive from IncLength.
Thanks for that - I will give it a try :)
On 27/07/14 21:21, leledumbo wrote:
It is only a personal preference, not a serious problem.
I would find code in the form of
ArrayLen := IncLength(ArrayName, 1);
to be much more readable then
SetLength(ArrayName, Length(ArrayName)+1);
> It is only a personal preference, not a serious problem.
>
> I would find code in the form of
>ArrayLen := IncLength(ArrayName, 1);
>
> to be much more readable then
>
> SetLength(ArrayName, Length(ArrayName)+1);
> ArrayLen:= High(ArrayName);
>
> I was just hoping somebody ma
It is only a personal preference, not a serious problem.
I would find code in the form of
ArrayLen := IncLength(ArrayName, 1);
to be much more readable then
SetLength(ArrayName, Length(ArrayName)+1);
ArrayLen:= High(ArrayName);
I was just hoping somebody may know how its done.
Thanks
Am 2014-07-27 12:10, schrieb Steve Gatenby:
> Could anybody enlighten me on how to make the 'SetLength' procedure into an
equivalent function
> I have many instances of
> SetLength(xxx, Length(xxx)+1);
> Num := High(xxx);
What is the problem with this code?
Why force these 2 commands into
On 04 Dec 2009, at 17:03, Flávio Etrusco wrote:
On Fri, Dec 4, 2009 at 12:32 PM, Jonas Maebe > wrote:
On 04 Dec 2009, at 14:57, Carsten Bager wrote:
I have 2 lines of code
1 I allocate memory
2 I read from the screen (Nano-X) and save it in the "BitMapArray".
Can I do this or can I not be s
On 04 Dec 2009, at 14:57, Carsten Bager wrote:
I have 2 lines of code
1 I allocate memory
2 I read from the screen (Nano-X) and save it in the "BitMapArray".
Can I do this or can I not be sure that the memory is in one block.
I have no idea whether that is guaranteed. It is currently impleme
31 matches
Mail list logo
