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

 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

 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


after all macros have been expanded. It's usually a lot easier to figure


what went wrong with that.

Yes, and I am not suggesting the feature is not useful. I'm actually

 a fix that doesn't result in truncated files as it makes things much

 figure out. I would expect that a simple include of a smaller boost lib

 result in some 200K .lst output. I am getting around 60K. And this 60K is

 STL initialization, and one of the boost config headers.

 For example, there is currently a problem with the preprocessor lambda

 finding a test case without -e means that I am hand coding the expansions.

 gets very complex in the boost preprocessor area, and arbitrary functors

 complex enough without the preprocessor. If -e and -l didn't result in

 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

 result in some 200K .lst output. I am getting around 60K. And this 60K is

 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:

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