Guru question:
On a couple of occasions when compiling a source package I've had errors such as that below. The common factor appears to be the "error: `__ASSERT_FUNCTION' undeclared". Have I got something set up wrong in my system?
-- GT
------------------------------------------------------------------------------------------------- make all-am make[1]: Entering directory `/home/graham/Documents/dvgrab-1.2' source='avi.cc' object='avi.o' libtool=no \ depfile='.deps/avi.Po' tmpdepfile='.deps/avi.TPo' \ depmode=gcc3 /bin/sh ./depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I. -D_FILE_OFFSET_BITS=64 -Wno-deprecated -O2 -Wall -D_REENTRANT -c -o avi.o `test -f 'avi.cc' || echo './'`avi.cc avi.cc: In member function `virtual void AVIFile::Init(int, int, int)': avi.cc:285: error: `assert' undeclared (first use this function) avi.cc:285: error: (Each undeclared identifier is reported only once for each function it appears in.) avi.cc: In member function `virtual int AVIFile::GetDVFrameInfo(off_t&, int&, int)': avi.cc:388: error: `__ASSERT_FUNCTION' undeclared (first use this function) avi.cc: In member function `virtual void AVI1File::Init(int, int, int)': avi.cc:951: error: `assert' undeclared (first use this function) avi.cc: In member function `virtual void AVI2File::Init(int, int, int)': avi.cc:1240: error: `assert' undeclared (first use this function) make[1]: *** [avi.o] Error 1 make[1]: Leaving directory `/home/graham/Documents/dvgrab-1.2' make: *** [all] Error 2 -------------------------------------------------------------------------------------------------
Non-guru answering...
assert is a debugging macro that shouldn't be left in production code - It produces error messages that worry and/or confuse the end users. Either add the line: #include <cassert> to each file affected, or compile with NDEBUG defined.
Regards, Paul.
On Thursday 27 November 2003 10:48 am, Graham Trott wrote:
avi.cc:285: error: `assert' undeclared (first use this function) avi.cc:285: error: (Each undeclared identifier is reported only once for each function it appears in.)
On Thu, 2003-11-27 at 17:51, Paul wrote:
assert is a debugging macro that shouldn't be left in production code - It produces error messages that worry and/or confuse the end users. Either add the line: #include <cassert> to each file affected, or compile with NDEBUG defined.
Having asserts in production code is actually very useful. It means that if your testing isn't thorough enough, you can get some useful information out of a crash in production.
D.
On Thursday 27 Nov 2003 6:05 pm, Daniel Silverstone wrote:
On Thu, 2003-11-27 at 17:51, Paul wrote:
assert is a debugging macro that shouldn't be left in production code - It produces error messages that worry and/or confuse the end users. Either add the line: #include <cassert> to each file affected, or compile with NDEBUG defined.
Having asserts in production code is actually very useful. It means that if your testing isn't thorough enough, you can get some useful information out of a crash in production.
D.
IIRC gtk+ uses assertion all the time in its production code, particualrly to check variables are valid and they are an excellent debugging tool for anyone using gtk+.
Ian
On Thursday 27 November 2003 19:50, IanBell wrote:
IIRC gtk+ uses assertion all the time in its production code, particualrly to check variables are valid and they are an excellent debugging tool for anyone using gtk+.
Ian
Which is fine except that with source tarballs the idea is they should compile, not require Joe User to take a 3-year C course to figure out the problem. I'll try the <cassert> option tomorrow; NDEBUG means wading through configuration files.
-- G
On Thu, 2003-11-27 at 20:55, Graham Trott wrote:
Which is fine except that with source tarballs the idea is they should compile, not require Joe User to take a 3-year C course to figure out the problem. I'll try the <cassert> option tomorrow; NDEBUG means wading through configuration files.
Your issue is that the source code you downloaded is buggy, not that is includes asserts in production code.
:-)
D.
On Thursday 27 November 2003 23:57, Daniel Silverstone wrote:
On Thu, 2003-11-27 at 20:55, Graham Trott wrote:
Which is fine except that with source tarballs the idea is they should compile, not require Joe User to take a 3-year C course to figure out the problem. I'll try the <cassert> option tomorrow; NDEBUG means wading through configuration files.
Your issue is that the source code you downloaded is buggy, not that is includes asserts in production code.
:-)
D.
Damn right. How DARE they put out buggy code. I'd never do such a thing, of course.
-- GT
On Thursday 27 Nov 2003 8:55 pm, Graham Trott wrote:
On Thursday 27 November 2003 19:50, IanBell wrote:
IIRC gtk+ uses assertion all the time in its production code, particualrly to check variables are valid and they are an excellent debugging tool for anyone using gtk+.
Ian
Which is fine except that with source tarballs the idea is they should compile, not require Joe User to take a 3-year C course to figure out the problem. I'll try the <cassert> option tomorrow; NDEBUG means wading through configuration files.
-- G
I can understand that but gtk+ is an application development library rather than an app in itself so it is important for an app developer to know when he is using the library wrongly.
Ian
-
Daniel Silverstone -
Graham Trott -
IanBell -
Paul