20.01.2010 0:29, JoshyFun:
Pointers and safe code is mutually exclusive, like managed code and
I use pointers quite a lot. The code then works 24/7 for months under
some continuous load. (Still, I'd be even happier if compiler/RTL
double-checked my code additionally.)
fast execution, garbage
20.01.2010 0:22, Marco van de Voort:
Totally different issue. The problem is that there was no implementation
of memavail that would suit the usage of memavail in old dos code.
That was the simple difference between single- and multiprocessing, which
was ingrained in the use. Even the simple sh
In our previous episode, Nikolai Zhubr said:
> 19.01.2010 23:18, Marco van de Voort:
> > FPC is not going to forbid standard pointer use, since it breaks a lot of
> > code.
> Of course. I think it all was about new features for new code.
> By the way, it reminds me MemAvail (though not exactly the
19.01.2010 23:18, Marco van de Voort:
FPC is not going to forbid standard pointer use, since it breaks a lot of
code.
Of course. I think it all was about new features for new code.
By the way, it reminds me MemAvail (though not exactly the same). Lots
of code used to use it, however AFAIK it is
In our previous episode, Nikolai Zhubr said:
> >p: pchar;
> > begin
> >GetMem(p,10);
> >inc(p,random(30));
>
> Yes, this is among things which should probably be immediately
> disallowed at compile-time (as long as one wants reasonably safe
> pointers) because they are hard (or expen
19.01.2010 17:49, JoshyFun пишет:
var
p: pchar;
begin
GetMem(p,10);
inc(p,random(30));
Yes, this is among things which should probably be immediately
disallowed at compile-time (as long as one wants reasonably safe
pointers) because they are hard (or expensive) to validate later.
I
19.01.2010 16:16, Thaddy:
Nikolai Zhubr wrote:
I'd guess this would require huge work and substantial modifications
to the language though.
The compiler then has to assert all possible codepaths... Do you think
that's a viable option?
I don't have that much expertise to judge really, but I'd
Nikolai Zhubr wrote:
I'd guess this would require huge work and substantial modifications
to the language though.
The compiler then has to assert all possible codepaths... Do you think
that's a viable option?
___
fpc-devel maillist - fpc-devel@lists
19.01.2010 12:31, Jonas Maebe:
Does FPC know how to find this places on compile time and at least
issue a
warning about it ?
No, it doesn't. In principle, the compiler can't even be sure that you
haven't replaced the default memory manager with e.g. some
garbage-collector-style memory manager s
On 19 Jan 2010, at 09:35, ik wrote:
There are sometimes way to "see" that you have memory leak in a code
without
using any sort of profiler.
For example using new/getmem on a local variable without releasing
it etc...
Does FPC know how to find this places on compile time and at least
is
http://ik.homelinux.org/
On Tue, Jan 19, 2010 at 10:59, Marco van de Voort wrote:
> In our previous episode, ik said:
> > There are sometimes way to "see" that you have memory leak in a code
> without
> > using any sort of profiler.
> > For example using new/getmem on a local variable without r
In our previous episode, ik said:
> There are sometimes way to "see" that you have memory leak in a code without
> using any sort of profiler.
> For example using new/getmem on a local variable without releasing it etc...
>
> Does FPC know how to find this places on compile time and at least issue
12 matches
Mail list logo
