Anders Melander

I think you need to explain a little bit better what you are trying to do. Start with an example of how you would like to use your component. Once we understand that we can better help you with how to implement it.

Sorry to continue this but I simply don't get it; Your example works exactly as I would expect. You're telling the compiler to use two different implementations for IBar.Foo and IFoo.Foo. Even though interface B inherits from A and we have an object that implements both A and B, their shared methods (the ones from A) need not be the same (but they can be if you choose that). In fact COM explicitly states that it's the API that is inherited, not the implementation. Your example more or less corresponds to: type IFoo = interface ['{1E77F313-1C93-4A59-957B-751FB23EC63F}'] end; IBar = interface(IFoo) ['{49FC3BDA-7A09-4596-A80C-5EBEF73BA201}'] end; TFooBar = class(TInterfacedObject, IFoo, IBar) private FFoo: IFoo; FBar: IBar; public property Foo: IFoo read IFoo implements IFoo; property Bar: IBar read FBar implements IBar; end; That's a secondary source. I'm looking for a primary one or at least a more reputable one.

Do you have any sources for this bug in COM or can you explain what bug is? Edit: Never mind. You just did.

Thank you! This is in line with my understanding of the rules of COM. It seems that, unlike Kaster (it's a bug, it's a bug), Chuck (it's by design) actually read the books.

Why would you need a GUID if this is supposed to be "COM free"?

You are correct: type IBar = interface ['{570FBD40-8ECF-4B4B-9898-EF3F4146FFF9}'] end; IFooBar = interface(IBar) ['{F99BAE4A-6612-4714-96B4-237763239C7F}'] end; type TFooBar = class(TInterfacedObject, IFooBar) end; procedure test; begin var FooBar: IFooBar := TFooBar.Create; var Bar: IBar := FooBar; end; ...but as we already know... var FooBar: IFooBar := TFooBar.Create; Assert(Supports(FooBar, IBar)); ...will fail, so there's a bug somewhere - or at least a really bad inconsistency. Supports just does a IUnknown.QueryInterface which ends up in TObject.GetInterface. The assignment on the other hand just copies the pointer and calls _AddRef. From my understanding on what interface inheritance is in Delphi, Supports() is correct and the compiler is wrong but there are obviously different interpretations of this.

But it isn't true. The IFooBar interface inherits the methods of IBar - at compile time. The implementing object doesn't inherit the contract that it must implement the IBar interface. I'm not convinced that John Kaster knew what he was talking about when he wrote that. I mostly included the link because it seems to be the earliest mention of the feature. The limitation as-is matches my recollection of "the rules of COM" but I could be mistaken. I'm not up to reading the COM bible again just to find out. It was hard enough the first time(s).

I agree. Interface inheritance is just syntactic sugar. http://edn.embarcadero.com/article/29779 (warning this links contain references to The Version That Must Not Be Mentioned: Delphi 8)

I think I have encountered this problem on rare occasions but I can't remember the circumstances. Did you mean interface inheritance? For example the following works fine: type IFoo = interface ['{F99BAE4A-6612-4714-96B4-237763239C7F}'] end; IBar = interface ['{570FBD40-8ECF-4B4B-9898-EF3F4146FFF9}'] end; type TFoo = class(TInterfacedObject, IFoo) end; TBar = class(TFoo, IBar) end; type TFooObject = class(TComponent, IFoo) end; TBarObject = class(TFooObject, IBar) end; procedure Test; begin // Supports(interface) var FooBar := TBar.Create as IUnknown; Assert(Supports(FooBar, IFoo)); Assert(Supports(FooBar, IBar)); // Supports(instance) var FooBarObject := TBarObject.Create(nil); Assert(Supports(FooBarObject, IFoo)); Assert(Supports(FooBarObject, IBar)); end;

It sounds like you fell into the premature optimization trap; "Optimized" something because it looked inefficient without actually measuring if it would matter.

Pfft. That is up to the customer to decide. [edit: before I start a sh*t storm let me rephrase that] It should be up to the customer to decide. Not you, not Embarcadero and not Microsoft. If the customer wants to run on Windows 7, which I perfectly understand in many cases, then I will support it. They are paying for that privilege. We are here to serve their needs, not the other way around. Windows 7 has a market share around 20%. Slightly higher than OS X... Works for me. It complained to install but I haven't encountered any issues that I can pin on Windows 7.

@Kazantsev Alexey Yes now I understand. Thanks.

Yes. Like I implied. Or just use the code I used: In the OP's example it doesn't matter much but a real StrLPas would be more efficient as it would avoid the reallocation (like your example).

Okay, so do we agree that it's not equivalent to StrLPas?

Um... Aren't you responsible for initializing the record yourself if you have declared an initializer for the record?

In my example there's already room for 65 characters in the destination since Delphi strings have an implicit null terminator.

I can't tell from the documentation if SetString copies up to Length characters or always Length characters and it seems to be an intrinsic function so I can't check the source.

You need to use StrLCopy instead of StrPas since there's no guarantee that the source string is null terminated. You actually need a StrLPas function but fo some reason they've never implemented that variant. Also remember that the buffer is a static array[] of Char[0..63] so you need to iterate the outer array somehow. var Buffer: PChar; GetMem(Buffer, PaperCount*SizeOf(Char)); try var p := Buffer; for i := 0 to PaperCount-1 do begin var PaperName: string; SetLength(PaperName, 64); StrLCopy(PChar(PaperName), p, 64); PaperName := PChar(PaperName); // or SetLength(PaperName, StrLen(PChar(PaperName))) ... Inc(p, 64); end; finally FreeMem(Buffer); end;

I haven't used IB in ages but as far as I can tell you can configure it to log query execution to disk. I have no idea what kind of output it produces. What I used to do when I had problems with slow queries was to just look at their plan to see if it matched my expectations. I used Craig Stuntz' free Planalyzer for that but I don't know if it works with current version of IB. I guess all the current commercial tools have similar features. Of course examining the plan requires that you already know which queries to look at but, assuming you can reproduce the problem, you can use the performance monitor to identify those.

If your post isn't meant as trolling then you should phrase your statements in a different way. If you do not want people to respond to your post then you should post it on one-way broadcast media instead. /ignore

I don't quite agree with that. Yes, it shouldn't be your primary source of implementation bugs but presumably the additional resources the testers represent will result in more bugs found. I can't see why that's a bad thing. My experience with the Delphi betas is that at the time they start, the design is already set in stone. My experience is also that the majority of beta tester aren't really qualified to give usable feedback on design and architecture. Things may have improved though.

http://docwiki.embarcadero.com/InterBase/2020/en/InterBase_Performance_Monitor_Window

What entitles you to be the judge of that? I don't think I have ever seen David "discipline" anyone (himself included) that didn't deserve it.

That is some really bad advice. https://devblogs.microsoft.com/oldnewthing/20070219-00/?p=27963 (read all 4 articles in the series)

Show me some evidence based on measurements.