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

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

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

"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.

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

"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?

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?

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

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?

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: