Rudy Velthuis

Ok, your problem was not entirely clear to me.

'C:\Libraries\Pictures' does not work for me either, but 'C:\Users\Rudy\Pictures' does. Note that a folder is not necessarily a physical directory on a physical medium, and that a display name can differ from the exact directory name as well. Libraries is such a virtual folder. It does not exist as such on disk and does not have a PItemIDList, AFAIK.

What happens if you use 'C:\Libraries\Pictures' or 'C:\Windows' as path? You need a full path and the PItemIDList for C:\ is, AFAIK, indeed nil.

My solution already worked in Delphi 4. Then, there was no SHGetPathFromIDList() yet. And the other solution was not possible at all. <g>

Thanks. Then I would have made it deprecated. Perhaps someone was careless and deprecated the wrong one. <g>

Like FPC? Not Delphi, but the closest there is.

I don't have a ready implementation right now, but Start with SHGetDesktopFolder. This returns an IShellFolder. Use IShellFolder.ParseDisplayName and see if you can get it to parse your directory. That should provide an ItemIDList. Now you can use those two to get the proper name.

If you use in, i.e. enumerators, you should not rely on any specific order, unless the enumerator is documented to have one. The only guarantee is that every element is visited, if possible (i.e. no break, no exceptions, etc.).

That's not dogfooding, that is plain (regression) testing. Yes, they should do that, most definitely, even the examples. Especially for newcomers, non-working examples give a very bad expression.

FWIW, I personally find this Emborcagear etc. stuff a little childish, just as childish as Micro$oft and similar name mutilations. The name is Embarcadero. Not so hard to write, although Borland was easier. <g> Borland and CodeGear were certainly dogfooding their stuff, at times, but certainly not all and certainly not always. I am not so sure about Embarcadero right now. Probably quite a lot of it, but certainly not everything. But even dogfooding is not a guarantee you'll find everything.

If they really wanted to keep the 32 bit Seek, they should not have overloaded it. They should have added a Seek64 method. Or they could have omitted the 64 bit Seek that takes a Word as second parameter and only have introduced the one that takes an enumeration as second parameter. There would have been no ambiguity and no need for a hack. If they had deprecated the 32 bit Seek, all would have been fine (although I am not sure if the deprecated directive already existed, at that time). And that is how you amend or improve large frameworks if backward compatbility is important. You don't resort to hacks. Of course, a Seek with a completely different signature would not have been a problem. The problem arises when the number of parameters is the same and they are assignmnet-compatible.

I don't understand. A breaking change like this (64 bit seek instead of 32 bit seek) would probably not even be noticed, or if it were, easily fixed. Most breaking changes, well, break things and thus stand out like a sore thumb. They are easy to find and easy to fix, IME.

Really? I guess many projects also stranded because of subtle bugs caused by those backward-compatibility hacks. Yes, it is hard to maintain backward compatibility, and sometimes it makes sense. But other times it doesn't. And if it is hard, the chances are big you must resort to a hack like the one under discussion. In such cases, I rather see my code break, as long as it is clear that it breaks any why. My code has broken often enough because of changes in the runtime, but usually, the alternative is not too complicated. So you take some time to fix, and, if you move your code to a new version, you'll have to test everything anyway, so that is no big deal and not much extra work.

Sherlock: why "Sad"? Breaking existing code is sometimes better than introducing such, er... "clever" (and fragile) tricks. Old code that used some FormatSettings needs an update too. They ne

Not always. Sometimes it is better to break things than to have to write code that has to parses the VMT to see if something was overridden. That is a pretty fragile piece of code. Again, I would have replaced it, not overloaded it.

I would not have done that. I would have let the code break.

If I had been them, I would simply have replaced Seek to accept a 64 bit parameter and to return a 64 bit value. I would have removed the 32 bit version. Versions only using 32 bit can still use those arguments. In other words: I would not have overloaded, just replaced.

Most of that discussion was about the topic at hand: rapid generics as compared to Delphi generics, and what I think about Delphi's generics: it can be made faster but not in a generic way.

Indeed. I wonder a bit about the 32 bit/64 bit Seek in TStream too.

Whoa! I object to the word "drivel" (or "feuchte Aussprache"). I have a properly dry speech. But you can call it "nonsense", if you like. And it is very simple: we both want to have the last word. And I doubt this can simply be cut apart into two threads. Both technically and discussionwise.

FWIW, assembler has cetain things you can only mimic in higher level code, and no optimizing compiler can provide those things, no matter how good: access tothings like flags. Adding or subtracting two arrays of (unsigned) integers using carry/borrow and a few other things can only be mimicked in C, Pascal or any other HLL. Also, assembler uses gotos like mad, and it is almost impossible to properly mimic that in HLL. I often had more problem with the PUREPASCAL portions of my BigInteger and other numeric code than with the asm. The asm was usually straightforward (but often tedious -- not something you would want to do in a noisy environment <g>) while PUREPASCAL had to mimic e.g. carry flags (In Win32, I had to divide up a 32 bit integer into 16 bit integers, using the other 16 bits of a UInt32 for overflow and carry, etc -- anything else, no matter how clever -- mimicking flags was much slower -- in Win64 I could use 64 bit integers for that). And doing this in C did not make any difference whatsoever (I have tried).

Perhaps, but that is 1. off-topic and 2. irrelevant to me. I still prefer Delphi. And I don't want to (have to) install packages to get something Delphi has standard.

Of course. ASM is not the most easy to write, and there are no safeguards whatsoever. But I didn't have many bugs, actually. I tend to plan such undertakings (and anything non-trivial is really an undertaking, in asm) before I write. I just once had to ask on S.O. for advice on how to cope with slowdowns because of partial flag stalls (something I didn't know about and which is a hardware thing in some processors).

Sure, but in the meantime, as long as teh compiler doesn't do it, I would be extremely happy about the ability to take this in my own hands, with default ctor/dtor/etc. But you can't eliminate FinalizeRecord with type info right now. These ctors/etc. would, as I wrote, also make things possible that are not possible, or can only be done rather awkwardly, now.

I have put code through godbolt quite a few times already. Yes, the generated code is not bad, but can still be improved, manually.