Re: how come #include "*.cpp" works?

Re: how come #include "*.cpp" works?

[mwoehlke]

Larry Hall (Cygwin) wrote:
> This isn't a Cygwin specific problem so it's off-topic for this list.
> Please find a better forum for such questions.  If you feel you must
> continue this discussion with a Cygwin crowd, then you can try the
> cygwin-talk list.

On that note, does anyone know of a good C++ forum? I have an 
interesting problem I'd like to see if anyone has any clever solutions for.

-- 
Matthew
If you can drive a cart and horses through, will a hippo fit?

RE: how come #include "*.cpp" works?

[Dave Korn]

On 17 May 2006 16:43, mwoehlke wrote:

> Larry Hall (Cygwin) wrote:
>> This isn't a Cygwin specific problem so it's off-topic for this list.
>> Please find a better forum for such questions.  If you feel you must
>> continue this discussion with a Cygwin crowd, then you can try the
>> cygwin-talk list.
> 
> On that note, does anyone know of a good C++ forum? I have an
> interesting problem I'd like to see if anyone has any clever solutions for.

  You've piqued my curiousity now.  Go on then, what's the C++ problem?  (And
for 5 bonus points for topicality, how can it be related to hippos?)

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: how come #include "*.cpp" works?

[Igor Peshansky]

On Wed, 17 May 2006, Dave Korn wrote:

> On 17 May 2006 16:43, mwoehlke wrote:
>
> > Larry Hall (Cygwin) wrote:
> >> This isn't a Cygwin specific problem so it's off-topic for this list.
> >> Please find a better forum for such questions.  If you feel you must
> >> continue this discussion with a Cygwin crowd, then you can try the
> >> cygwin-talk list.
> >
> > On that note, does anyone know of a good C++ forum? I have an
> > interesting problem I'd like to see if anyone has any clever solutions
> > for.
>
>   You've piqued my curiousity now.  Go on then, what's the C++ problem?

Ditto.

> (And for 5 bonus points for topicality, how can it be related to
> hippos?)

Heh?  C++ has always been related to hippos.  What do you think the .hpp
extension stands for?
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

RE: how come #include "*.cpp" works?

[Dave Korn]

On 17 May 2006 17:28, Igor Peshansky wrote:

> On Wed, 17 May 2006, Dave Korn wrote:
> 
>> On 17 May 2006 16:43, mwoehlke wrote:
>> 
>>> Larry Hall (Cygwin) wrote:
>>>> This isn't a Cygwin specific problem so it's off-topic for this list.
>>>> Please find a better forum for such questions.  If you feel you must
>>>> continue this discussion with a Cygwin crowd, then you can try the
>>>> cygwin-talk list.
>>> 
>>> On that note, does anyone know of a good C++ forum? I have an
>>> interesting problem I'd like to see if anyone has any clever solutions
>>> for.
>> 
>>   You've piqued my curiousity now.  Go on then, what's the C++ problem?
> 
> Ditto.
> 
>> (And for 5 bonus points for topicality, how can it be related to
>> hippos?)
> 
> Heh?  C++ has always been related to hippos.  What do you think the .hpp
> extension stands for?


  Oh wow, that's for 'hippo' is it?  I always thought it stood for
<penelopepitstop> Haaayyy-ulppp! </penelope>


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: how come #include "*.cpp" works?

[mwoehlke]

Dave Korn wrote:
> On 17 May 2006 16:43, mwoehlke wrote:
>> On that note, does anyone know of a good C++ forum? I have an
>> interesting problem I'd like to see if anyone has any clever solutions for.
> 
>   You've piqued my curiousity now.  Go on then, what's the C++ problem?  (And
> for 5 bonus points for topicality, how can it be related to hippos?)

Hehe, ok... but I think I figured out a good way to solve the problem 
already :-).

I'm writing a program to dump structures from core dumps generated from 
symbol-less binaries (i.e. no easy looking at structures, etc, in gdb). 
It works great; you give it a structure name and an address and it 
reads, decodes, and prints the structure, as well as referenced objects 
like strings (the idea being to dump whole hierarchies of structures at 
once).

