To clarify a bit...
Peter Popov wrote:
A
C++ class CANNOT have a virtual destructor (the VMT is killed when you
call delete, before the class' destructor is called).
Nope. Virtual destructors exist in C++, moreover good practice is to make
destructor virtual if any other method is virtual
mic arrays,
autmatic destructoe calling at the end of scope, etc. Or even automatic
memory management.
In one lang you'd have to write:
for i:=1 to len(arr) do begin
if arr[i] = 0 then
break
end;
And in anther:
i := find(arr, 0);
And in yet another:
i := arr.Find(0);
Verbosity of
ecessarily complex or something else was
wrong. It just doesn't correlate with the praxis.
Probably Pascal examples are poor (it was already signaled on this list).
But don't forget that Ada is more verbose but is also somewhat more
expressive (compare the typesystems fo
design) is bad (and
that's true at least to java 1.4)
rgds
--
Sebastian Kaliszewski
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Vinzent Hoefler wrote:
On Thursday 02 June 2005 13:54, Sebastian Kaliszewski wrote:
No, they aren't (or let me put it this way: It depends on what you
measure). For instance, studies indicate that there are ten times more
errors code in C code then in Ada code once you've del
27;s also further away from standard Pascal.
Is it worth something?
rgds
--
Sebastian Kaliszewski
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
greaytest impact on Objective
Pascal productioveness would come from allowing programmers to declare
classes like self managing (self freeing, not needeing explicit destructions).
rgds
--
Sebastian Kaliszewski
___
fpc-devel maillist - fpc-d
short (10 cycles is very little) periods of time -- btw even L2 cache hits
take longer (out of PC processors only PentiumM has 10 cycle L2 latency,
others are worse.
> have it happen too
> often, and that's enough to make the difference between smooth and
> sluggish.
You d
and will require partial or total freezes while they
> happen.
compacting GC allocation is rather more cache friendly than non GC one.
Compacting Collection is not cache friendly though.
>
> Eric
rgds
--
Sebastian Kaliszewski
___
fpc-devel m
indefinite, and this would break exiting code (hence it's unacceptable).
rgds
--
Sebastian Kaliszewski
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
ou didn't touch any.
PS. there exists real-time capable GC (i.e. good for (soft)real time
applications, such thing can't be said about even most non GC memory
allocation systems).
rgds
--
Sebastian Kaliszewski
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
11 matches
Mail list logo
