While working on a project we were having 4000+ warnings.
To remove some of those I found one compiler Directive as NEXTGEN.
After Using this directive I found that there is a much more minimize in the warnings to 257.
I want to know if we have any issues in using the compiler directive. Are there any drawback of this directive for my windows application.
I am using Delphi 10.
on Site of Embarcadero I found very less information.
Can anyone tell me something about the same?
Delphi's NEXTGEN conditional symbol marks the next-generation ARC compilers. The Windows and OSX compilers are not NEXTGEN compilers. The iOS and Android compilers are NEXTGEN. Initial release of Linux compiler in 10.2 Tokyo had NEXTGEN defined, but since 10.3 Rio it does not.
Any code compiled for Windows that is marked with NEXTGEN will be ignored in current compilers.
See Conditional symbols:
Defined for compilers (such as the Delphi mobile compilers) that use
"next-generation" language features, such as 0-based strings.
New in XE4/iOS
Update: 10.4 Sydney
NEXTGEN symbol has been removed from all compilers, along with AUTOREFCOUNT and WEAKINSTREF symbols.
The NEXTGEN conditional symbol is defined by the compiler. It is defined, for instance, for the mobile compilers that use ARC. It is not defined for the traditional Windows and Mac OS compilers.
You must not define it in your code. You are compiling your code with a traditional compiler, not a NEXTGEN compiler. Whatever is responsible for these compiler warnings, defining NEXTGEN is not the solution.
Related
I am running Delphi XE8 and have the GetIt AsyncPro for VCL 1.0 installed. It works fine when I compile my application for 32 bit but fails for 64 bit.
The failure is:
[dcc64 Error] OoMisc.pas(2771): E2065 Unsatisfied forward or external declaration: 'Trim'
When I open OoMisc.pas is see:
{$IFNDEF Win32}
function Trim(const S : string) : string;
{$ENDIF}
The Trim function does not seem to be defined. The unit does have SysUtils in its uses clause.
AsyncPro supports only Win32 platform. It cannot be used as-is for Win64 bit.
It contains plenty of 32bit inline ASM code that would have to be replaced either by Pascal code or ported to 64bit ASM code. Besides that part there might be other incompatibilities with Win64 bit platform.
Converting 32-bit Delphi Applications to 64-bit Windows - Inline Assembly Code
If your application contains inline assembly (ASM) code, you need to
examine the ASM code and make the following changes: Mixing of
assembly statements with Pascal code is not supported in 64-bit
applications. Replace assembly statements with either Pascal code or
functions written completely in assembly.
Porting assembly code from IA-32 to Intel 64 cannot be done by simply
copying the code. Consider the architecture specifics, such as the
size of pointers and aligning. You may also want to consult the
processor manual for new instructions. If you want to compile the same
code for different architectures, use conditional defines. See Using
Conditional Defines for Cross-Platform Code in "Using Inline Assembly
Code."
RAD Studio supports Intel x86 through SSE4.2 and AMD 3dNow, and for
x64, Intel/AMD through SSE4.2.
Using Inline Assembly Code
Update:
There is Win64 port of AsyncPro provided by Johan Bontes:
I have a version for Win64 on my Github:
https://github.com/JBontes/AsyncPro
It compiles, but I have not been
able to test it comprehensivly. Feel free to file an issue if you get
stuck anywhere.
I bet that is a relic from Delphi 1 when Win32 was used to distinguish from Win16. You may safely remove those lines.
I converted AsyncPro to XE8 but it only supports Win32.
OoMisc.pas had a Trim function, that was removed from the implementation part. However somebody forgot to remove it from the interface part. That didn't hurt for x32 because it was inside of the $IFNDEF.
Win32 is not defined for x64, so the compiler will complain. The solution for this particular issue is to delete the following 3 lines that were intended for Delphi 1.0.
{$IFNDEF Win32}
function Trim(const S : string) : string;
{$ENDIF}
Of course that does not make AsyncPro compatible with x64 as there will be other issues.
I am searching for a list of supported object file formats for each delphi version. Object files should be linked with something like: {$L lib/object.o}.
The Reason for this is a linker error in Delphi7 for a project i maintain. The error does not occur in compilers >XE3. I have only XE3 and above to test.
Has someone maintained a list or knows a reference to one where i can find informations about the supported format and/or changes with newer versions, maybe also problems with object files, etc?
I would like to help a user of the project with this problem (lz4-delphi issue).
The change came with XE2 which added support for the COFF object format. Prior versions only supported OMF objects.
The change to add support for COFF was driven by the new 64 bit compiler, introduced in XE2. Embarcadero did not have a 64 bit C++ compiler at that time and so needed to link objects produced by another compiler. They chose to use the MS compiler which emits COFF objects.
Allen Bauer's answer to a question that I asked contains more detail.
In practical terms this means that for Delphi 7 you will need to compile the source code with bcc32. Or compile the C code with some other compiler but then link to a DLL.
For future reference, Delphi 10.1 Berlin and 10.2 Tokyo both support ELF64 format, and also COFF.
How and where can I write ARM Assembly codes in Embarcadero Delphi XE5 with Android?
That would be the best, if I can write it inline.
Delphi mobile compiler do not support the asm ... end blocks.
But the "old good way" is still available, since we are talking about a Native compiler.
What you can do is compile your own module with an external assembler (e.g. GNU AS), then link it to your Delphi XE* application.
For instance, System.RTTI uses low-level asm tricks via external statically linked files:
procedure RawInvoke(CodeAddress: Pointer; ParamBlock: PParamBlock);
external 'librtlhelper.a' name 'rtti_raw_invoke';
procedure RawIntercept;
external 'librtlhelper.a' name 'rtti_raw_intercept';
Take a look at this Japanese article - Google translate is your friend!
It is not possible.
Use Atomic Instrinsics Instead of Assembly Language.
Quote:
The Delphi mobile compilers do not support a built-in assembler.
The Delphi mobile compilers do not support inline assembler. The documentation makes this clear:
The inline assembler is available on:
DCC32.EXE, the Delphi Command Line Compiler
DCC64.EXE, the Delphi 64-bit Command Line Compiler
DCCOSX.EXE, the Delphi Cross Compiler for OS X
You'll need to find an assembler to create something that the Delphi mobile compiler can consume, for instance a shared library.
You can not.
LLVM - which is the engine behind Delphi Mobile - has its kind of an assembler language: http://llvm.org/docs/CommandGuide/llvm-as.html
But it would hardly be ARM kind or x86 kind, since LLVM tries to be CPU-agnostic.
Anyway Delphi officially has no support neither for CPU-native assembling language nor for LLVM kind of it.
http://docwiki.embarcadero.com/RADStudio/XE4/en/Migrating_Delphi_Code_to_iOS_from_Desktop#Use_Atomic_Instrinsics_Instead_of_Assembly_Language
http://docwiki.embarcadero.com/RADStudio/XE4/en/Using_Inline_Assembly_Code
I use this code in my project:
var
P: TPoint;
MyControl.Perform(WM_LBUTTONDOWN, 0, Longint(PointToSmallPoint(P)));
The compiler gives me a warning:
[Warning]: Unsafe typecast of 'TSmallPoint' to 'Integer'
But, the same code is used in Controls.pas without any warnings - for example in TControl.BeginDrag method:
....
Perform(WM_LBUTTONUP, 0, Longint(PointToSmallPoint(P)));
I don't see any {$warnings off} in Controls.pas unit.
Why is the compiler warning me, but skips the warning for Controls.pas?
Is this code Unsafe?
Edit: in my Project Options -> Compiler Messages -> Unsafe Typecast is checked (which by default is unchecked).
Maybe this is why #David and #Ken could not reproduce the warning.
This is caused because you have unsafe typecast warnings checked in Project->Options->Compiler Messages. This is safe to uncheck (as are unsafe type and unsafe code above it. (See below.)
I couldn't reproduce the warning because I have unsafe type cast unchecked. It's no longer applicable. (It was added in Delphi 6 or 7 for .net compatibility when they were developing Delphi for .NET, to make it easier to write code that worked for both .NET and Win32; since the Delphi for .NET product was discontinued, that warning (and the two above it) are not applicable any longer). The "unsafe" in these three warnings use the .NET meaning of "unsafe", meaning "unmanaged".
From the Delphi 7 help file (search for "Compiler Changes") (emphasis mine):
The Delphi dcc32 compiler now supports three additional compiler warnings: Unsafe_Type, Unsafe_Code, and Unsafe_Cast. These warnings are disabled by default, but can be enabled with the compiler directive {$WARN UNSAFE_CODE ON}, compiler command line switch (dcc32 -W+UNSAFE_CODE), and, in the IDE, on the Project|Options|Compiler Messages page.
This feature is intended to help you port your code to the managed execution environment of Microsoft's .NET platform. In a managed execution environment, "unsafe" means the operation cannot be verified during the static analysis performed by the Just In Time (JIT) compiler. Such code might pose a security risk, since there is not enough information for the JIT compiler to verify its runtime behavior. Examples of unsafe code include pointer operations and memory overwrites.
If you compile the Controls unit yourself, with the unsafe typecast warning enabled, then you will see the warning. But if you link the pre-built .dcu file then you see no warning. The compiler only emits warnings on units that it compiles.
As a general rule, the RTL and VCL units generate large numbers of hints and warnings. If ever I have to re-compile them, I always have to switch hints and warnings off on those units.
The modern day documentation for the warning says:
You have used a data type or operation for which static code analysis cannot prove that it does not overwrite memory. For example, you might have cased (sic) one record to another or one instance to another.
And that warning does apply to your code. Your code is unsafe. The compiler cannot verify that it is correct to overlay two 16 bit integers onto a 32 bit integer. So the compiler warns you. It's up to you to decide whether or not the code is correct.
Now, it appears that the warning was intended primarily for the .net compiler. All the same, it still has meaning for the Win32 compiler. Overlaying one record on another is suspicious behaviour.
My 32 bit Delphi 2010 application links to a number of C object files using the $LINK compiler directive. Can I do this in Delphi XE2 when targetting 64 bit?
I am currently compiling using bcc32 version 5.5, but I don't mind which compiler I use if it turns out that the Embarcadero C compiler does not yet output 64 bit objects.
Yes. You must compile the "C" objects files to COFF format. This usually means either the Intel and/or MSVC++ compilers. The same caveats apply to 64bit object file linking that apply to 32bit. You must ensure that all external references are properly resolved, either by providing another .obj which has that symbol, or from Delphi code. When building the "C" code, make sure you disable any stack checks or other run-time verification code generation. Many times such codegen relies on a specific version of the C/C++ RTL from the given tool.
Something else worth noting is that while Delphi 64bit can link to COFF object files (eventually it will also support ELF64), 32bit Delphi supports linking with C++Builder built OMF object files and, new to XE2, 32bit COFF object files which can be built with MSVC++. The same caveats apply.
Yes, you can link to OBJ files in 64-bit XE2 projects, but the OBJ files have to be 64-bit code.