www.digitalmars.com         C & C++   DMDScript  

c++.beta - Compiling problem: Tricky macro & struct usage

reply =?iso-8859-15?Q?=22Robert_M._M=FCnch=22?= <robert.muench robertmuench.de> writes:
Hi, I have some defines like this:

#define	SH_TAILQ_FIRSTP(head, type)					\
	((struct type *)((u_int8_t *)(head) + (head)->stqh_first))

#define	SH_TAILQ_FIRST(head, type)					\
	((head)->stqh_first == -1 ? NULL : SH_TAILQ_FIRSTP(head, type))

And code that uses this like this:

	/* Reset the hash bucket's priority. */
	hp->hash_priority = SH_TAILQ_FIRST(&hp->hash_bucket, __bh)->priority;

And get an error like this:

..\mp\mp_alloc.c(362) : Error: not a struct or union type
        hp->hash_priority = SH_TAILQ_FIRST(&hp->hash_bucket, __bh)- 
priority;
^ Shouldn't this work? -- Robert M. Münch
Mar 13 2003
parent reply "Walter" <walter digitalmars.com> writes:
Try compiling with -e -l, then look at the resulting .lst file to see how
the macros expanded.

"Robert M. Münch" <robert.muench robertmuench.de> wrote in message
news:oprlznhgpgr6w2gz news.digitalmars.com...
 Hi, I have some defines like this:

 #define SH_TAILQ_FIRSTP(head, type) \
 ((struct type *)((u_int8_t *)(head) + (head)->stqh_first))

 #define SH_TAILQ_FIRST(head, type) \
 ((head)->stqh_first == -1 ? NULL : SH_TAILQ_FIRSTP(head, type))

 And code that uses this like this:

 /* Reset the hash bucket's priority. */
 hp->hash_priority = SH_TAILQ_FIRST(&hp->hash_bucket, __bh)->priority;

 And get an error like this:

 ..\mp\mp_alloc.c(362) : Error: not a struct or union type
         hp->hash_priority = SH_TAILQ_FIRST(&hp->hash_bucket, __bh)-
priority;
^ Shouldn't this work? -- Robert M. Münch
Mar 13 2003
parent reply Richard Grant <fractal clark.net> writes:
In article <b4qrsa$18sk$1 digitaldaemon.com>, Walter says...
Try compiling with -e -l, then look at the resulting .lst file to see how
the macros expanded.
The -e and -l produce a .lst file, but it is usually truncated. In the case of stlport and boost, the .lst file never containes useful information for diagnostic. I presume that in the case of a short include there would be useful information. Richard
Mar 13 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Richard Grant" <fractal clark.net> wrote in message
news:b4qutj$1b8n$1 digitaldaemon.com...
 In article <b4qrsa$18sk$1 digitaldaemon.com>, Walter says...
Try compiling with -e -l, then look at the resulting .lst file to see how
the macros expanded.
The -e and -l produce a .lst file, but it is usually truncated. In the
case of
 stlport and boost, the .lst file never containes useful information for
 diagnostic. I presume that in the case of a short include there would be
useful
 information.
The .lst file, even if truncated, shows the text presented to the compiler after all macros have been expanded. It's usually a lot easier to figure out what went wrong with that.
Mar 13 2003
parent reply Richard Grant <fractal clark.net> writes:
In article <b4r16l$1d4h$1 digitaldaemon.com>, Walter says...

The .lst file, even if truncated, shows the text presented to the compiler
after all macros have been expanded. It's usually a lot easier to figure out
what went wrong with that.
Yes, and I am not suggesting the feature is not useful. I'm actually fishing for a fix that doesn't result in truncated files as it makes things much harder to figure out. I would expect that a simple include of a smaller boost lib would result in some 200K .lst output. I am getting around 60K. And this 60K is always STL initialization, and one of the boost config headers. For example, there is currently a problem with the preprocessor lambda lib, and finding a test case without -e means that I am hand coding the expansions. It gets very complex in the boost preprocessor area, and arbitrary functors are complex enough without the preprocessor. If -e and -l didn't result in truncated lst files, I would already have a test case for the lambda problem. Richard
Mar 14 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Richard Grant" <fractal clark.net> wrote in message
news:b4stji$gbv$1 digitaldaemon.com...
 In article <b4r16l$1d4h$1 digitaldaemon.com>, Walter says...

The .lst file, even if truncated, shows the text presented to the
compiler
after all macros have been expanded. It's usually a lot easier to figure
out
what went wrong with that.
Yes, and I am not suggesting the feature is not useful. I'm actually
fishing for
 a fix that doesn't result in truncated files as it makes things much