Anyway... what I do is have an "OBJ" ABC and subclass it for each type 
of structure I want this program to be able to understand. What I want 
to do is have some system that entails the fewest *lines* of code 
(macros to turn one line into lots of *actual* code are OK) that can a: 
construct an object by name, and b: provide me a list of names of 
classes which can be created (i.e. if you enter an invalid one, it will 
tell you valid ones). Any thoughts? (Maybe dropping a hippo on the code 
will make it as small as I want it to be? ;-))

-- 
Matthew
Hey, buddy, if it's OT, TITTTL!

Re: how come #include "*.cpp" works?

[Jason Alonso]

On 5/18/06, mwoehlke wrote:
> tell you valid ones). Any thoughts? (Maybe dropping a hippo on the code
> will make it as small as I want it to be? ;-))

// oppi.h
#define HIPPO_DROP int main() { \
   ... \
   }

// code.c
#include "oppi.h"

HIPPO_DROP


Remember, you must include the hippo before you can drop it on your code.  ;-)

Jason

RE: how come #include "*.cpp" works?

[Dave Korn]

On 18 May 2006 15:45, mwoehlke wrote:

> Anyway... what I do is have an "OBJ" ABC and subclass it for each type
> of structure I want this program to be able to understand. What I want
> to do is have some system that entails the fewest *lines* of code
> (macros to turn one line into lots of *actual* code are OK) that can a:
> construct an object by name, and b: provide me a list of names of
> classes which can be created (i.e. if you enter an invalid one, it will
> tell you valid ones). Any thoughts? (Maybe dropping a hippo on the code
> will make it as small as I want it to be? ;-))

  Something like this?

subclasses.def:
---------------

SUBCLASS (class1_name,
	void class1_func1 (int args, ... ); \
	int class1_func2 (int args, ... ); \
           .... \
       private: \
       int m_foo; \
)

SUBCLASS (class2_name,
	void class2_func1 (int args, ... ); \
	int class2_func2 (int args, ... ); \
           .... \
       private: \
       void *m_foo; \
)

subclass_list.cpp
-----------------

#define SUBCLASS (A, B) { ## A , gen_ # A }

struct subclassdata {
	const char *name;
	ABC * (*gen_func)();
};

const struct subclassdata subclasslist[] = {
#include "subclasses.def"
};

#undef SUBCLASS
#define SUBCLASS (A, B) \
ABC *gen_ # A () \
{ \
	return new A; \
};

#include "subclasses.def"


subclass_defns.h
----------------

#undef SUBCLASS
#define SUBCLASS (A, B) \
class A : public ABC { \
B \
};



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: how come #include "*.cpp" works?

[mwoehlke]

Dave Korn wrote:
> On 18 May 2006 15:45, mwoehlke wrote:
> 
>> Anyway... what I do is have an "OBJ" ABC and subclass it for each type
>> of structure I want this program to be able to understand. What I want
>> to do is have some system that entails the fewest *lines* of code
>> (macros to turn one line into lots of *actual* code are OK) that can a:
>> construct an object by name, and b: provide me a list of names of
>> classes which can be created (i.e. if you enter an invalid one, it will
>> tell you valid ones). Any thoughts? (Maybe dropping a hippo on the code
>> will make it as small as I want it to be? ;-))
> 
>   Something like this?
(moved below)

Hey, that's pretty slick... thanks!

Upon further thought, I may actually do something with my Makefile and 
auto-generation of some file, but I think I'm still going to use part of 
this. (Having an entire class declaration inside of a macro kind-of rubs 
me wrong ;-). Also, I want to keep each class in its own header.)

-- 
Matthew
Hey, buddy, if it's OT, TITTTL!

