I filed a bugreport: https://bugs.freepascal.org/view.php?id=38309
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Mon, Jan 4, 2021 at 11:00 PM Bart wrote:
> So, most likely this has nothing to do with generics?
> I'm using r47193 of fpc trunk
Try to compile attached program for Win64-bit with either 3.2.0 or trunk:
Free Pascal Compiler version 3.2.0 [2020/06/04] for x86_64
Copyright (c) 1993-2020 by Flo
On Mon, Jan 4, 2021 at 5:13 PM Bart wrote:
>
> > What is strange to me is that the compilation issue does not happen with
> > the LazControls package alone, but only when ExCtrls package is added.
> > Moreover, the problem occurs only on 64bit, not on 32 bit. (I am on Windows)
64-bit Windows:
Com
On Mon, Jan 4, 2021 at 12:57 PM Werner Pamler via fpc-devel
wrote:
> What is strange to me is that the compilation issue does not happen with
> the LazControls package alone, but only when ExCtrls package is added.
> Moreover, the problem occurs only on 64bit, not on 32 bit. (I am on Windows)
Cu
Am 25.10.2016 08:07 schrieb "Martok" :
> Before submitting this to the bugtracker, 3 questions: does this look
sane in
> general?
I'll try to take a look at it this weekend. But at work we're currently
rather busy (shortly before a new release of our main software), so no
promises though... (As I'
2016-07-30 18:40 GMT+02:00 Sven Barth :
> please check the changes I've made (they're mentioned both in the commit
> as well as the issue).
>
> merged into github repo
> Maybe you should add an "experimental" modifier to these types so that one
> knows that they're unstable.
>
I've made that lon
Am 30.07.2016 18:10 schrieb "Maciej Izak" :
>
> Impossible! :O *Finally*! Thanks Sven! Totally unexpected event. ;)
Expect the unexpected :P
> I'd like to use Generics.Collections in stable release ASAP but... IMO
best version for release is 3.2 (even 3.0.4 is probably to early). I need
to review
Impossible! :O *Finally*! Thanks Sven! Totally unexpected event. ;)
I'd like to use Generics.Collections in stable release ASAP but... IMO best
version for release is 3.2 (even 3.0.4 is probably to early). I need to
review latest changes in trunk for generics to correct library (package?)
code, be
Am 08.05.2015 23:56 schrieb "Martin Frb" :
>
> What are the scoping rules?
>
> Example:
>
> TLazStorageMemBase = object
> private
> const
> CNT_OFFS = SizeOf(Pointer);
> DATA_OFFS = CNT_OFFS + (2 * SizeOf(Integer));
> private
> FMem: PByte;
> function GetCapacity: Integer;
Ahh, thanks Sven! I'll see if I can post a bug report soon of it.. I'll
use the work-around for now. :)
On 2015-02-19 12:22 AM, Sven Barth wrote:
On 18.02.2015 20:51, Den wrote:
Hi there,
Currently this code:
TSomeObject = Class;
TSomeOtherObject = Class(TSomeObject );
And finally:
On 18.02.2015 20:51, Den wrote:
Hi there,
Currently this code:
TSomeObject = Class;
TSomeOtherObject = Class(TSomeObject );
And finally:
TMyObject = Class;
TSomeOtherOtherObject = Class(TSomeOtherObject );
Comes up with error 'got "T" expected "TObject"' .. But TMyObject is
based
Okay Sven I'll be using the bug tracker with the "generics" to assist in
the best way I can. I just added an issue for the problem I mentioned which
I believe was previously an undocumented issue.
Issue #22019
http://bugs.freepascal.org/view.php?id=22019
___
On 11.05.2012 22:58, Anthony Walter wrote:
Thanks Sven. Overall generics in Fpc are very much improved. So good
work! Your work is much appreciated!
I also experienced some different problems with classes which implement
generic interfaces where the compiler thinks that method aren't implement.
Thanks Sven. Overall generics in Fpc are very much improved. So good
work! Your work is much appreciated!
I also experienced some different problems with classes which implement
generic interfaces where the compiler thinks that method aren't implement.
On my blog I have a page where I describe mu
On 11.05.2012 20:10, Anthony Walter wrote:
Okay with the latest trunk version I tried compiling my generic classes.
It seems there is a problem with fpc generics in that you cannot use a
generic as a type parameter. e.g type TDictionary =
class(TEnumerable>) ...
Yes, this is a known problem and
Okay with the latest trunk version I tried compiling my generic classes. It
seems there is a problem with fpc generics in that you cannot use a generic
as a type parameter. e.g type TDictionary =
class(TEnumerable>) ...
Given:
type
TCollection = class
end;
TPair = class
Key: K;
Val
The example problem I listed seems to be fixed in trunk. I'll write a few
more examples. Thank you FPC development team!
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Okay, i'll try getting trunk sources from svn and building. I'll reporting
back shortly.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
It will compile correctly with the trunk version.
Generics support has been greatly improved in the trunk version; you may
want to give it a try.
On May 12, at 00:11, Anthony Walter wrote:
> Generics still have a lot of problems. I know they've been in the works
> for years but they still fail
First, thanks for the detailed answer!
This information may be useful for others, so I put it into the wiki:
http://wiki.freepascal.org/Generics#Technical_details.
Maybe there is a better place for that...
A.v.P.
___
fpc-devel maillist - fpc-devel@li
On 19.11.2011 09:33, AvP wrote:
Simply replacing "object" by "class" is not sufficient, because classes
need to be used differently than objects.
Right, it actually needs a bit of modification in the destructor. ;-)
I haven't yet tried to replicate your example with classes, so I can't
say wh
First of all, thanks for your answer.
I tried to make the example as simple as possible - and simply forgot to
allocate the memory :$
> Simply replacing "object" by "class" is not sufficient, because classes
> need to be used differently than objects.
Right, it actually needs a bit of modificatio
On 18.11.2011 21:12, Sven Barth wrote:
Please note: While this is how it SHOULD work this does currently not
work with any version of the compiler except maybe my generic branch (I
haven't tested that yet).
Ok, I have tested that with my branch and it doesn't work there either.
After thinking
On 18.11.2011 18:31, AvP wrote:
1. Is this behavior intended (generic objects)?
I didn't find anything like that in the docs
It's at least not forbidden. I can imagine though that it was forgotten
to document as objects aren't used by that many persons (and thus they
are forgotten rather
Am 30.08.2011 03:06, schrieb Anthony Walter:
Tonight I tried to "make all" from your branch and wasn't able to build.
This is a the output I got:
http://pastebin.com/GQh5XA2w
I am guessing your build requires a working version of your fpc binary
to build itself.
The errors you see are already
Sven,
Tonight I tried to "make all" from your branch and wasn't able to build.
This is a the output I got:
http://pastebin.com/GQh5XA2w
I am guessing your build requires a working version of your fpc binary to
build itself.
Also, I wrote a few of pretty clean test cases in Delphi 2010 Today whe
Wow, Sven, thanks for the reply, and most definitely thanks for working
on FPC. Anything I can do to help I'll do. Last week I sent patches to
fix issues with Lazarus CodeTools and the new generic syntax which
basically caused a lot of problems in the IDE.
I'll be on freenode irc in both #fpc and
On Mon, Aug 29, 2011 at 11:19 AM, Sven Barth wrote:
> Hi!
>
> As Paul and Jonas already told you, I'm currently working on improving the
> compilers generic implementation. As you have noticed it currently doesn't
> support generic methods and constraints at all. Also the generic
> implementation
Hi!
As Paul and Jonas already told you, I'm currently working on improving
the compilers generic implementation. As you have noticed it currently
doesn't support generic methods and constraints at all. Also the generic
implementation in mode Delphi isn't working correctly as you've noticed.
I
On 29 Aug 2011, at 16:50, Anthony Walter wrote:
Btw, where would be a good place to follow your progress on
JVm support?
Here :) And also the svn commit log of http://svn.freepascal.org/svn/fpc/branches/jvmbackend
, as well as http://wiki.freepascal.org/FPC_JVM and its subpages
(probably e
Thanks Jonas. Btw, where would be a good place to follow your progress on
JVm support?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 29 Aug 2011, at 16:23, Anthony Walter wrote:
Paul, thanks for the reply. Did you mean to say that the generics are
actually being improved ... that is that someday you might be able
to say:
procedure TMyNonGenericClass.MyGenericMethod(List: TList);
Or that the random seeming bugs with t
Oh, and FPC generics really need the ability to add constraints ...
e.g. type TObjectList = class TList ... end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Mon, Aug 29, 2011 at 10:15 AM, Paul Ishenin wrote:
> Yes. These are known problems and you would found even more a year ago.
> Sven Barth now trying to fix exising problems and implement missing things.
>
> If you wish to try fix them yourself you need to study how parser part of
> the compile
29.08.2011 21:52, Anthony Walter wrote:
Jump to "So here are some of the problems I've found with fpc
generics" if you don't want to read the backstory.
...
And if someone ever does intent to fix generics in FPC, there are a
whole slew of errors that they already bring into the compiler. I'll
Am 23.11.2010 20:18, schrieb Aleksa Todorovic:
> Hi!
>
> I've attached several patches regarding generics some time ago
> (http://bugs.freepascal.org/view.php?id=15875,
> http://bugs.freepascal.org/view.php?id=11777), but there was no
> response regarding them. Is anyone from fpc developers workin
Am 29.09.2010 09:06, schrieb Sven Barth:
Am 29.09.2010 00:54, schrieb Willibald Krenn:
Hi!
I'm having this issue, too, but with 2.4.3.
The following example code fails with FPC 2.4.2 RC1 as well (system is
i386-win32):
Tried that with trunk and it compiled fine. (FPC 2.5 on win64)
I also
Am 29.09.2010 00:54, schrieb Willibald Krenn:
Hi!
I'm having this issue, too, but with 2.4.3.
The following example code fails with FPC 2.4.2 RC1 as well (system is
i386-win32):
Tried that with trunk and it compiled fine. (FPC 2.5 on win64)
I also tested with a 2.5.1 version from August (
Hi!
I'm having this issue, too, but with 2.4.3.
The following example code fails with FPC 2.4.2 RC1 as well (system is
i386-win32):
Tried that with trunk and it compiled fine. (FPC 2.5 on win64)
Cheers,
Willi
___
fpc-devel maillist - fpc-devel@
Am 27.09.2010 14:21, schrieb Sven Barth:
I'm having this issue, too, but with 2.4.3.
The following example code fails with FPC 2.4.2 RC1 as well (system is
i386-win32):
program generictest;
{$mode objfpc}{$H+}
uses
fgl;
type
TTest = specialize TFPGList;
begin
end.
2.4.0
Am 22.09.2010 15:59, schrieb Felipe Monteiro de Carvalho:
Hello,
Has anyone experienced issues with generics? I have the following code:
unit cdescreen;
{$mode delphi}
interface
uses
// LCL, RTL, FCL
Classes, SysUtils, Controls, Graphics, LCLType, SDFData, fpimage,
fgl,
//
cde
On 21 Oct 2009, at 19:08, David B Copeland wrote:
On Wed, 2009-10-21 at 15:54 +0200, Jonas Maebe wrote:
Generics still don't work 100%,
In what way is Generics not 100%?
There are problems with using inheritance, e.g. http://bugs.freepascal.org/view.php?id=12249
and http://svn.freepascal
On Thu, Oct 22, 2009 at 04:08, David B Copeland
wrote:
> In what way is Generics not 100%?
>
> Dave Copeland.
For me at least, the gravest problem is a lack of function-level generics.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.
On Wed, 2009-10-21 at 15:54 +0200, Jonas Maebe wrote:
> On 21 Oct 2009, at 14:55, Marco van de Voort wrote:
>
> Generics still don't work 100%,
>
>
> Jonas
>
In what way is Generics not 100%?
Dave Copeland.
___
fpc-devel maillist - fpc-devel@
On Jan 17, 2008 9:01 PM, Peter Vreman <[EMAIL PROTECTED]> wrote:
> See the fgl unit in current 2.2.1 or 2.3.1. Generics were not stable
> enough in the past to have the unit already enabled in 2.2.0.
Oh, thanks. In my search I had actually found this unit, but then I
looked at the unit name and sa
At 20:56 17-1-2008, you wrote:
Hi Felipe,
I have never gotten onto the band wagon regarding Generics. I have
only seen the word being tossed around on the mailing lists and
newsgroups. Do you maybe have a nice link explaining Generics, what
benefits it has over TList (TObjectList and friends) a
At 20:40 17-1-2008, you wrote:
Hello,
I was coding and I suddently saw that need to use a typed list. I went
with TFPList, but considering we already have compiler support I
thougth that maybe we could have a basic library with useful classes
using generics. I searched on fpc 2.2.0 sources a lot
Hi Felipe,
I have never gotten onto the band wagon regarding Generics. I have
only seen the word being tossed around on the mailing lists and
newsgroups. Do you maybe have a nice link explaining Generics, what
benefits it has over TList (TObjectList and friends) and what I would
use it for? I ga
Florian Klaempfl wrote:
Mattias Gaertner schrieb:
For example, this is currently not allowed:
generic TTree = class(TObject)
type public TTreeNode = specialize TNode;
end;
And this neither:
generic TTree = class(TObject)
type public
TTreeNode = class
Data: T;
end;
Mattias Gaertner wrote:
For example, this is currently not allowed:
generic TTree = class(TObject)
type public
TTreeNode = specialize TNode;
end;
Shouldn't this be allowed?
Perhaps it can only work with a complete TTreeNode description, probably
the TNode is specific for use by T
On Fri, 17 Aug 2007 10:20:13 +0200 (CEST)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>[...]
> > > > > What local types are/will be allowed?
> > > > >
> > > > > For example, this is currently not allowed:
> > > > >
> > > > > generic TTree = class(TObject)
> > > > > type public TTreeNode =
On Fri, 17 Aug 2007, Florian Klaempfl wrote:
> Michael Van Canneyt schrieb:
> >
> > On Fri, 17 Aug 2007, Florian Klaempfl wrote:
> >
> > > Mattias Gaertner schrieb:
> > > > On Thu, 16 Aug 2007 23:31:25 +0200 (CEST)
> > > > Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > [...]
Michael Van Canneyt schrieb:
On Fri, 17 Aug 2007, Florian Klaempfl wrote:
Mattias Gaertner schrieb:
On Thu, 16 Aug 2007 23:31:25 +0200 (CEST)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
[...]
Why is the local variable block needed?
It is not. I asked the same question. It was added for
On Fri, 17 Aug 2007, Florian Klaempfl wrote:
> Mattias Gaertner schrieb:
> > On Thu, 16 Aug 2007 23:31:25 +0200 (CEST)
> > Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> >
> > > [...]
> > > > Why is the local variable block needed?
> > > It is not. I asked the same question. It was added for
Mattias Gaertner schrieb:
On Thu, 16 Aug 2007 23:31:25 +0200 (CEST)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
[...]
Why is the local variable block needed?
It is not. I asked the same question. It was added for symmetry
reasons: if a local type block is allowed, then a var block should
a
On Thu, 16 Aug 2007 23:31:25 +0200 (CEST)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>[...]
> > Why is the local variable block needed?
>
> It is not. I asked the same question. It was added for symmetry
> reasons: if a local type block is allowed, then a var block should
> also be allowed.
>
On Thu, 16 Aug 2007, Mattias Gaertner wrote:
> On Thu, 16 Aug 2007 14:59:47 -0500 (CDT)
> Jesus Reyes <[EMAIL PROTECTED]> wrote:
>
> >
> > --- Jesus Reyes <[EMAIL PROTECTED]> escribió:
> >
> > >
> > > --- Michael Van Canneyt <[EMAIL PROTECTED]> escribió:
> > >
> > > >
> > > >
> > > > On T
On Thu, 16 Aug 2007 14:59:47 -0500 (CDT)
Jesus Reyes <[EMAIL PROTECTED]> wrote:
>
> --- Jesus Reyes <[EMAIL PROTECTED]> escribió:
>
> >
> > --- Michael Van Canneyt <[EMAIL PROTECTED]> escribió:
> >
> > >
> > >
> > > On Thu, 16 Aug 2007, Mattias Gaertner wrote:
> > >
> > > >
> > > > What is
On Thu, 16 Aug 2007, Jesus Reyes wrote:
>
> --- Michael Van Canneyt <[EMAIL PROTECTED]> escribió:
>
> >
> >
> > On Thu, 16 Aug 2007, Mattias Gaertner wrote:
> >
> > >
> > > What is the state and future plans of generics?
> > > I only found the wiki page
> > >
> > > http://wiki.lazarus.fre
--- Jesus Reyes <[EMAIL PROTECTED]> escribió:
>
> --- Michael Van Canneyt <[EMAIL PROTECTED]> escribió:
>
> >
> >
> > On Thu, 16 Aug 2007, Mattias Gaertner wrote:
> >
> > >
> > > What is the state and future plans of generics?
> > > I only found the wiki page
> > >
> > > http://wiki.lazaru
--- Michael Van Canneyt <[EMAIL PROTECTED]> escribió:
>
>
> On Thu, 16 Aug 2007, Mattias Gaertner wrote:
>
> >
> > What is the state and future plans of generics?
> > I only found the wiki page
> >
> > http://wiki.lazarus.freepascal.org/Generics
> >
> > which does not even mention the curre
On Thu, 16 Aug 2007, Mattias Gaertner wrote:
>
> What is the state and future plans of generics?
> I only found the wiki page
>
> http://wiki.lazarus.freepascal.org/Generics
>
> which does not even mention the current syntax.
The current syntax is descibed in the docs, reference manual.
Ther
Michael Schnell schreef:
No. Generics are more like using a macro when defining a type.
So a ":=" copies the memory and not a pointer and they are passed by
value into a procedure.
I think you cut too much context. To which question does this give an
answer?
(Don't you see the link to t
Michael Schnell schreef:
No. Generics are more like using a macro when defining a type.
So a ":=" copies the memory and not a pointer and they are passed by
value into a procedure.
I think you cut too much context. To which question does this give an answer?
Vincent
__
No. Generics are more like using a macro when defining a type.
So a ":=" copies the memory and not a pointer and they are passed by
value into a procedure.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
Op Wed, 20 Dec 2006, schreef Marco van de Voort:
> > Op Wed, 20 Dec 2006, schreef Marco van de Voort:
> > > > > In other word the type is not parameterized by another type but by an
> > > > > integer
> > > > > used to define the upper limit of an array.
> > > >
> > > > Basically, isn't this si
> Op Wed, 20 Dec 2006, schreef Marco van de Voort:
> > > > In other word the type is not parameterized by another type but by an
> > > > integer
> > > > used to define the upper limit of an array.
> > >
> > > Basically, isn't this similar to a schema type like you have in Extended
> > > Pascal?
>
Op Wed, 20 Dec 2006, schreef Marco van de Voort:
> > Op Wed, 20 Dec 2006, schreef Vincent Snijders:
> >
> > >
> > > In other word the type is not parameterized by another type but by an
> > > integer
> > > used to define the upper limit of an array.
> >
> > Basically, isn't this similar to a
> Op Wed, 20 Dec 2006, schreef Vincent Snijders:
>
> >
> > In other word the type is not parameterized by another type but by an
> > integer
> > used to define the upper limit of an array.
>
> Basically, isn't this similar to a schema type like you have in Extended
> Pascal?
Aren't those autom
Op Wed, 20 Dec 2006, schreef Vincent Snijders:
> Daniël Mantione schreef:
> >
> > Op Wed, 20 Dec 2006, schreef Vincent Snijders:
> >
> > > Will fpc support generic record declarations like this:
> > >
> > > type
> > > generic TFixedKeyNode = record
> > > key: array[0..KeySize-1] of char;
> >
Will fpc support generic record declarations like this:
type
generic TFixedKeyNode = record
key: array[0..KeySize-1] of char;
value: dword;
end;
In other word the type is not parameterized by another type but by an
integer used to define the upper limit of an array.
Free Pascal
Daniël Mantione schreef:
Op Wed, 20 Dec 2006, schreef Vincent Snijders:
Will fpc support generic record declarations like this:
type
generic TFixedKeyNode = record
key: array[0..KeySize-1] of char;
value: dword;
end;
In other word the type is not parameterized by another type but by an int
Op Wed, 20 Dec 2006, schreef Vincent Snijders:
> Will fpc support generic record declarations like this:
>
> type
> generic TFixedKeyNode = record
> key: array[0..KeySize-1] of char;
> value: dword;
> end;
>
> In other word the type is not parameterized by another type but by an integer
> us
Marc Weustink wrote:
Flávio Etrusco wrote:
On 4/12/06, Bisma Jayadi <[EMAIL PROTECTED]> wrote:
It isn't clear to me what the current status about Generics is:
http://www.freepascal.org/wiki/index.php/Generics
http://www.dummzeuch.de/delphi/object_pascal_templates/english.html
http://commu
Op Thu, 13 Apr 2006, schreef Marc Weustink:
> > Ingenious! I really feel stupid for not thinking of something that
> > simple like this before :-)
>
> Is it possible this way to "derive" 2 (or more) classes in one unit from the
> same generic ?
The matrix unit does it. It uses FPC's preprocess
Flávio Etrusco wrote:
On 4/12/06, Bisma Jayadi <[EMAIL PROTECTED]> wrote:
It isn't clear to me what the current status about Generics is:
http://www.freepascal.org/wiki/index.php/Generics
http://www.dummzeuch.de/delphi/object_pascal_templates/english.html
http://community.borland.com/article
On 13 apr 2006, at 00:29, Flávio Etrusco wrote:
http://www.dummzeuch.de/delphi/object_pascal_templates/english.html
http://community.borland.com/article/0,1410,27603,00.html
Ingenious! I really feel stupid for not thinking of something that
simple like this before :-)
Something similar is
It isn't clear to me what the current status about Generics is:
http://www.freepascal.org/wiki/index.php/Generics
http://www.dummzeuch.de/delphi/object_pascal_templates/english.html
http://community.borland.com/article/0,1410,27603,00.html
Ingenious! I really feel stupid for not thinking of s
On 4/12/06, Bisma Jayadi <[EMAIL PROTECTED]> wrote:
> > It isn't clear to me what the current status about Generics is:
> > http://www.freepascal.org/wiki/index.php/Generics
>
> http://www.dummzeuch.de/delphi/object_pascal_templates/english.html
>
> http://community.borland.com/article/0,1410,27603
On Wed, 12 Apr 2006 08:31:58 +0200 (CEST)
"Peter Vreman" <[EMAIL PROTECTED]> wrote:
> FPC is a compiled language where not all types are classes. The only way
> to implement it is like C++ templates. It is a known fact that generics
> will introduce code bloat, but that is still less than the 15-2
It isn't clear to me what the current status about Generics is:
http://www.freepascal.org/wiki/index.php/Generics
http://www.dummzeuch.de/delphi/object_pascal_templates/english.html
http://community.borland.com/article/0,1410,27603,00.html
-Bee-
has Bee.ography at
http://beeography.wordpress.
Hi,
Am Dienstag, den 11.04.2006, 18:56 -0300 schrieb Flávio Etrusco:
> On 4/11/06, Danny Milosavljevic <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Am Montag, den 10.04.2006, 23:33 -0300 schrieb Flávio Etrusco:
> > > On 4/10/06, Danny Milosavljevic <[EMAIL PROTECTED]> wrote:
> > > > Hi,
> > > >
> >
> On 4/11/06, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>>
>> > Templates' pros:
>> > - support of primitive types;
>> > - flexibility (ability to call non-virtual and non-related methods,
>> > operators, etc);
>> > - ability of coding for speed.
>> >
>> > Type erasure generics' pros:
>> > - No
On 4/11/06, Danny Milosavljevic <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Am Montag, den 10.04.2006, 23:33 -0300 schrieb Flávio Etrusco:
> > On 4/10/06, Danny Milosavljevic <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > (...)
> > > > but thing is I can't see much use for generics for low level
> > > > t
Hi,
Am Montag, den 10.04.2006, 23:33 -0300 schrieb Flávio Etrusco:
> On 4/10/06, Danny Milosavljevic <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> (...)
> > > but thing is I can't see much use for generics for low level
> > > tasks.
> >
> > You need them for any kind of compile-time-type-checked collec
On 4/11/06, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>
> > Templates' pros:
> > - support of primitive types;
> > - flexibility (ability to call non-virtual and non-related methods,
> > operators, etc);
> > - ability of coding for speed.
> >
> > Type erasure generics' pros:
> > - No additional
On Tue, 11 Apr 2006 13:06:27 -0300
"Flávio Etrusco" <[EMAIL PROTECTED]> wrote:
> > What does type erasure mean without a runtime engine (VM) ?
>
> That the "template" is not aware of the instantiated type of the
> template parameters, they are only accessed/resolved through oop
> (inheritance/pol
On 4/11/06, Micha Nelissen <[EMAIL PROTECTED]> wrote:
> On Mon, 10 Apr 2006 23:33:12 -0300
> "Flávio Etrusco" <[EMAIL PROTECTED]> wrote:
>
> > Type erasure generics' pros:
>
> What does type erasure mean without a runtime engine (VM) ?
>
That the "template" is not aware of the instantiated type of
On Mon, 10 Apr 2006 23:33:12 -0300
"Flávio Etrusco" <[EMAIL PROTECTED]> wrote:
> Type erasure generics' pros:
What does type erasure mean without a runtime engine (VM) ?
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freep
> Templates' pros:
> - support of primitive types;
> - flexibility (ability to call non-virtual and non-related methods,
> operators, etc);
> - ability of coding for speed.
>
> Type erasure generics' pros:
> - No additional generated code, no code bloat;
> - Code is easier to understand (no addi
On 4/10/06, Danny Milosavljevic <[EMAIL PROTECTED]> wrote:
> Hi,
>
(...)
> > but thing is I can't see much use for generics for low level
> > tasks.
>
> You need them for any kind of compile-time-type-checked collections...
> so as long as you only do I/O port programming, you are safe... no wait,
Hi,
Am Sonntag, den 09.04.2006, 18:51 -0300 schrieb Flávio Etrusco:
> I hope I'm not being too annoying, I'm just trying to understand
> better your decision/opinion. If you think this discussion is useless
> please speak and I'll shut up ;-)
>
> > Well, talking about Java's speed never makes sen
> > > What compiler? If gcc, gcc does nothing fast, and C++ header model than
> > > the
> > > bit of codegenerating done.
> >
> > nothing fast ..., _the problem is more_ ... C++ header model
>
> VisualC++ 6.
> I know it's much related to C header model and linking, but I never
> saw any "comp
On 4/9/06, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> > > I guess I was a bit too hasty on the whining, but just thinking about
> > > C++ compilation speed
> >
> > What compiler? If gcc, gcc does nothing fast, and C++ header model than the
> > bit of codegenerating done.
>
> nothing fast ...,
I hope I'm not being too annoying, I'm just trying to understand
better your decision/opinion. If you think this discussion is useless
please speak and I'll shut up ;-)
> Well, talking about Java's speed never makes sense.
LOL, I agree :-)
> Fact is, if you use
> classes that you've always an in
> > I guess I was a bit too hasty on the whining, but just thinking about
> > C++ compilation speed
>
> What compiler? If gcc, gcc does nothing fast, and C++ header model than the
> bit of codegenerating done.
nothing fast ..., _the problem is more_ ... C++ header model
__
Flávio Etrusco wrote:
> On 4/9/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>> Flávio Etrusco wrote:
>>> On 4/9/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
(...)
Is there already a specification how they will look like in Delphi?
> (.net2)? Wh
> > > What? Do you mean that FPC implementation of generics wouldn't be
> > > based on "type erasure" but on beefed-up-precompiler-macros? Please
> > > say I got it all wrong :-o
> >
> > You want crippled generics regarding speed and usage like C# has? You
> > can do this with "real" templates as w
On 4/9/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> Flávio Etrusco wrote:
> > On 4/9/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> >> [EMAIL PROTECTED] wrote:
> >> (...)
> >> Is there already a specification how they will look like in Delphi?
> >>
> >>> (.net2)? What's planned? Can somebod
> On 4/9/06, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> > > What? Do you mean that FPC implementation of generics wouldn't be
> > > based on "type erasure" but on beefed-up-precompiler-macros? Please
> > > say I got it all wrong :-o
> >
> > Do you have documents about "type erasure" in native
1 - 100 of 136 matches
Mail list logo
