Leaderboard

During the upgrade process the unknown resources are moved to the .otares file and the dpk gets a reference for that. The recommended process in such a case is to use decent resources for the unknown ones and get rid of the .otares and the corresponding entry in the dpk. In the majority of cases the otares only contains a resource named PLATFORMTARGETS, which references targets no longer supported by the newer Delphi version. A typical otares file in that case has 96 bytes and can just be removed completely. Unfortunately some library vendors and open source libraries didn't grasp this and deliver these otares files. The warning you are referring to may be caused by something else. Perhaps one or more of those unknown resources were later added as regular resources to the project, which leads to the duplicate warning. The linker just detects resources with the same name, which cannot be resolved into one module.

Why would you stream the pointers? They only have any meaning inside each application as a reference to a memory position.

When performance is an issue, pass by reference then. Presumably you are happy to use value types like integer? Or do you shun all value types? Prevent what bugs? Code with interfaces can have bugs too. So it's not some magic solution. Code using interfaces can have leaks. They are still there, the compiler writes them. It's the exact same pattern as used with classes. It's well known and easy to follow. This is true. But it's simple enough to flow the rules and avoid this.

I am not following. What function declarations have with records and record pointers we are talking about here? You cannot separate ownership from access. The pointer no longer has the responsibility to release it, but instead of having one problem - one reference that needs to be tracked, managed and released. You now have two you need to pay attention to. Just because you only need to release one, does not mean that you can do just about anything with the other. And if you pass such pointer to the record out of scope, you have just created access violation. Once you free the wrapper object, your record pointer becomes dangling reference. I am not even going to comment about whole wrapping record into object and then working with pointer to that record instead of just using pointer and be done with it... Whether or not you would do all that depends on the context of the code you are dealing with. Wrapping object in a object or an automatically managed object could make sense, but it could also be the opposite. first you need to write such wrapper code and then you need to maintain it. Again, it could make sense in some scenarios where you want to add some additional functionality to a record you cannot otherwise change, but just for allocation it on the heap it doesn't.

As long as we are talking about personal opinions, mine is just not moved much by this reasoning. Record pointers are nothing exotic or anachronistic in Delphi. That is a lot more common than having classes with no methods, imo. Also, there is nothing superior about a free call on a class compared to calling dispose on a record pointer. The Delphi language absolutely requires learning memory management. The removal of the misguided ARC baggage from the language shows that will not be changing. No reason to try to find ways to dumb it down.

Well, in Delphi we commonly use phrases untyped and typed pointers. so when you say raw pointer in Delphi context my immediate association is untyped pointer, especially since your next comparison with C++ unique pointer and shared pointer which are automatically managed was completely unrelated feature to Delphi objects which are not automatically managed. So I assumed that you wanted to say untyped, as I haven't made the connection with the rest and what you are trying to say. I am still not certain what was your original point... as it seems that you were arguing for both style and memory management, otherwise why mentioning unique and shared pointer. I have chosen to disregard the automatic memory management part as this would be adding additional level of complexity and focus on the class part alone. Again, that depends on the rest of the code. In general, if you are dealing with records, then using typed pointer to that record is more consistent and idiomatic than wrapping that record into a class, just to have it allocated on the heap. Especially, since Delphi no longer requires dereferencing typed pointers when working with their content. TRec = record x: Integer; end; PRec = ^TRec; TRecObject = class public r: TRec; end; var p: PRec; begin New(p); try p.x := 5; finally Dispose(p); end; end; var o: TRecObject; begin o := TRecObject.Create; try o.r.x := 5; finally o.Free; end; end If you look at the above code, the using pointer makes code more readable than having wrapped record as you can directly access its content through pointer reference instead of having another level of indirection between.

Typed pointers are quite different from raw pointers. Both class and pointer in make sense, but which one you will chose, pretty much depends on the other code in the context. Declaring a class merely for a single procedure might be an overkill. From the safety perspective typed pointers in Delphi are equally safe or unsafe as classes. You still have to manage their memory and pay attention to what you are doing with them.

Pointers should not be avoided and I highly suggest programmers should learn to use them properly and embrace them. They can make life so much easier.