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