Stefan Glienke

I can't see a situation where TArray<T> can have noticable overhead as it does not have enough stuff to be generated - what you demonstrated was using a generic class that has executable code and RTTI.

Not for TArray<T> but possibly for types with actual executable code - see my reply to Mahdi. The question was about TArray<T> where it does not matter at all rather than a few unnoticable microseconds at compile time. You are right however when talking about types that have executable code (and possibly a significant amount of typeinfo) as the compiler always emits all code of a generic type into each and every dcu that is using it as in your example with Unit1 and Unit2. However it does not need to emit into Unit3.dcu because that one is just referencing the type that already fully resides in Unit2.

I think you meant to write: TItems = TArray<TItem>; Apart from not having to type the angle brackets anymore this is exactly the same type as TItems is just an alias for TArray<TItem>

Sounds more like you have some serious issue with your globals

Those languages to my knowledge don't also have something like the initialization part of a unit which might cause a chicken-egg-problem.

According to what Allen wrote in 2009 that is not true. If there is a bug with that please link to the QP entry and/or code to repro wrong behavior.

Simply, because it obviously was designed poorly and assumes that every individual installation is an atomic thing that needs the restart not allowing you to install a couple more and only then restart.

Only testing the code yourself will show but I can smell a potential memory leak due to circular references caused by anonymous methods and capturing of the IOmniTask within itself - nested anonymous methods can be a bit nasty sometimes.

Afaik the dialog used by Delphi is just what the winapi offers.

Give some more votes to https://quality.embarcadero.com/browse/RSP-16751 maybe we get it some day...

If the term pebcak is offending you must be new to the internet. I simply explained the way that always works for installing jcl/jvcl 1. The same as always - jcl\lib\d27\win32 or win64 and jcl\source\include 2. Yes, works JCL/JVCL setup issues are almost always a problem with not properly executing them or rather not having the latest jcl/jvcl sources or having some old stuff lying around. Maybe you did not update the submodule and are missing on the defines for 10.4 Also did you select both (10.4 32bit and 10.4 64bit)? And did not set the "Install selected only" checkbox?

Clearly you need to write your own WillRaise version that does not just swallow the exception but passes it on to the logger.

Clearly a pebcak. Just pulled the jcl repo, ran install.bat - it compiled the setup using 10.4 and then I installed JCL for 10.4 32bit and 64bit without a problem

I answered your question on the Spring4D forum - sometimes I have weekend or vacation - thus no immediate answer 😉

procedure Main; begin var Bob := TSmartPointer.Wrap(TTalking.Create('Bob')); Bob.Talk; Bob := TSmartPointer.Wrap(TTalking.Create('Another bob')); Bob.Talk; end; Leak because Wrap just blasts the newly created smartpointer into result not caring if its already assigned - interface results are passed as var parameter and thus contain the value that was in them before the call. I am tired fixing code that other people post on SO that I already implemented properly myself. 🙂

Matters if you have many different versions installed which can be typical for library or component developers - and every installation puts quite a bit into the path environment variable. Here is how mine looks (I have XE, 10.1, 10.2, 10.3 and 10.4 installed - and so far it's ok on Windows 10): I did not do the work yet on this Machine but on my older Win8.1 machine i had everything from Delphi 2010 to 10.3 installed and that completely blew the max length of the path variable so I substituted the common parts of the paths (such as programfiles or public documents)

Ugh - just stop it please - first there is a typo resulting in an AV as TS in TSmartPointer.Wrap needs to be of type TInjectType<T> (fwiw these types are not necessary at all as you can just call New(p) and have the correct amount of memory allocated) and second this implementation will leak if you assign TSmartPointer.Wrap<T> to anything that is not nil already.

No, actually pretty good, thank you. 🙂 It's just the experience with issues being reclassified and then "forgotten". And yes it can always be worse is also a way of optimism 😉

Too bad it will most likely rot in JIRA with the other 1900 open as "new feature" classified issues...

And some of it is unfortunately completely unnecessary and applies to every managed type! See https://quality.embarcadero.com/browse/RSP-27375

hardly - its approx 25% to 50% slower because it has to create and destroy an entire object with all bells and whistles. 🙂

@pyscripter Looks weird given how other managed types lifetimes are being handled - but since we don't have precise language and design specs as always we can just guess. Apart from that implementing smartpointer that way is wrong anyway because they break whenever there is an explicit or implicit assignment/copy going on. Proper smartpointer need a shared block that holds a reference counter. Shared<T> in Spring is implemented with several optimizations to avoid the overhead of object creation for this purpose using the all known "interface in record" approach and I challenge everyone to come up with a robust implementation using custom managed records to beat that.

That is only an issue for library authors that need to target a range of past versions which is the vast minority of Delphi users. Most migrate to a new version, start using that and never have to run their code through previous versions. Type inference for inline variables is a really nice thing - no need to explicitly decare the type just to tell the compiler (yes, if you name your variable properly the type is irrelevant for understanding the code, ask programmers from other languages that have this feature for a long time). Also often enough you have to add units to a uses clause just to declare a variable of a type that is the return of a method of some other type being used - with type inference that becomes unnecessary.

I don't understand the original problem - please describe exactly the data in a complete but small enough sample and the way you want it to be organized/shown.

As far as I know the editor control does not support ligatures