freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Frediano Ziglio <freddyz77 AT tin.it>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: RE: [freetds] tdoParseConnectString
- Date: 03 Apr 2003 22:13:40 +0200
>
> > Personally I don't like assert that much.
>
> Why?
>
My background is DOS (not DoS :) ), Windows, Linux ... for O/S and
BASIC, Pascal, ASM, (C), C++ ... for language. I like performance and I
prefer the use of assert in DOS/Windows. In DOS/Windows assert are
disabled by default while in many Unix programs assert are enabled by
default.
This is why I don't like assert that much.
> > It should be removed from final
> > compile. I think we should define another macro based on
> > --enable-extra-checks instead of enabling always assert...
>
> The assert() macro *is* removed in the "final" compile, if NDEBUG is
> defined, at least on my system.
>
> Assert is your friend. It provides information that segment faults don't.
> It's a strong comment in the code about the programmer's assumptions. It
> avoids the need to backtrack a runtime fault stemming from a bad assumption.
>
When I write programs sometimes I fill them of assert (one of my program
is 4 time slower compiled with assert enabled...).
Also I saw assert code like
char *p = (char*)malloc(10);
assert(p);
(good for practice but not for real programs...)
In another program I defined two macro:
PRG_ASSERT and COMPILE_CHECK. I use my PRG_ASSERT instead of assert
cause PRG_ASSERT is disabled by default. COMPILE_CHECK is a macro to do
tests are compile time... if you think is useful for FreeTDS here you
are:
#if defined(__GNUC__) && __GNUC__ >= 2
#define COMPILE_CHECK(name,check) \
extern int name[(check)?1:-1] __attribute__ ((unused))
#else
#define COMPILE_CHECK(name,check) \
extern int name[(check)?1:-1]
#endif
freddy77
-
[freetds] tdoParseConnectString,
Lowden, James K, 04/03/2003
- <Possible follow-up(s)>
- RE: [freetds] tdoParseConnectString, ZIGLIO Frediano, 04/03/2003
-
RE: [freetds] tdoParseConnectString,
Lowden, James K, 04/03/2003
- RE: [freetds] tdoParseConnectString, Frediano Ziglio, 04/03/2003
- RE: [freetds] tdoParseConnectString, Frediano Ziglio, 04/03/2003
-
RE: [freetds] tdoParseConnectString,
Lowden, James K, 04/03/2003
- RE: [freetds] tdoParseConnectString, Michael Peppler, 04/03/2003
- RE: [freetds] tdoParseConnectString, Lowden, James K, 04/03/2003
Archive powered by MHonArc 2.6.24.