--
> subclasses.def:
> ---------------
> 
> SUBCLASS (class1_name,
> 	void class1_func1 (int args, ... ); \
> 	int class1_func2 (int args, ... ); \
>            .... \
>        private: \
>        int m_foo; \
> )
> 
> SUBCLASS (class2_name,
> 	void class2_func1 (int args, ... ); \
> 	int class2_func2 (int args, ... ); \
>            .... \
>        private: \
>        void *m_foo; \
> )
> 
> subclass_list.cpp
> -----------------
> 
> #define SUBCLASS (A, B) { ## A , gen_ # A }
> 
> struct subclassdata {
> 	const char *name;
> 	ABC * (*gen_func)();
> };
> 
> const struct subclassdata subclasslist[] = {
> #include "subclasses.def"
> };
> 
> #undef SUBCLASS
> #define SUBCLASS (A, B) \
> ABC *gen_ # A () \
> { \
> 	return new A; \
> };
> 
> #include "subclasses.def"
> 
> 
> subclass_defns.h
> ----------------
> 
> #undef SUBCLASS
> #define SUBCLASS (A, B) \
> class A : public ABC { \
> B \
> };

RE: how come #include "*.cpp" works?

[Dave Korn]

On 18 May 2006 19:28, mwoehlke wrote:


>>   Something like this?
> (moved below)
> 
> Hey, that's pretty slick... thanks!

  :)  It's a fairly standard technique.  The particularly good thing about it
is that there's no danger of anything getting out-of-sync because it all comes
from one source and hence has to remain consistent.  Gcc and other big
highly-configurable projects do this all the time, and even more advanced
stuff.

> Upon further thought, I may actually do something with my Makefile and
> auto-generation of some file, but I think I'm still going to use part of
> this. (Having an entire class declaration inside of a macro kind-of rubs
> me wrong ;-). Also, I want to keep each class in its own header.)

  Yep, it's certainly a little ugly, but it serves to illustrate the
technique; feel free to adapt and mutate to best serve your own purposes!


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: how come #include "*.cpp" works?

[mwoehlke]

Dave Korn wrote:
> On 18 May 2006 19:28, mwoehlke wrote:
>>>   Something like this?
>> (moved below)
>>
>> Hey, that's pretty slick... thanks!
> 
>   :)  It's a fairly standard technique.

Right, I *was* pretty sure I was trying to re-invent the wheel, which is 
why I asked ;-).

>> Upon further thought, I may actually do something with my Makefile and
>> auto-generation of some file, but I think I'm still going to use part of
>> this. (Having an entire class declaration inside of a macro kind-of rubs
>> me wrong ;-). Also, I want to keep each class in its own header.)
> 
>   Yep, it's certainly a little ugly, but it serves to illustrate the
> technique; feel free to adapt and mutate to best serve your own purposes!

Thanks again!

-- 
Matthew
Hey, buddy, if it's OT, TITTTL!

Re: how come #include "*.cpp" works?

[mwoehlke]

mwoehlke wrote:
> I'm writing a program to dump structures from core dumps generated from 
> symbol-less binaries (i.e. no easy looking at structures, etc, in gdb). 
> It works great; you give it a structure name and an address and it 
> reads, decodes, and prints the structure, as well as referenced objects 
> like strings (the idea being to dump whole hierarchies of structures at 
> once).
> 
> Anyway... what I do is have an "OBJ" ABC and subclass it for each type 
> of structure I want this program to be able to understand. What I want 
> to do is have some system that entails the fewest *lines* of code 
> (macros to turn one line into lots of *actual* code are OK) that can a: 
> construct an object by name, and b: provide me a list of names of 
> classes which can be created (i.e. if you enter an invalid one, it will 
> tell you valid ones). Any thoughts? (Maybe dropping a hippo on the code 
> will make it as small as I want it to be? ;-))

Below is what I ultimately wound up using. Thanks again to Dave Korn for 
the assistance in coming up with this solution!

The final requirements for this solution are:
1: An updated list of class headers in Makefile.
2: Classes must be declared with 'CREATABLE_CLASS(name)' instead of 
'class name : virtual public OBJECT'.
3: A create_<name> function must be written. If all objects were 
constructed the same, this could have been lumped into the declaration 
CREATABLE_CLASS macro, however not all constructors take the same 
arguments, which is why 'create_<name>' takes an argc/argv pair. IOW 
this requirement cannot be eliminated.

