Hi Anthony > The more that I think about it, the more I am believe that using my approach > is probably the best solution. Hear me out please. > > First, it would be fairly easy to implement copy on write logic with a custom > record class. > > Second, because it's Pascal code, it's entirely possible to fully customize > how it operates now and into the future, without the need to modify the > compiler. Suppose later you decide that also want the ability allocate the > storage memory of using the same array interface, but with a vertex buffer > object as the mechanism for allocating storage. Maybe at a later time you > want to allow an arrays type to back a memory mapped file. > > In all cases, user code would be the proper avenue to implement these > features. Unless these is some special feature unique to an intrinsic type > that makes working with a user code type significantly more difficult, why > bother adding more complexity to the compiler and more complexity rigidly > into the built in types? > > Now that we have management operators, type helpers, generics, > implicit/explicit conversions, and operator overloading, why not use what we > already have and make it better? Can you, or anyone for that matter, find a > real problem with a type or other construct that user code solution can solve > trivially with approximately the same syntax? If so then yes I am all for > addling to the language and compiler. In all other cases when can use what > the nice compiler and language developers have created for us and do everyone > a favor by reporting and helping to fix the bugs those features might still > have.
Yes. I am all for custom/user implementation in case it can be used everywhere together/interchangeably with native dynamic arrays. However FPC typing does not seem to cope with that (currently?). 1. e.g. primitive types (integers, floats) and records still need different handling in your TAlignedArray: A[0]^:=0; A.Item[0]:=0; vs A[0].X:=0; Standard arrays support A[0]:=0 and A[0].X:=0 via their compiler magic. 2. TAlignedArray memory layout can't be made compatible with dynamic arrays. Thus no existing functions accepting dynamic arrays would work with TAlignedArray and vice versa. And that's a huge deal as it just greatly increases fragmentation and messes with code re-use between libraries. Imho, Pascal is too good to follow into C/C++ custom arrays hell. 3. Does not support standard way of dealing with array like @A[0], High(A), Low(A), Length(A), etc. Think about generic functions accepting both standard dynamic array and your custom array/vector. Another minor issue is that your TAlignedArray is semantically more like Rust's Vec. It lacks public SetLength, but has Push/Pop/Clear. Thus it behaves differently to FPC array. -- Regards, Denis Golovan _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
