Lukas,
>> I just explain, why I not see a tons of warnings...
Yup. I got that. Very clearly and very easily. Right away. But I completely
disagree with your reasoning, and so do some very famous and very popular
other libraries. In fact, it's such a common technique that I was quite
surprised that Synapse isn't using it!
I already worked around it, but maybe it's worth a little exploration.
Because by using compiler directives, you can ensure that "It Just Works"
*for everyone* with no effort (no changes necessary on their part whether
they're compiling from the IDE or the command line! "almost like magic" <g>,
or automation), AND you can reliably control the "environment" for your code
running on other systems--and thus make it look better too (hundreds of
warnings don't show up--that's enough to scare some new users away
immediately, especially when most developers won't have configured their
environments exactly like you do). And: Nobody ever _wants_ to see such
warnings from an external, thirdparty lib, whether commercial or open
source. If the developers know it's proper, it's far better to _reliably_
quiet the noisy warning messages.
I am not trying to change your mind, just outlining what seems to be the
general consensus (from experience with quite a few libs over quite a few
years). Actually, never mind that(!), this IS worth trying to change your
mind about. It's a much better, and well-established solution (available
with some variations <g>). Well... one way or the other, I'll present what
I think is a very compelling argument FOR using the $WARN compiler
directives in particular, and especially from within a carefull crafted
INCLUDE file (with other directives) which yields even more benefits:
>> I never want this kind of warning, because are useless.
EXACTLY. That's exactly why so many libraries hide/eliminate the warnings.
Some of them have INCLUDE files that do nothing else! (You might very well
already have those files on your systems! Such as DirectX.inc which includes
the Jedi.inc and then just turns off those warnings for every compiler from
D7 up.) And by doing this, they are actually ENABLING those developers who
want to control the visibility of warnings (either ON or OFF) to do so.
Whereas by NOT hiding them, Synapse forces its users to explicitly handle
the problem otherwise. Probably globally. Exactly the opposite of your
stated goal.
And for those who use both the IDE and the command line compilers, they have
to accommodate this in different ways.
The Synapse Library is used in all sorts of situations, including by those
who value $WARN compiler directives, and those who do not want to see
(useless!) warnings COMING FROM WITHIN a library into which most developers
won't venture. Most will want the library to function as a "black box," and
not make unnecessary noise or cause extra work (potentially different work
for different projects). We all KNOW that the Synapse lib works perfectly
well under D7, but in its default configuration, and probably the way most
developers have their IDE set up... it'll complain with HUNDREDS of USELESS
warnings, which while annoying in themselves, can serve to hide other
VALUABLE warnings.
>> Tun off this warnings by directives is not easy, because directives
>> must be used for some platforms only.
Yes, it is easy, and lots of projects and libraries do it; which even
provides lots of examples for how to do it. AND BEYOND THIS BENEFIT, using
such include files makes it easy to globally set other options, ALSO
depending on a conditional compiler directive so that you can have far
better debugging efforts (such as turning Range Checking and Overflowchecks
on--can be wonderful!), but have much better performance for production code
(Range Checking OFF!).
A quick example:
{$IFDEF DEBUGGING}
{$ASSERTIONS ON}
{$DEBUGINFO ON}
{$OVERFLOWCHECKS ON}
{$RANGECHECKS ON}
{$WARNINGS ON}
{$HINTS ON}
{$ELSE}
{$ASSERTIONS OFF}
{$DEBUGINFO OFF}
{$OVERFLOWCHECKS OFF}
{$RANGECHECKS OFF}
{$WARNINGS OFF}
{$HINTS OFF} and maybe Stack Frames... etc...
{$ENDIF}
NOTE: Using compiler directives this way is FAR more powerful than the
global settings. For example, somewhat like the UNSAFE warnings, it is quite
often COUNTER-productive to turn Overflow Checks on (like in some crypto
libs). You can still control them in this default manner (as above) and yet
*override* this in one's own code by explicitly placing the appropriate
directives. (Sometimes just bracketing a single routine with
{$OVERFLOWCHECKS OFF} ... ... ... {$OVERFLOWCHECKS ON} ... )
Remember that $WARN is also a LOCAL Switch type compiler directive which
means you can turn it on and off (repeatedly) within a single unit. AND even
the "global" type switch compiler directives only have scope as far as the
UNIT anyway. That's one of the major reasons we use INCLUDE files into each
unit...
Googling for search terms like "WARN UNSAFE_TYPE UNSAFE_CODE UNSAFE_CAST"
yields some examples (some more elegant than others). But one can also look
directly at popular libraries like Jedi (jcl.inc -- which disables the
warnings, depending on the compiler identity established in jedi.inc), the
OpenXML library's cDefines.inc (nice, clean, simple, with debug support, and
UNSAFE warnings disabled), and for a commercial example, the
DevelopersExpress cxVer.inc is pretty comprehensive, and disables those
warnings. A search of one computer's drives here comes up with plenty more
examples. (Like Dave Baldwin's THMTL and other packages (htmlcons.inc) which
were commercial, and now open source...) It's almost a necessity.
>> However question is - if someone really want this warings, will be
>> happy if these warnings will be hidden in thirdparty code? I don't
>> think so. ;-)
Nobody will want these warnings from a library they aren't developing in.
They DO want those warnings to be hidden in 3rd party code, AS LONG AS that
code is properly managing the appropriate issues.
Using in-code compiler directives gives developers considerably MORE
freedom, since not using them requires editing the library code, or setting
global defaults (FOR EVERYTHING).
I can easily live with this either way, but there are such great benefits to
quieting the appropriate compilers, and customizing other settings, that you
might want to reconsider your position on this.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
synalist-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synalist-public