The list-in-code (including pointers to create functions) is maintained 
via (1), which is the only "overhead" other than (3) and the actual 
class declaration... and if I really wanted to, I could get rid of this 
as well (but to be worth it, I would want/need a way to determine what 
files are actually used to build the executable, and I think this is one 
case where I /prefer/ to update the list by hand).

Thus, except for Makefile, it achieves the objective of having a list 
which is entirely generated and does not need to be maintained by hand.


=== For declaring an object
#define CREATABLE_CLASS(name) \
extern class OBJECT* create_##name( int argc, const char* argv[] ); \
class name : virtual public OBJECT

=== Example declaration
CREATABLE_CLASS( STRING )
{
     public:
         STRING( long ptr, long lim = MAX_STR );
         virtual ~STRING();
         ...

     protected:
         char* _data;
};

=== For creating object.def (in Makefile)
objects.def : $(classes)
	cat $(classes) | grep CREATABLE_CLASS > $@

(This requires '$(classes)' to be kept up to date, but that's OK because 
'$(classes)' becomes part of '$(objects)', which defines the 
prerequisites for the executable - i.e. this isn't really adding any 
work, although I suppose I could go one step further and generate the 
object prerequisites as well; this would certainly be do-able)


=== So main.cpp doesn't need the headers for every class
#undef CREATABLE_CLASS
#define CREATABLE_CLASS(name) \
extern class T_OBJ* create_##name( int argc, const char* argv[] );
#include "objects.def"

=== And finally for the list
#undef CREATABLE_CLASS
#define CREATABLE_CLASS(name) { #name, create_##name },

typedef OBJECT *(*OBJ_CREATOR)( int argc, const char* argv[] );
typedef struct {
     const char* name;
     OBJ_CREATOR create;
} OBJECT_LIST_ENTRY;

OBJECT_LIST_ENTRY createable_object[] = {
#include "objects.def"
{ NULL, NULL }
};

(The last '{ NULL, NULL }' entry is needed to have something after the 
comma that the macro generates.)

-- 
Matthew
Doom doom dooM doo-DooM dOOm DOom doOM... DOOM! -- Gir

RE: how come #include "*.cpp" works?

[Dave Korn]

On 24 May 2006 17:00, mwoehlke wrote:

> 3: A create_<name> function must be written. If all objects were
> constructed the same, this could have been lumped into the declaration
> CREATABLE_CLASS macro, however not all constructors take the same
> arguments, which is why 'create_<name>' takes an argc/argv pair. IOW
> this requirement cannot be eliminated.

  Are you sure this can't be worked around using varargs macros?

#define CREATABLE_CLASS(name, ...) \
  extern class OBJECT* create_##name( __VA_ARGS__ ); \

> Thus, except for Makefile, it achieves the objective of having a list
> which is entirely generated and does not need to be maintained by hand.

> === For declaring an object
> #define CREATABLE_CLASS(name) \
> extern class OBJECT* create_##name( int argc, const char* argv[] ); \
> class name : virtual public OBJECT

> === So main.cpp doesn't need the headers for every class
> #undef CREATABLE_CLASS
> #define CREATABLE_CLASS(name) \
> extern class T_OBJ* create_##name( int argc, const char* argv[] );
> #include "objects.def"

  Bad idea, I think.  You now have two separate bits of code that are
generating the prototypes for this set of functions.  You run the danger of
getting inconsistent code.  In this case, unless T_OBJ is the exact same type
as OBJECT, you've already made (technically speaking) undefined behaviour,
haven't you?  Umm, perhaps I mean "Would someone remined me whether C++
mangled names include the return type, or just the args signature?"

  Perhaps it would be better to factor out the prototype generation into a
separate macro that could be invoked by both instances of "#define
CREATABLE_CLASS" ?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: how come #include "*.cpp" works?

[Igor Peshansky]

On Wed, 24 May 2006, Dave Korn wrote:

