Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Generic collections

  1. #1

    Generic collections

    We'll need some collection classes and algorithms which will be used everywhere in engine.
    1. implementation of at least List, Map (dictionary) and sorting
    2. work with different types, including primitive ones (non classes)
    3. high performance
    4. type safe
    5. without code duplication

    Class/interface based approaches are not comply with requirement #2 and #3.
    Pointer-based implementations conflicts with requirement #4.
    I know two remaining solutions:
    1. Generics.
    + intended to solve this problem exactly
    - not supported by Delphi 7 and FPC 2.6.2
    2. include-based template approach
    + max performance and flexibility
    + support of D7 and FPC 2.6.2
    - only one instantiation of each template per unit
    - hard to read and support template code (does not apply to code using the templates)

    I've implementation of the second approach:
    You can see what it looks like.

    We can drop support of D7 and FPC 2.6.2 and go with generics.
    What do you think guys?

  2. #2
    Unacceptable. One of the main reasons we are doing this, is because we want to support every version since D7 and all fpc. Another reason is that generics make your app increase in size every time you use another instance of the same library for another purpose. What I was thinking, is to implement some kind of double linked list or btree using pointers (maybe both), advantage we can put anything inside, it's faster than anything, small footprint.

  3. #3
    PGDCE Developer
    Join Date
    Jun 2010
    California, USA
    Personally I like generics. I find them easy to use and a perfect fit for this situation. As for for the support of D7 and FPC 2.6.2 I understand the support for D7 but FPC is free, anyone can get a newer version. This shouldn't be a factor when deciding how to implement. Just my 2 cents.

  4. #4
    pitfiend, pointer-based approach is not type safe (remember why we using Pascal?) and has poor data locality, and therefore performance.
    So we need to implement collections for each type. Good news that size increase is negligible in case of a few collections and algorithms.

    gasdeveloper, the problem with generics is compatibility between Delphi and FPC syntax. I don't know exactly which FPC version is ok for this. Generics with FPC syntax are supported from FPC 2.2.

  5. #5
    I vote for include-based template approach
    le programmeur

  6. #6
    Quote Originally Posted by Mirage View Post
    pitfiend, pointer-based approach is not type safe (remember why we using Pascal?) and has poor data locality, and therefore performance.
    So we need to implement collections for each type. Good news that size increase is negligible in case of a few collections and algorithms.
    Can't agree on that. One of the most important language features is going to be left just because we use Pascal? A well designed structure and helpers could solve any of our needs. I also think that we must build real objects and not classes, they are faster, have inheritance and also very small footprint. And yes, I am an old school developer.

  7. #7
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    UK (England, the bigger bit)
    Blog Entries
    Would it not be possible to get some polls of who is using which FPC versions and decide then? Personally, I think that if we're making a new engine for the future, it'd be a contradiction to not use some newer features for the sake of backwards compatibility. A couple years down the line, I don't think it'll be very likely we'll alienate people from the engine on account of them not being able to get their hands on a copy of delphi newer than 7 or fpc 2.6.2 (I think it was?).

    At a glance it looks like it complicates things and almost causes us to work around a feature just to provide support for what is already considered old software (delphi 7 has been around as long as I can remember) which is already pseudo-irrelevant and will only become more so as times goes on.
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  8. #8
    I'm also gainst the use of generics:
    1. As it was sad before using generics greatly increases the size of executable.
    2. Generics offer much lower performance. I maself rather go and gwite several thousands lines of code more than have mush poorer peroformance.
    3. Debuging of code that uses generics is much harder.
    4. Delphi compliler is known to sometimes simply fail in compiting generics code. This was reported long ago and still hasn't been fixed entirely.

  9. #9
    My position is against using anything that can impact negatively on performance. Using generics is a bad idea, the support on delphi is not very stable neither optimal and fpc is a mess. If we want to make an engine solid, stable and optimal we need things that provide that, also we are not building this for the casual programer and we'll try to make as much documentation as we can provide. BTW, tlist component, a critical component for nearby any kind of list is build with pointers.

  10. #10
    PGD Community Manager AthenaOfDelphi's Avatar
    Join Date
    Dec 2004
    South Wales, UK
    Blog Entries
    I've found generics to be useful and reliable in Delphi. I can't comment on performance, but I have no reason to suspect it's poor given the generic part of this is handled at compile time.

    So, how about we do what we would probably all do if we encountered this question in our day jobs... lets establish some facts. The key questions here seem to be:-

    Do generics have an adverse affect on the size of the compiled binaries?
    Are generics stable in both Delphi and FPC? - This might be tricky to prove one way or the other
    What are the differences between Delphi and FPC generics?

    Personally, I have no problem using them, but it's not just my choice, so does someone (or a collection of people) want to take on a task and get some answers? Then when we have a realistic view of the current state of affairs we can make an educated decision. This of course won't answer the question about whether we drop the idea of supporting D7 which is still very popular I believe. But, the technical side may make the decision easier... if the differences between FPC and Delphi are too great for example, regardless of the other factors, generics would be a non-starter if they are going to need lots of conditionals and such, but then depending on just how different they are we may be able to get around it by creating compiler specific versions of the classes we're talking about.

    So, plan of action... let's establish the answers to the key questions and then make a decision based on hard facts.
    :: AthenaOfDelphi :: My Blog :: My Software ::

Page 1 of 2 12 LastLast


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts