Jump to content
Edwin Yip

Oz-SGL, a new generic collections library based on the idea of C++ STL

Recommended Posts

On 10/11/2020 at 2:21 AM, Stefan Glienke said:
6 hours ago, Stefan Glienke said:

So instead of adressing those statements you bring up some completely irrelevant and wrong things about my library? Well... I am all for criticism if you find issues in its design or implementation but that was just a low blow. ūüėČ

 

I'm sorry, I was wrong in this case.

SgList doesn't really support managed types.


The implementation of this collection was one of the very first.
I actually used it for data that does not contain managed types.

 

It will be necessary to fix this shortfall and do it in about the same way as in other collections, in which this problem should not be.

You will need to look into the code of each collection again and provide test support for the managed types.

Share this post


Link to post

Sorry, I didn't expect the flame war, but was only sharing interesting and useful stuff, and expected to gain insightful comments from senior programmers (and we received some) :)

Share this post


Link to post
Guest
12 minutes ago, Edwin Yip said:

Sorry

Don't be, nothing bad is going in here, on contrary it is civilized discussion, we all benefiting from this, any library been discussed will only get better, and we all getting better at spotting the problems in code, with more important point, we are getting better in the way we can spot problems then evaluate them.

Share this post


Link to post
10 hours ago, Attila Kovacs said:

looks like "TsgList<T> = record" should be "TsgList<T: record> = record"

Records can be managed types

  • Like 1

Share this post


Link to post

Collections as records seems to me a good idea. I've thinked about creation of such a library for a long time.

 

However, my goals was to achieve as light solution as possible. For example, every TList instance currently - are several heap memory blocks. Two objects and a block of memory for items. Every object in Delphi have implicit try/except in its constructor, and so on.... So, Tlist is quite more complicated compare to native dynamic arrays (which seems to me much more optimal).

 

Also, I think value sematics of record types should be supported. So, when A and B are collections, user can assign one to another, like A := B. And here something like copy-on-write should be provided. For this either: Delphi 10.4 managed records feature can be used, or, collection types should have single interface field (IInterface or similar), and all requited additional data fields (like Count, Capacity, ect. fields) should be incapsulated into it. This complicate things to some degree.

 

Also, this way (with a single interface field inside) collections, implemented as record types, wil be able to auto-initialize and auto-free itself, which will simplify user's code.

 

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

√ó