> On 24 May 2006 17:00, mwoehlke wrote:
>
> > === For declaring an object
> > #define CREATABLE_CLASS(name) \
> > extern class OBJECT* create_##name( int argc, const char* argv[] ); \
> > class name : virtual public OBJECT
>
> > === So main.cpp doesn't need the headers for every class
> > #undef CREATABLE_CLASS
> > #define CREATABLE_CLASS(name) \
> > extern class T_OBJ* create_##name( int argc, const char* argv[] );
> > #include "objects.def"
>
>   Bad idea, I think.  You now have two separate bits of code that are
> generating the prototypes for this set of functions.  You run the danger
> of getting inconsistent code.  In this case, unless T_OBJ is the exact
> same type as OBJECT, you've already made (technically speaking)
> undefined behaviour, haven't you?  Umm, perhaps I mean "Would someone
> remined me whether C++ mangled names include the return type, or just
> the args signature?"

The mangled name doesn't, but C++ will invoke different coercions based
on the return type, so if OBJECT and T_OBJ are indeed different types,
calling the function in exactly the same way from main.cpp and another
file may result in completely different behavior.

>   Perhaps it would be better to factor out the prototype generation into
> a separate macro that could be invoked by both instances of "#define
> CREATABLE_CLASS" ?

What's wrong with the following?

#define _CREATABLE_CLASS_DECL(name) \
class name : virtual public OBJECT
#define _CREATABLE_CLASS_PROTO(name) \
extern class OBJECT* create_##name( int argc, const char* argv[] );

#ifndef CC_NO_CLASS_DECL
#define CREATABLE_CLASS(name) \
_CREATABLE_CLASS_PROTO(name) \
_CREATABLE_CLASS_DECL(name)
#else
#define CREATABLE_CLASS(name) \
_CREATABLE_CLASS_PROTO(name)
#endif

and then, in main.cpp:

#define CC_NO_CLASS_DECL
#include "objects.def"

	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

RE: how come #include "*.cpp" works?

[Dave Korn]

On 24 May 2006 18:28, Igor Peshansky wrote:

> On Wed, 24 May 2006, Dave Korn wrote:

>>   Perhaps it would be better to factor out the prototype generation into
>> a separate macro that could be invoked by both instances of "#define
>> CREATABLE_CLASS" ?
> 
> What's wrong with the following?
> 
> #define _CREATABLE_CLASS_DECL(name) \
> class name : virtual public OBJECT
> #define _CREATABLE_CLASS_PROTO(name) \
> extern class OBJECT* create_##name( int argc, const char* argv[] );
> 
> #ifndef CC_NO_CLASS_DECL
> #define CREATABLE_CLASS(name) \
> _CREATABLE_CLASS_PROTO(name) \
> _CREATABLE_CLASS_DECL(name)
> #else
> #define CREATABLE_CLASS(name) \
> _CREATABLE_CLASS_PROTO(name)
> #endif
> 
> and then, in main.cpp:
> 
> #define CC_NO_CLASS_DECL
> #include "objects.def"

  Well, there's nothing wrong with it.  In fact it's exactly what I suggested
doing; you have factored out the prototype generation into a separate macro
called _CREATABLE_CLASS_PROTO.  Sure, you've then gone on to refactor the
separate #definitions of CREATABLE_CLASS into one header that can be included
at each place; with a little more work it would be possible to factor the
table-building definition

#define CREATABLE_CLASS(name) { #name, create_##name },

in as well and then everything would be really nice and well-engineered.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: how come #include "*.cpp" works?

[mwoehlke]

Igor Peshansky wrote:
> On Wed, 24 May 2006, Dave Korn wrote:
>>   Perhaps it would be better to factor out the prototype generation into
>> a separate macro that could be invoked by both instances of "#define
>> CREATABLE_CLASS" ?
> 
> What's wrong with the following?
> 
> #define _CREATABLE_CLASS_DECL(name) \
> class name : virtual public OBJECT
> #define _CREATABLE_CLASS_PROTO(name) \
> extern class OBJECT* create_##name( int argc, const char* argv[] );
> 
> #ifndef CC_NO_CLASS_DECL
> #define CREATABLE_CLASS(name) \
> _CREATABLE_CLASS_PROTO(name) \
> _CREATABLE_CLASS_DECL(name)
> #else
> #define CREATABLE_CLASS(name) \
> _CREATABLE_CLASS_PROTO(name)
> #endif

