Except for constants RTLVersion and CompilerVersion is there any way how to get version symbol like VER320 instead of following code?
'VER' + IntToStr(Trunc(CompilerVersion * 10))
The simple answer to the question is no. There is no mechanism for code to enumerate conditional symbols.
Your current approach is probably the best you can do, subject to there being no guarantee that future release of the compiler will follow the current VERxxx convention.
Of course, you may as well simply report the compiler version directly.
Related
In typical Apple fashion, there's no documentation (and what little there borders on trolling). For example, what is simd_precise_normalize(_:)? You’d be forgiven for thinking it was a slower, more precise normalization than simd_fast_normalize(_:). But then why does simd_normalize(_:) exist?
Why is there simd_cross(simd_float3, simd_float3) and cross(SIMD3<Float>, SIMD3<Float>) when typealias simd_float3 = SIMD3<Float>?
And what about the Swift operator overloads on simd_float3?
I've written a bug to Apple about it, but does anyone know?
But then why does simd_normalize(_:) exist?
This comment explains it. simd_normalize is equivalent to simd_precise_normalize unless you are compiling with -ffast-math specified, in which case it is equivalent to simd_fast_normalize. I never used swift only objective-c, but it’s possible there’s equivalent option somewhere in compiler switches or xcode project settings.
Why is there simd_cross(simd_float3, simd_float3) and cross(SIMD3, SIMD3)
I think they are equivalent. Note that comments in the header discuss both C-style API like simd_cross(x,y) and C++ API simd::cross(x,y). It could be that in Swift both are available for some of these functions.
I am evaluating Keil Microvision IDE on STM32H753.
I am doing compiler comparison between ARMCC5 and AC6 in the different optimisation levels. AC6 is based on Clang.
My code is not using memcpy and I have unchecked "Use MicroLIB" in the project settings , However a basic byte per byte copy loop in my code is replaced by a memcpy with AC6 (only in "high" optimisation levels). It doesn't happen with ARMCC5.
I tried using compilation options to avoid that, as described here: -ffreestanding and -disable-simplify-libcalls, at both compiler and linker levels but it didn't change (for the second option, I get an error message saying that the option is not supported).
In the ARMCLANG reference guide i've found the options -nostdlib -nostdlibinc that prevent (??) the compiler to use any function of a standard lib.
However I still need the math.h function.
Do you know how to prevent clang to use functions from the Standard C Lib that are not explicitely called in the code ?
EDIT: here is a quick and dirty reproduceable example:
https://godbolt.org/z/AX8_WV
Please do not discuss the quality of this example, I know it is dumb !!, I know about memset, etc... It is just to understand the issue
gcc know a lot about the memcpy, memset and similar functions and even they are called "the builtin functions". If you do not want those functions to be used by default just use the command line option -fno-builtin
https://godbolt.org/z/a42m4j
In code that I help maintain, I have found multiple examples of code that looks like this:
Description := IfThen(Assigned(Widget), Widget.Description, 'No Widget');
I expected this to crash when Widget was nil, but when I tested it, it worked perfectly.
If I recompile it with "Code inlining control" turned off in Project - Options - Compiler, I do get an Access Violation.
It seems that, because IfThen is marked as inline, the compiler is normally not evaluating Widget.Description if Widget is nil.
Is there any reason that the code should be "fixed", as it doesn't seem to be broken? They don't want the code changed unnecessarily.
Is it likely to bite them?
I have tested it with Delphi XE2 and XE6.
Personally, I hate to rely on a behavior that isn't contractual.
The inline directive is a suggestion to the compiler.
If I understand correctly what I read, your code would also crash if you build using runtime packages.
inlining never occurs across package boundaries
Like Uli Gerhardt commented, it could be considered a bug that it works in the first place. Since the behavior isn't contractual, it can change at any time.
If I was to make any recommendation, I would flag that as a low priority "fix". I'm pretty sure some would argue that if the code works, it doesn't need fixing, there is no bug. At that point, it becomes more of a philosophical question (If a tree falls in a forest and no one is around to hear it, does it make a sound?)
Is there any reason that the code should be "fixed", as it doesn't seem to be broken?
That's really a question that only you can answer. However, to answer it then you need to understand fully the implications of reliance on this behaviour. There are two main issues that I perceive:
Inlining of functions is not guaranteed. The compiler may choose not to inline, and in the case of runtime packages or DLLs, a function in another package cannot be inlined.
Skipping evaluation of an argument only occurs when the compiler is sure that there are no side effects associated with evaluation of the argument. For instance, if the argument involved a function call, the compiler will ensure that it is always evaluated.
To expand on point 2, consider the statement in your question:
Description := IfThen(Assigned(Widget), Widget.Description, 'No Widget');
Now, if Widget.Description is a field, or is a property with a getter that reads a field, then the compiler decides that evaluation has no side effects. This evaluation can safely be skipped.
On the other hand, if Widget.Description is a function, or property with a getter function, then the compiler determines that there may be side effects. And so it ensures that Widget.Description is evaluated exactly once.
So, armed with this knowledge, here are a couple of ways for your code to fail:
You move to runtime packages, or the compiler decides not to inline the function.
You change the Description property getter from a field getter to a function getter.
If it were me, I would not like to rely on this behaviour. But as I said right at the top, ultimately it is your decision.
Finally, the behaviour has been changed from XE7. All arguments to inline functions are evaluated exactly once. This is in keeping with other languages and means that observable behaviour is no longer affected by inlining decisions. I would regard the change in XE7 as a bug fix.
It already has been fixed - in XE7 and confirmed that this was supposed to be wrong behavior.
See https://quality.embarcadero.com/browse/RSP-11531
Everyone knows about hint directives. However from reviewing various modules, i learned what, for example, deprecated accepts string -literal- to be emitted in the same manner $MESSAGE does:
procedure StinkStr(S: string); deprecated 'You are unemployed now.';
However, documentation being modestly silent about that (highest version i have my hands on is D2010) and i hate guesswork in exact sciences - the questions are:
where this syntax is documented?
and, since which version it has been available?
Correction: accepts string literals only, refuses constants (a la external).
Current findings: D210 chokes on string literals accompanying any hint directive other than deprecated, also eats the hint if unit is marked with it.
It's documented here http://docwiki.embarcadero.com/RADStudio/en/Deprecated
As the comments mention above, it seems to have been introduced in Delphi 2009. Another reference is http://www.tindex.net/Language/deprecatedwithcomment.html
I need to patch a method in Classes.pas
(TReader.ReadString - I want to force it to use a specified codepage, not the system default).
If I copy Classes.pas into my project,I will end up having to rebuild the entire VCL. Is there any (easy) way to patch a method at runtime?
Modifying the implementation side of Classes.pas will not require recompiling everything. Delphi figures out if a unit needs to be recompiled by an algorithm that looks roughly like this:
If DCU found:
Is DCU format out of date (old version of compiler)? If so, need source to recompile or compile-time error.
Is the source on the path? If so, if it's newer than the DCU, recompile
For each used unit:
Repeat analysis when loading
For each used symbol ("import": type, variable, routine, initialized constant etc.) from that unit:
Is symbol version of import different to symbol found in used unit? If so, recompile needed.
If DCU is not found, source will need to be found and compiled, otherwise compile-time error
The important concept is that of symbol version. When saving a DCU, Delphi calculates a hash based on the interface declaration of the symbol and associates it with the symbol. Other units that use the symbol also store the symbol version. In this way, link-time conflicts caused by stale symbols are avoided, unlike most C linkers.
The upshot of this is that you should be able to add Classes.pas to your project and modify its implementation section almost to your heart's content, and still be able to statically link with the rest of the RTL and VCL and third-party libraries, even those provided in object format only.
Things to be careful of:
Inlined routines; the body of inlined routines are part of the symbol version
Generics; the implementation side of generic types and methods are part of the respective symbol versions
I found VCLFixPack:
https://www.idefixpack.de/blog/bugfix-units/vclfixpack-10/
I used the techniques from this to replace the method I wanted to patch at runtime.