harder to
 figure out. I would expect that a simple include of a smaller boost lib
would
 result in some 200K .lst output. I am getting around 60K. And this 60K is
always
 STL initialization, and one of the boost config headers.

 For example, there is currently a problem with the preprocessor lambda
lib, and
 finding a test case without -e means that I am hand coding the expansions.
It
 gets very complex in the boost preprocessor area, and arbitrary functors
are
 complex enough without the preprocessor. If -e and -l didn't result in
truncated
 lst files, I would already have a test case for the lambda problem.
If it's truncated, the problem line is likely the last one. How does it look?
Mar 17 2003
parent reply Christof Meerwald <cmeerw web.de> writes:
On Mon, 17 Mar 2003 16:10:10 -0800, Walter wrote:
 "Richard Grant" <fractal clark.net> wrote in message
 news:b4stji$gbv$1 digitaldaemon.com...
 figure out. I would expect that a simple include of a smaller boost lib
would
 result in some 200K .lst output. I am getting around 60K. And this 60K is
always
 STL initialization, and one of the boost config headers.
[...]
 If it's truncated, the problem line is likely the last one. How does it
 look?
No, AFAIK even simple programs that use STLport and compile fine produce truncated .lst-files. Please try to generate a .lst-file of something like: #include <iostream> int main() { std::cout << "Hello world" << std::endl; return 0; } I don't know what's causing the problem, but AFAIK the problem was introduced by the preprocessor rewrite. bye, Christof -- http://cmeerw.org JID: cmeerw jabber.at mailto cmeerw at web.de ...and what have you contributed to the Net?
Mar 18 2003
parent reply Richard Grant <fractal clark.net> writes:
In article <b57lv6$10ul$1 digitaldaemon.com>, Christof Meerwald says...

No, AFAIK even simple programs that use STLport and compile fine produce
truncated .lst-files. Please try to generate a .lst-file of something like:
Walter, there is a problem with the boost 1_30_0 preprocessor repetition lib. This is almost impossible to track down without proper "-e -l" support in DM. Richard
Mar 28 2003
parent reply Christof Meerwald <cmeerw web.de> writes:
On Fri, 28 Mar 2003 09:42:53 +0000 (UTC), Richard Grant wrote:
 In article <b57lv6$10ul$1 digitaldaemon.com>, Christof Meerwald says...
No, AFAIK even simple programs that use STLport and compile fine produce
truncated .lst-files. Please try to generate a .lst-file of something like:
Walter, there is a problem with the boost 1_30_0 preprocessor repetition lib. This is almost impossible to track down without proper "-e -l" support in DM.
Here is a simple test-case: #define MY_HEADER(header) <header> #if 0 #include MY_HEADER(stdio.h) #endif int main() { } and the generated .lst-file (-e -l) is truncated: extern "C++" { void * __cdecl operator new[](unsigned),__cdecl operator delete[](void *); } struct __nt_context { int esp; int info; int prev; int handler; int stable; int sindex; int ebp; }; extern "C++"{ void * __cdecl operator new(unsigned), __cdecl operator delete(void *),* __cdecl __vec_new(void *,unsigned,int,void *(__pascal *)(void),int (__pascal *)(void)),* __cdecl __vec_ctor(void *,unsigned,int,void *(__pascal *)(void),int (__pascal *)(void)),* __cdecl __vec_cpct(void *,unsigned,int,void *(__pascal *)(void),int (__pascal *)(void),void *),__cdecl __vec_delete(void *,int,unsigned,int (__pascal *)(void)), __cdecl __vec_dtor(void *,unsigned,int,int (__pascal*)(void)), __cdecl __vec_invariant(void *,unsigned,int,int (__pascal*)(void)), __cdecl __eh_throw(const char *,int(__pascal*)(),unsigned,...), __cdecl __eh_rethrow(void);extern void * (__cdecl * __eh_newp)(unsigned);typedef int (*__mptr)();struct __eh_cv { volatile void *p; ~__eh_cv(); };void * __cdecl __rtti_cast(void *,void *,const char *,const char *,int);} extern "C" { int __cdecl _fatexit(void(__cdecl *)());} #define MY_HEADER(header) <header> #if 0 bye, Christof -- http://cmeerw.org JID: cmeerw jabber.at mailto cmeerw at web.de ...and what have you contributed to the Net?
Mar 29 2003
parent "Walter" <walter digitalmars.com> writes:
Thanks! This saves me a lot of work. -Walter

"Christof Meerwald" <cmeerw web.de> wrote in message news:b646f9
 Here is a simple test-case:
Mar 29 2003