Hmm, not bad\... I think I *will* actually use that; thanks!

And 'T_OBJ' is supposed to be 'OBJECT'; that's a typo on my part... see 
my other message which passed yours in the night :-).

-- 
Matthew
Doom doom dooM doo-DooM dOOm DOom doOM... DOOM! -- Gir

Re: how come #include "*.cpp" works?

[mwoehlke]

Dave Korn wrote:
> On 24 May 2006 17:00, mwoehlke wrote:
>> 3: A create_<name> function must be written. If all objects were
>> constructed the same, this could have been lumped into the declaration
>> CREATABLE_CLASS macro, however not all constructors take the same
>> arguments, which is why 'create_<name>' takes an argc/argv pair. IOW
>> this requirement cannot be eliminated.
> 
>   Are you sure this can't be worked around using varargs macros?
> 
> #define CREATABLE_CLASS(name, ...) \
>   extern class OBJECT* create_##name( __VA_ARGS__ ); \

Hehe, good try :-), but "no"... First, how would you know how to invoke 
the create function like that? Second, 'argc' and 'argv' are actually 
being passed direct from the command line; the idea is that the 
individual create function deals with the args, so that the upper level 
doesn't need to know what the args should look like for a particular 
object type.

>> === For declaring an object
>> #define CREATABLE_CLASS(name) \
>> extern class OBJECT* create_##name( int argc, const char* argv[] ); \
>> class name : virtual public OBJECT
> 
>> === So main.cpp doesn't need the headers for every class
>> #undef CREATABLE_CLASS
>> #define CREATABLE_CLASS(name) \
>> extern class T_OBJ* create_##name( int argc, const char* argv[] );
>> #include "objects.def"
> 
>   Bad idea, I think.  You now have two separate bits of code that are
> generating the prototypes for this set of functions. [snip]

Oh, oops... it's actually 'T_OBJ' in my code; I was trying to replace it 
with 'OBJECT'. So, 'OBJECT' == 'T_OBJ'.

-- 
Matthew
Doom doom dooM doo-DooM dOOm DOom doOM... DOOM! -- Gir

RE: how come #include "*.cpp" works?

[Dave Korn]

On 17 May 2006 16:43, mwoehlke wrote:

> Larry Hall (Cygwin) wrote:
>> This isn't a Cygwin specific problem so it's off-topic for this list.
>> Please find a better forum for such questions.  If you feel you must
>> continue this discussion with a Cygwin crowd, then you can try the
>> cygwin-talk list.

  BTW, an interesting point arises from that thread:

  Everyone who replied chimed in with advice that the problem resulted from a
doubled include, and showed the OP how to use include guards to prevent the
resultant duplicate redefinitions.

  However,

1)  The OP was reporting *UN*defined symbol errors, not multiply-defined
errors;
2)  Nothing was being repeatedly included; each .cpp #included the header just
once, correctly;
3)  The division of declarations in the header file and definitions in the
.cpp file was completely correct; there are no definitions in the header so
nothing would get instantiated in both modules and cause a link error;
4)  The testcase compiles and runs fine!

  The only thing I can imagine is that OP got his compile command-lines messed
up, and was trying to fully compile-and-link each of the modules separately,
having missed out the -c option; so it compiled OK but then got link errors at
the end of the build.  When one .cpp was included in the other, the whole
thing was complete and all the links resolved.

  So, I think Larry should have written something more like

>> This isn't a Cygwin specific problem so it's off-topic for this list.
>> Please find a better forum for such questions, because nobody's
>> actually paying sufficient attention here.  If you feel you must
>> continue this discussion with a Cygwin crowd, then you can try the
>> cygwin-talk list, because irrelevant advice about dropping a hippo
>> on it is probably preferable to realistic-seeming yet completely
>> misleading advice.

  I guess if you've got a hammer, and every problem looks like a nail, then
everything that goes wrong is going to look like hitting your thumb....

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....