David Heffernan

All this speculation..... A minimal example and the answer would be simple. 

3 hours ago, Mahdi Safsafi said:

I wish if you were right ... but things are much much more complex than that. E.g : sometimes there is an official mechanism but you choose message instead because you don't want the official mechanism to perform a paint for example ... there is a lot of those examples.

I also talked about such examples. This isn't one of them. 

3 hours ago, Mahdi Safsafi said:

I didn't take any dependency (please read my example again) !

You said, "I'd understand if the logic was implemented in RecreateWnd but that's not the case here". You literally talk about making a choice based on the implementation details.

I still can't see why you are set against calling RecreateWnd. That seems perverse to me. 

3 hours ago, Mahdi Safsafi said:

FYI, there is no concept of private/protected for messages. Messages are public !

Not so. For sure the language doesn't stop you using any message you like. But that doesn't mean that it is reasonable to do so. Oftentimes messages are used in the private implementation detail for a class.  As a broad principle, you should not be looking to work with Windows messages when consuming VCL controls.  Sometimes one is forced into it because the control provides no official mechanism.  But when we do that, it is brittle, and subject to future implementation detail changes.

3 hours ago, Mahdi Safsafi said:

I'd understand if the logic was implemented in RecreateWnd but that's not the case here !

And there it is.  There's the point where you take a dependency on on implementation details.

The implementation of RecreateWnd is:

procedure TWinControl.RecreateWnd;
begin
  if WindowHandle <> 0 then Perform(CM_RECREATEWND, 0, 0);
end;

There is a difference between this code and yours. Your code does something unconditionally. But RecreateWnd does nothing if the window handle has not already been created.

I'm quite sure that you've got this wrong.  I mean, it won't have any material impact on things, but one may as well do things the right way.

6 hours ago, Mahdi Safsafi said:

For Main form that's not necessary. RecreateWnd is useful when creating dynamic controls as you don't know when there would be the handle available.

This doesn't make sense to me. I don't see the argument for sending a private implementation specific message rather than calling the RecreateWnd method. 

Dude, just make a minimal example and debug that. Post it here if you want. Really good discipline to learn how to make that minimal example. 

Cut this code down to the minimum that leaks. Then debug that. 

Try finslly still wrong. You must acquire the resource immediately before the try

Foo := TMyObject.Create;

try

  Foo.Use;

finally 

  Foo.Free;

end;

As you have it, if an exception is raised before the variable is assigned, you'll call Free on an uninitialized variable. 

Not the cause of the leak, but each of those calls to TSomeObject.Create needs to be protected in a try/finally

Free is implemented as if Assigned(Foo) then Foo.Destroy; so those if statements in the previous post are pointless. Call Free unconditionally. 

1 hour ago, Edwin Yip said:

How about not to port it to Delphi, but  instead, just wrap it as dynamic linking library for the Delphi program to use?

Even harder than porting to delphi. 

17 minutes ago, Mahdi Safsafi said:

He wrote "@stk.Peek" and I understood that he wanted the address of the peeked value. 

No. It's clear. He wants the address of the record stored internally by the class to avoid a copy. 

19 minutes ago, Mahdi Safsafi said:

use @stk.List[xxx]

What value of xxx is to be used? 

12 minutes ago, Mahdi Safsafi said:

@Dave Novo As David pointed out,  you may need to use @stk.List[xxx].

"may" is rather weak. A more detailed clarification may be useful to the asker, to make it clear that the code you offered does not prevent a copy, and in fact just adds obfuscation. 

However, it's also possible that there is premature optimisation going on here. 

Surely that's just going to copy the record to a temp local, and return the address of that temp local. Or am I missing something? 

8 minutes ago, Mike Torrettinni said:

This happens to me quite often, start with new feature and after a while I see the different naming would be more suitable. So, now changing an alias will be so much easier, because refactoring/rename of type doesn't always work across multiple units.

Then you end up with different names for the same thing. How can that be better? 

Refactoring tools get these names changed very reliably. 

I don't understand why people are scared of changing names. If you aren't prepared to change names then your code will be a mess.

57 minutes ago, Rollo62 said:

I can see also benefit in maintaining code.

Imaging you change

TItemArray = TArray<TItem>;

to

TItemArray = TArray<TItemEx>;

In the TItemArray version you touch the code in one place only.

In the TArray<TItemEx> version you touch the code in thousands of places maybe.

Now you have the type named incorrectly in thousands of places. It should be called TItemExArray. 

Seems far worse to me. 

I can't really see any benefit here. I mean you might think that TItemArray is somehow better than TArray<TItem> but they seem pretty interchangeable to me in terms of readability. And the reader has to trust that convention was followed with TItemArray. 

5 hours ago, chkaufmann said:

The order of initialization sections and class constructor is at least partial random.

No. It is deterministic. 

29 minutes ago, Mike Torrettinni said:

Isn't TArray<T> only for generic usage? I use it when I define generic method, and is used like TArray,Method<T>.

Those are two completely different things. One is a generic dynamic array type, the other is a generic method. 

You are just polluting the namespace for no benefit. Use TArray<T>. 

D is a truly wonderful language, and Andrei Alexandrescu's book is by some distance the best programming book I have ever read.

On 6/13/2020 at 10:17 AM, David Heffernan said:

My post above demonstrates that RTTI does exist. I think that the real issue is that these types don't have qualified names.

Basically this then?

1 hour ago, Attila Kovacs said:

found by accident

 

 

So, is it the case that rtti is generated for types declared in the project file, but these rtti types don't have a qualified name? 

1 hour ago, Mahdi Safsafi said:

First, do you really think that I'm missing a basic fact about RTTI ?

I don't think about you at all. I was interested in the question. Try to view comments as impersonal. 

1 hour ago, Mahdi Safsafi said:

I'm still thinking that you're not understanding neither Attila question nor my answer.

That's entirely possible. I'm interested in learning. It's possible that my misunderstanding is because of imprecise statements. It's possible I'm slow on the uptake.

To be clear, I thought you said that types declared in the project file had no RTTI. I checked that and was able to retrieve RTTI for such types.

I simply don't understand the strength of your reaction. 

On 6/11/2020 at 11:39 PM, Attila Kovacs said:

The question is answered as far as I can see, Ctx.FindType(TypeName) fails on types declared in the dpr, doesn't matter what directives I put there,

@Mahdi Safsafi's answer is very plausible for me, with not having interface section, no public pool for them.

My post above demonstrates that RTTI does exist. I think that the real issue is that these types don't have qualified names.