Thread overview | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
March 13, 2003 Compiling problem: Tricky macro & struct usage | ||||
---|---|---|---|---|
| ||||
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 |
March 13, 2003 Re: Compiling problem: Tricky macro & struct usage | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert M. Münch | 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 |
March 13, 2003 Re: Compiling problem: Tricky macro & struct usage | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 |
March 13, 2003 Re: Compiling problem: Tricky macro & struct usage | ||||
---|---|---|---|---|
| ||||
Posted in reply to Richard Grant | "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. |
March 14, 2003 Re: Compiling problem: Tricky macro & struct usage | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 |
March 18, 2003 Re: Compiling problem: Tricky macro & struct usage | ||||
---|---|---|---|---|
| ||||
Posted in reply to Richard Grant | "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? |
March 18, 2003 Re: Compiling problem: Tricky macro & struct usage | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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? |
March 28, 2003 Re: Compiling problem: Tricky macro & struct usage | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christof Meerwald | 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 |
March 29, 2003 Re: Compiling problem: Tricky macro & struct usage | ||||
---|---|---|---|---|
| ||||
Posted in reply to Richard Grant | 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? |
March 29, 2003 Re: Compiling problem: Tricky macro & struct usage | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christof Meerwald | 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:
|
Copyright © 1999-2021 by the D Language Foundation