When compiling my application, there is a compiler warning:
[DCC Warning] ... W1002 Symbol 'IncludeTrailingBackslash' is specific to a platform
How do I avoid this warning?
Delphi XE2 has another function IncludeTrailingPathDelimiter which can be used in place of IncludeTrailingBackslash. This function is supported on any platform that Delphi supports.
To avoid the warning, turn it off in the config dialog. This turns off all other plattform specific warnings as well, which might be helpfull, as you are not going to develop Linux-Apps anyway, I assume.
To get around the warning, use another function (IncludeTrailingPathDelimiter) as you suggested.
Related
In Delphi we have multiple warn the compiler the provide to protect you do do something bad. Some are errors other warns etc.
I want to turn off the Warn for SYMBOL_DEPRECATED for all my files in the project.
But I just found ways to do it by file ?
Project->Options->Hints and Warnings from the menu.
Change Deprecated Symbol in the list to False. You'll need to do it for each target (Debug Win32, Release Win32, etc.), as they're maintained separately.
(Not sure why you'd want to do that, BTW. Deprecated symbol warnings are meaningful, as opposed to the Platform Unit when you're clearly doing a VCL Windows app and not FMX. You should heed deprecated symbol warnings, as those mean that code can break in the future and you're not prepared.)
NSDeprecated which tunnels through CF_Deprecated into the clang attribute availability only handles deprecation for MACOSX and IOS.
Are there any calls or series of macros that replicate this tool for third parties.
I am working on V2 of an SDK and there are certain calls we want to deprecate as well as EOL.
(Please note, this SDK is still in Objective-C; so Swift only solutions don't solve my issue)
The deprecation warnings and errors would be fantastic at compilation and code generation time; however, I fear this is something I'd need to spin on my own.
Any pointers or reference on this before I have to decide if I need to kill the time on this side project?
You can #define a macro in your SDK project to make a shorthand for the deprecation message. We did something similar in the Core Plot project.
There is a function attribute deprecated provided by GNU compiler.
The syntax to mark deprecated functions is:
void Foo() __attribute__( (deprecated("message", "replacement")) );
The first one is the message to display when emitting the warning; the second one enables the compiler to provide a Fix-It to replace the deprecated name with a new name.
More information on using function attributes can be found in GCC Attribute Syntax documentation or Attributes in Clang documentation
some handy macros are in the NSObjCRuntime.h from Apple.
NS_DEPRECATED_IOS(6.0,10.0)
works like a charm.
I get a warning when i compile my project.
[DCC Warning] ...W1047 Unsafe code '^ operator'
On build info:
Target CoreCompile:
....\dcc32.exe -$W+ -$J+ --no-config ... -W+UNSAFE_TYPE -W+UNSAFE_CODE -W+UNSAFE_CAST
I know that I can set this off, but I can't find where todo this on delphi 2010.
On Project>Options>Delphi Compiler>Hint and Warnings: I have Unsafe code, unsafe type and unsafe typecast to false
Can somebody help me.
If the warnings are disabled in the IDE options dialog, then the command send to dcc32 will not enable them. Which leads me to believe that the warnings are enabled in the IDE options.
So, my guess is that you have multiple build configurations and are looking in the wrong build configuration in the IDE.
I always get confused by the way the IDE presents build configurations. You may find it easier to search the .dproj file in a text editor. Look for DCC_UNSAFE_CODE, DCC_UNSAFE_CAST and DCC_UNSAFE_TYPE. You can then delete all of those entries and your settings will revert to the default value, which is not to warn.
As you know in Delphi we can use Deprecated directive to say a method or ... is obsolete or supported only for backward compatibility and we can use Experimental directive to say current unit are in an unstable development state .
Deprecated & Experimental directives work properly in form,s unit , but when we use it on unit that we add to application manualy they don,t work and when compile application don,t show any warning message in message window .
May i should enable any directive like {$HINTS ON} or {$WARNINGS ON} in that unit ?
Any one can help me ?
Thanks alot .
I think you've answered the question yourself. These directives make the compiler emit warnings, but only if warnings are enabled at that point in the compilation. Note that these symbols produce warnings rather than hints.
I personally configure the compiler to treat the use of deprecated symbols as an error rather than a warning.
I use statically linked sqlite database and in order to compile every next version I sometimes have to do minor changes in the list of object files used.
But sometimes the changes I have to make puzzles me.
For example prior to version 3_6_10 this order
{$L 'Objs\is.OBJ'}
{$L 'Objs\mbisspc.OBJ'}
was ok, but starting 3_6_12 the linker said
unsatisfied forward or external declaration _isspace
but changing the order to
{$L 'Objs\mbisspc.OBJ'}
{$L 'Objs\is.OBJ'}
helped.
As for the changes in sqlite, it really stopped to use c function isspace in 3_6_12 and started to use an internal equivalent so "isspace" keyword even don't appear inside the obj file.
So why does the order of linked object file with $L directive matter and where I can read more about this? I suppose it is something related to cross-usage of the listed obj files, but I will feel more safe if I understand what is going on
Thanks
Edit:
As of the comment by David Heffernan linking to his answer to this other question on linking .obj file in Delphi, I replaced linker by compiler, and added a the italic portion below:
C compilers use a multi-pass linker compiler that knows how to resolve forward and circular dependencies between .obj files.
Since the Delphi linker compiler is targeted at the Delphi language, and the Delphi language does not allow for that, the linker compiler does not allow for this either.
Pro: the linker compiler is much faster.
Con: you need to help the linker compiler a bit by placing the .obj files in the right order
, or by manually resolving the dependencies (see the above mentioned answer by David Heffernan)
.
--jeroen