-
Content Count
3427 -
Joined
-
Last visited
-
Days Won
169
Posts posted by David Heffernan
-
-
There's all sorts of things that Delphi should allow as constants, but that's a long known area of significant weakness in the language.
-
2 hours ago, Rollo62 said:Can the memory safety of RadStudio C++ safely assumed to be more improved than standard C++, because it's close relation to its sibling Delphi within the same package?
No
-
5 hours ago, Anders Melander said:Sounds like premature optimization
Exactly!
-
These microbenchmarks for floating point typically are of quite limited use. I remember making a bunch of changes based on such benchmarks and then finding absolutely no impact in the actual program, presumably because the bottleneck was memory.
-
7 minutes ago, Brandon Staggs said:I don't understand this but I would like to know what you are talking about.
There's nothing to understand, the original statement from @DelphiUdIT is incorrect
-
You call this method I think, however that's done from Delphi
CoreWebView2Profile.ClearBrowsingDataAsync Method (Microsoft.Web.WebView2.Core) | Microsoft Learn
-
Problem with doing this is that it will scale your window size also which is usually not what you want.
-
I think that's about right. The issue you were facing though is 2 rather than 1. The type that matters here is the handle type. LPPPLFHANDLE is a pointer to a handle. You were managing the pointer to correctly, but your handle was wrong.
You could actually declare your function like this:
// an out param function pp_lfopen(filename: LPSTR; lfflags: LONG; lftype: LONG; password: LPSTR; out handle: PPLFHANDLE): LONG; stdcall; // or a var param function pp_lfopen(filename: LPSTR; lfflags: LONG; lftype: LONG; password: LPSTR; var handle: PPLFHANDLE): LONG; stdcall;
Either of these would work. I show these to give a view on conceptually what that handle param is doing.
I usually prefer having a literal header translation so the version in my previous message is how I would do it. And for some function you want to be able to pass nil to indicate that you don't need the function to return a handle. In this case I'm pretty sure you'd never want to do that, you always want the handle, and so the out param version would be a reasonable translation.
Hope that helps!
-
The key here is that PPLFHANDLE is 32 bits in a 32 bit process and 64 bits in a 64 bit process. So you need a type that has the same property. For instance any pointer, or NativeInt or NativeUInt.
Now, in this case it seems that the expedient thing to do is to declare PPLFHANDLE as HGLOBAL. And in the Delphi winapi units HGLOBAL will be declared as a type that switches size based on process bitness. Actually it's NativeUInt but that's actually a detail you don't really need to know. Although it's nice to know it and help confirm the understanding!
So I would do this:
type PPLFHANDLE = HGLOBAL; LPPPLFHANDLE = ^PPLFHANDLE; function pp_lfopen(filename: LPSTR; lfflags: LONG; lftype: LONG; password: LPSTR; handle: LPPPLFHANDLE): LONG; stdcall;
Here I am using the same types as the header file. I generally think that it's preferable to keep an API translation as close to the original as possible.
The header file is a bit odd in the way it defines these types:
#ifndef PPLFHANDLE #ifdef _WIN64 #define PPLFHANDLE HGLOBAL #else #define PPLFHANDLE LONG #endif #endif #ifndef LPPPLFHANDLE #ifdef _WIN64 #define LPPPLFHANDLE HGLOBAL * #else #define LPPPLFHANDLE LPLONG #endif #endif
It looks like an earlier version wrongly declared PPLFHANDLE as LONG and then they've kept that mistake as they catered for 64 bit. This header code should really look like this:
#ifndef PPLFHANDLE #define PPLFHANDLE HGLOBAL #endif #ifndef LPPPLFHANDLE #define LPPPLFHANDLE PPLFHANDLE * #endif
- 1
-
Just now, Ron Howard said:Already changed it to Int64 from Longint just before your reply
That's also wrong.
-
30 minutes ago, Ron Howard said:Since there are both 32-bit and 64-bit versions of the DLL, I thougth I could get away with a single function definition, but apparently that is wrong.
No, you can have a single definition. You just need to get it right.
31 minutes ago, Ron Howard said:The LPPPPLFHANDLE is also a pointer to a LONG.
I doubt that. Where is the header file? Or can you show enough of it so that we can see the declaration of LPPPPLFHANDLE?
-
3 minutes ago, DelphiUdIT said:But the incompatibility with 64-level DLLs and ASLR is well known
There is no such incompatibility. It's just 64 to 32 bit value truncation caused by defective code.
- 2
-
10 hours ago, Anders Melander said:It's beyond me why they haven't implemented basic numerical functions such as Trunc, Round, Abs, etc. as compiler intrinsics so we at least can get them inlined.
I mean, they've shown no interest in performance whatsoever, and even less interest in floating point code. It's as much as they can manage to vaguely support all the different compilers they have and keep them functioning.
-
6 hours ago, DelphiUdIT said:I think the problem is the project options: in the new 11.3 (like 12) environment the additional setting about ASLR are ON, try to deselect them.
This isn't the problem. The problem is in the incorrect header file translation. The project settings that you highlight should not be changed. They are just the reason why the code has been exposed as being incorrect. That exposure should be celebrated! It's very wrong headed to try to ignore such a mistake as you propose here.
-
Looks like this has always been broken but you just got lucky because the 64 bit handles happened to have values that weren't changed when your code truncated them to 32 bits.
With the latest delphi your luck ran out because the values are now being changed by truncation, for whatever reason. But your code was always broken and you just got away with it. Be thankful for the new delphi version highlighting this.
The mistake is in your translation of the header code. There are going to be a bunch of pointer sized types that you have erroneously translated as 32 bit longint or integer.
-
19 minutes ago, DelphiUdIT said:I think he wants to try a general function, also for others rounding modes (he inserts other masks to the function).
But you are right, there are also other native CPU instructions that do that specif works (like that you exposed).Would be weird to want to truncate a single (a well defined task) and insist on doing so in an inefficient way.
-
4 hours ago, Lajos Juhász said:No. The change was made to follow the Windows standard. Other languages assume or will change the exception masks. That was fragile in previous versions of the Delphi. They made the change to follow other languages and minimalize the possibilities to have problems when calling an external DLL.
The price is that we have to adjust our code.
The point I think is that FMX projects masked exceptions previously by accident rather than design.
Why should making an empty FMX project bring in all those units and change the floating point control state?
I understand why the change to the default was made. I kind of agree with it.
But changing your code to match isn't always going to be easy. I think it would be a huge task for any code base that is heavily numerical. I certainly wouldn't change.
-
57 minutes ago, Rollo62 said:Thanks for pointing to this nice page, which shows the overview of old and new behaviour nicely.
http://docwiki.embarcadero.com/RADStudio/Athens/en/Floating_Point_Operation_Exception_Masks
I've tried to summarize that and make the relevant differences even more visible in this overview:
I was interested to see different behaviour between VCL and FMX on Windows, in pre Delphi 12.
I'm not sure that this is especially intentional. It happens because FMX.Platform.Win uses FMX.WebBrowser which uses FMX.WebBrowser.Win which uses System.Win.InternetExplorer which does this in its initialization
FSetExceptMask(femALLEXCEPT);
I guess it does this because this the IE library implementation expects exceptions to be masked.
Similarly a default FMX app will use Winapi.EdgeUtils which also masks exceptions for the same reason.
I actually think it makes sense to have all platforms behaving the same way and exceptions being masked by default. That being the platform standard on all of these platforms.
Myself, I'm going to keep unmasking exceptions because my codebase relies on that. I hope that the Delphi RTL will continue supporting being used with exceptions unmasked.
-
34 minutes ago, shineworld said:So, to use a 3rd part DLL made with C++, eg: MSVC or C++Builder itself, it is necessary to create a Proxy C DLL with C++ Builder.
I don't think that's the case. If you need to interface with a C++ codebase, then you need to create either a C wrapper, or a COM wrapper, but in each case you aren't limited to C++Builder. Whichever compiler you use to compile the C++, you compile the C wrapper, or the COM wrapper. The point is that the C or COM wrappers are compiler agnostic. But C++ code is, in general, not compiler agnostic. So you just need to compile your wrapper in the same toolchain as the C++ library.
There are actually tools to create such wrappers. I'm thinking of SWIG.
But there's no way that there's going to be a Delphi produced which can consume C++ libraries compiled by some arbitrary C++ compiler.
-
Just now, JonRobertson said:How was it possible with Delphi 1?
Because Delphi 1 could import functions from DLLs.
-
3 hours ago, shineworld said:Good to hear but no real match.
There are two libraries in git for porting OpenCV to Delphi.
Both use a middle-man C DLL made in C++ Builder to access the DLLs...That's inevitable though isn't it. Because OpenCV is written in C++. For which there is no single binary interface.
-
1 hour ago, shineworld said:Delphi13 will be useful to import DLL made with C++ to open road to use directly tools like OpenCV, VTK, numpy, etc.
This can already be done, and has been possible since Delphi 1
- 1
-
How much are you prepared to pay? What exactly does the job entail? You may be better asking directly on sites that are designed to put together people looking for contract programmers.
Are you asking any more than you did here:
-
55 minutes ago, Kas Ob. said:yet it is safer than C++
It's not safer than C++, it's exactly the same as C++
- 1
Delphi should let me use a const array reference as a constant
in RTL and Delphi Object Pascal
Posted
We'd all like that. Prospects are not good for it happening.