Board index » jbuilder » Compiler directives

Compiler directives


2003-12-16 04:39:49 PM
jbuilder18
Hi EveryOne,
Is it possible to implement some compiler directives in JBuildrer and have
different compilation profiles based on these directives ?
Thanks for ur future answers...
--
P. Mermod
PKL Group CTO
www.pkl.ch
 
 

Re:Compiler directives

Should they be avoided? Why?
 

Re:Compiler directives

Quote
Should they be avoided? Why?
They are usually unavoidable, but IMO their use should be minimized, because
they make code less readable and maintainable.
Another reason is that their change is only reflected on the units that are
recompiled, so changing them can lead to curious bugs if you forget to fully
rebuild.
 

{smallsort}

Re:Compiler directives

Abdullah Kauchali wrote:
Quote
Should they be avoided? Why?
I think some are very useful:
{$M+} I have had to use this in the past when I needed to generate RTTI
information but did not want to derive from TPersistent.
{$IFDEF}, {$DEFINE} etc. : Important if you're building commercial
components or libraries that support different Delphi versions. Sort of
Important if you might want a copy of code that is specific to one
customer (when you sell to many) but there usually are other ways to do
this, including code forking which is perhaps the easiest business
solution.
{$APPTYPE CONSOLE} I think the compiler needs this to emit some
information in the EXE.
{$ASSERTIONS ON} Use it for developer level error catching. Tricky if
somebody puts run-time condition checks in there, but that's a training
thing.
{$DENYPACKAGEUNIT}{$DESIGNONLY} etc. are package level compiler
instructions
{$I+} Have had to use this when using type "Text" and
OpenFile/Reset/Rewrite functions.
There are others that one tends to use because they are debug options,
optimization and so on.
{$I} Well this is only useful in some cases, and I think the difference
between doing this vs. using the unit initialization and finalization
sections don't run. But, is useful for IFDEF sets.
I've never had to use:
{$Align}, {$Stackchecks}, {$M}, {$R}, {$REALCOMPATIBILITY}, {$U} or
{$Y}
I think are dangerous to use at all:
{$BoolEval On} {$Warnings Off}
--
Deepak Shenoy (TeamB)
shenoyatwork.blogspot.com
 

Re:Compiler directives

Quote
Should they be avoided? Why?
I don't like $ifdef - it always leads to less readable code, and it can be
abused to make *much* less readable code.
The other ones like $B- etc can be essential in some circumstances. A particular
example is when you write components. It's a good practice to put all the
required compiler directives in an inc file so that your components will compile
properly no matter what options any of your users might change.
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper XXXX@XXXXX.COM
Skype : jim.cooper
Singapore mobile: +65 9345 0024
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
 

Re:Compiler directives

"Abdullah Kauchali" < XXXX@XXXXX.COM >wrote in message
Quote
Should they be avoided? Why?
Use them carefully. To minimize problems that are hinted at by Reba, use
them only in your .dpr - because this file will always be compiled.
Raise a flag, depending on the compiler directive, which in turn can be
dealt with in code, in a dependent unit.
 

Re:Compiler directives

Quote
{$I+} Have had to use this when using type "Text" and
OpenFile/Reset/Rewrite functions.
This is a legacy feature left over from UCSD Pascal that I remember being
taught in 1981. This really is a stupid way to handle exceptions and error
values. I know Wirth didn't like exceptions, and preferred error value, but
this third alternative surely offends almost everyone.
Oliver Townshend
 

Re:Compiler directives

Deepak Shenoy (TeamB) wrote:
Quote
I think some are very useful:
Wow. Thanks so much for that detailed answer, Deepak. Much
appreciated! :)
Many thanks to the other posters as well.
 

Re:Compiler directives

I have a file "BuildOptions.inc" that I include in my projects
{$IFNDEF RELEASE}
{$IFNDEF DEBUG}
Define DEBUG or RELEASE
{$ENDIF}
{$ENDIF}
{$O+} //Optimisation on
{$U+} //Check for flawed Pentium FDIV
{$B-} //Complete boolean evaluation off
{$R+} //Range checking on
{$O+} //Overflow checking on
{$IFDEF DEBUG}
{$W+} //Stack frames on
{$D+} //Debug info on
{$L+} //Local symbols on
{$C+} //Assertions on
{$ELSE}
{$W-} //Stack frames off
{$D-} //Debug info off
{$L-} //Local symbols off
{$C-} //Assertions off
{$ENDIF}
I then have to define either DEBUG or RELEASE in my app's conditional
defines.
--
Pete
====
Audio compression components, DIB graphics controls, FastStrings
www.droopyeyes.com
My blog
blogs.slcdug.org/petermorris/
 

Re:Compiler directives

Oliver Townshend wrote:
Quote
>{$I+} Have had to use this when using type "Text" and
>OpenFile/Reset/Rewrite functions.

This is a legacy feature left over from UCSD Pascal that I remember
being taught in 1981. This really is a stupid way to handle
exceptions and error values. I know Wirth didn't like exceptions,
and preferred error value, but this third alternative surely offends
almost everyone.
You know what, you're right. I'd much rather use a try/except block,
come to think of it. I haven't used Reset or Rewrite in a very long
time, with line based reading having given way to block reading and
using parsers :)
--
Deepak Shenoy (TeamB)
shenoyatwork.blogspot.com
 

Re:Compiler directives

forgot
{$E fmx}
Which I just recently used for the FIRST time. I wrote a Delphi SDK for
Filemaker plugins.
Joe Mele
www.youseful.com
www.fmplugin.net
"Deepak Shenoy (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
Abdullah Kauchali wrote:

>Should they be avoided? Why?

I think some are very useful:

{$M+} I have had to use this in the past when I needed to generate RTTI
information but did not want to derive from TPersistent.

{$IFDEF}, {$DEFINE} etc. : Important if you're building commercial
components or libraries that support different Delphi versions. Sort of
Important if you might want a copy of code that is specific to one
customer (when you sell to many) but there usually are other ways to do
this, including code forking which is perhaps the easiest business
solution.

{$APPTYPE CONSOLE} I think the compiler needs this to emit some
information in the EXE.

{$ASSERTIONS ON} Use it for developer level error catching. Tricky if
somebody puts run-time condition checks in there, but that's a training
thing.

{$DENYPACKAGEUNIT}{$DESIGNONLY} etc. are package level compiler
instructions

{$I+} Have had to use this when using type "Text" and
OpenFile/Reset/Rewrite functions.

There are others that one tends to use because they are debug options,
optimization and so on.

{$I} Well this is only useful in some cases, and I think the difference
between doing this vs. using the unit initialization and finalization
sections don't run. But, is useful for IFDEF sets.

I've never had to use:
{$Align}, {$Stackchecks}, {$M}, {$R}, {$REALCOMPATIBILITY}, {$U} or
{$Y}

I think are dangerous to use at all:
{$BoolEval On} {$Warnings Off}


--
Deepak Shenoy (TeamB)
shenoyatwork.blogspot.com
 

Re:Compiler directives

Joseph Mele wrote:
Quote
forgot

{$E fmx}

Which I just recently used for the FIRST time. I wrote a Delphi SDK
for Filemaker plugins.
Ah yes, of course, also useful for some plugin architectures.
Also had missed {$R file.res} for including a resource file. Useful
when you use external resource files.
--
Deepak Shenoy (TeamB)
shenoyatwork.blogspot.com