HDTenEightyP/NetNews huggingface dataset:
From: mittle@siena.watson.ibm.com (Josh Mittleman)
Subject: Re: Query regarding constructor taking void (*f)(...) as arg
Date: Tue, 06 Oct 92 18:29:33 GMT
Organization: IBM T. J. Watson Research

> void f(int a) {int b = a;}
> class bar {
>     public:
> 	bar::bar(void (*f)(...) ...) {int a = 1;}
> };
> main () {bar b(f,1);}
> 
> The complaint is that the constructor invocation bar b(f,1) does not
> match the argument list for bar::bar.

The error is correct: ... is a part of the signature of the function.  At
invocation, the ... may match any string of arguments, but that doesn't
mean that the type (*)(int) is the same as (*)(...).  I believe you can
think of it this way: ... is a special signature which allows a special
part of the compiler's function-matching algorithm to come into play when
resolving an invocation.  Otherwise, it is treated just like any other
signature, and it can only match another ...  Thus, the first argument to
your constructor must have type void (*)(...)

> In case you're curious, what I'm trying to do here is to construce
> a type that takes a function name and a variable list of parameter types
> as arguments and later executes the function.

I don't think your approach can work.  ... is not an argument; it is simply
an indication that there may or may not be more arguments stored somewhere
in memory.  Recall that the only portable way to access those arguments is
the va_list macros.  To use those, you _must_ have an argument before the
... from which to reference.  A function like f(...) cannot access its
arguments.  

You might be able to manage what you want by constructing the va_list and
storing a reference to it.  However, I don't know how long a va_list is
valid, nor how many you can keep around at the same time.  It isn't a true
object, so the construction of the second va_list may corrupt the first.  I
guess it depends on how they are implemented.

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
ReplyTo: nikki@trmphrst.demon.co.uk
Subject: Abstract base classes, virtual inheritance & mixins
Distribution: world
X-Mailer: cppnews $Revision: 1.18 $
Organization: Trumphurst Ltd.
Date: Wed, 30 Sep 1992 17:06:12 +0000

 I have a problem with virtual inheritance and mixins. I have a class
 structure as follows :-

 (Base1) <- - - - - - - Derived1 <------------- Derived2
 Base1Virtual() = 0     Base1Virtual() defined  Base1Virtual() from Derived1
================================================
 (Base1) <- - - - - - - (Mixin) <--------------
 Base1Virtual() = 0     Base1Virtual() = 0
========================
 (Base2) <-------------
 Base2Virtual() = 0     Base2Virtual() defined	Base2Virtual() from Mixin

 <- - - represents virtual inheritance
 <----- represents regular inheritance
 Base<n>Virtual are virtual methods

 I figure Derived2 is NOT an abstract class, but Borland C++ 3.0 
 disagrees. Zortech C++ 3.0r4 also disagrees sometimes (see comment) !
 
 Some example code and the error message follows ...
------------------------------------------------------------------
#include <stdio.h>

inline void print(const char *string)
{
	printf("%s\n", string);
}

class Base1 {
public:
	Base1();
	~Base1();
	virtual void Base1Virtual() = 0;
	};

class Derived1 : virtual public Base1 {
public:
	Derived1();
	~Derived1();
	virtual void Base1Virtual();
	};

class Base2 {
public:
	Base2();
	~Base2();
	virtual void Base2Virtual() = 0;
	};

class Mixin : public Base2, virtual public Base1 {
public:
	Mixin();
	~Mixin();
//	virtual void Base1Virtual() = 0;
// If the line above is uncommented, Zortech C++ also complains that 
// Derived2 is abstract.
	virtual void Base2Virtual();
	};

class Derived2 : public Derived1, public Mixin {
public:
	Derived2();
	~Derived2();
	};

Base1::Base1()
{
	print("Base1 constructor");
}

Base1::~Base1()
{
	print("Base1 destructor");
}

Derived1::Derived1()
{
	print("Derived1 constructor");
}

Derived1::~Derived1()
{
	print("Derived1 destructor");
}

void Derived1::Base1Virtual()
{
	print("Derived1::Base1Virtual()");
}

Base2::Base2()
{
	print("Base2 constructor");
}

Base2::~Base2()
{
	print("Base2 destructor");
}

Mixin::Mixin()
{
	print("Mixin constructor");
}

Mixin::~Mixin()
{
	print("Mixin destructor");
}

void Mixin::Base2Virtual()
{
	print("Mixin::Base2Virtual()");
}

Derived2::Derived2()
{
	print("Derived2 constructor");
}

Derived2::~Derived2()
{
	print("Derived2 destructor");
}

main()
{
	Derived1 h;
	Derived2 c;
// Error : Cannot create instance of abstract class 'Derived2'
	Base1 &hb1 = h;
	Base1 &cb1 = c;
	Base2 &cb2 = c;

	h.Base1Virtual();
	c.Base1Virtual();

	c.Base2Virtual();
// Zortech C++ crashes horribly (rebooting DOS) at this call.

	hb1.Base1Virtual();
	cb1.Base1Virtual();
	cb2.Base2Virtual();
	return 0;
}
---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
Newsgroups: comp.lang.c++
From: dascalu@libra.math.tau.ac.il (Dascalu Ziv)
Subject: Turbo Turing Machine for windows 3
Organization: School of Math & CS - Tel Aviv University , Tel Aviv , ISRAEL.
Date: Tue, 22 Sep 1992 16:12:20 GMT



      +-------------------------------------------------+
      |                                                 |
      |   Turbo Turing Machine Simulation for Windows 3 |
      |                                                 |
      |    You are welcome to take and enjoy this       |
      |    product and give to to any person you like.  |
      |                                                 |
      |    Full source code written in C++ is also      |
      |    available free of any charge - just mail me  |
      |    the request.                                 |
      |                                                 |
      |    Product can be found in (when using ftp) :   |
      |          taurus.math.tau.ac.il in /pub/ttm      |
      |                                                 |
      |           dascalu@math.tau.ac.il                |
      |                                                 |
      +-------------------------------------------------+
From: pheras@iris-dcp.es
Newsgroups: comp.lang.c++
Subject: Re: NIHCL Doc's
Date: 29 Sep 92 22:02:37 +0100
Distribution: comp
Organization: REDIRIS, Red Nacional de I+D

In article <djd.717691139@reading>, djd@csg.cs.reading.ac.uk (David J Dawkins) writes:
> michiel@baan (Michiel Wories) writes:
> 
>>I Just downloaded and compiled NIHCL for BC++3.1 and am now looking...
>> <stuff deleted>
> 
>     What's NIHCL?
> 
> -dave
> 
> -- 
> djd@uk.ac.reading.cs.csug
> djd@uk.ac.reading.cs.csg
> davidd@integ.uucp


	Please, could you say me which is the way to obtain NIHCL for BC++3.1?

	Thank you.

	Pedro de las Heras
	FUNDESCO	SPAIN.


Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: How to ensure correct argument type provided.
Keywords: integer promotion argument type checking
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Sat, 3 Oct 1992 03:49:17 GMT

In <1992Oct2.035453.25085@odin.corp.sgi.com> pj@sam.wpd.sgi.com (Paul Jackson) writes:

>Question:

>I have some routines that pass around a couple of small integer
>arguments, amongst other args.  I want to type these args so that
>the compiler will warn if args of the wrong type are passed.  How
>can I inhibit automatic promotion of other integer types, and get
>a warning or error instead.

>For example, what type (or other change) could I make (to) i1_t
>and i2_t in the following so that the compiler would not silently
>accept my passing a type i2_t to a function declared to expect a
>type i1_t:

>    typedef int i1_t;
>    typedef int i2_t;
>    
>    extern void foo(i1_t);
>    
>    main(){
>        foo(i2_t(1));       // wrong foo arg 1 type; but no warning
>        return 0;
>    }
>    
>    void foo(i1_t i){
>        foo(i);
>    }

*****>	You can't.  A typedef is *NOT* a new type: i1_t and 12_t are both
	int.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: dr808310@cs.nthu.edu.tw (Mr. Presto)
Subject: Looking for a Data Structure Book of C++
Organization: National Tsing Hua University (HsinChu)
Date: Tue, 6 Oct 1992 03:55:20 GMT

I am looking for a book which introduce data structre by OOP 
concept, this book was introduced by somebody a few months ago
on this list, if you know where stored such file, tell me please.

--K.C.Liu
kcliu@cs.nthu.edu.tw
Xref: sparky comp.lang.c++:14361 comp.std.c++:1258
From: rgp@mpd.tandem.com (Ramon Pantin)
Newsgroups: comp.lang.c++
Subject: Re: How to ensure correct argument type provided.
Keywords: integer promotion argument type checking
Date: 2 Oct 92 23:13:46 GMT
Organization: Tandem Computers, Micro-Products Division

In article <1992Oct2.035453.25085@odin.corp.sgi.com> pj@sgi.com writes:
>Question:
>
>I have some routines that pass around a couple of small integer
>arguments, amongst other args.  I want to type these args so that
>the compiler will warn if args of the wrong type are passed.  How
>can I inhibit automatic promotion of other integer types, and get
>a warning or error instead.

The only thing that has worked for me is to have a #define that
takes one argument (a type name) and that expands into a trivial
class that functions exactly as an integer (i.e. it contains an
integer and overloads all the appropriate operators so that it
behaves like an integer) but with no conversion operators.  Call
that macro declare_integral_type, then I do:

#ifdef STRONGLY_TYPED
	declare_integral_type(it_1);
	declare_integral_type(it_2);
#else
	typedef int	it_1;
	typedef int	it_2;
#endif

You will want to compile your code with STRONGLY_TYPED while
doing development, this will add substantial overhead (at least
on cfront based compilers, even with everything being inlined) so you
will want to compile your production code without STRONGLY_TYPED.
You could consider this like a "lint" compile and just do it the
other way around.  Of course all this can create lots of trouble for
large projects.

It is certainly a pity that the type equivalence rules in C and
C++ are so weak.  As it is customary in this group, I will propose
that an extension be made to this effect (pick your favorite
syntax) and will proceed to consider it hopeless because it would
fall under the "yet another nice feature" category.

Ramon Pantin
From: jme4@po.CWRU.Edu (John M. Ehrlinger)
Newsgroups: comp.lang.c++
Subject: FAQ request
Date: 6 Oct 1992 02:57:26 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: jme4@po.CWRU.Edu (John M. Ehrlinger)
NNTP-Posting-Host: slc12.ins.cwru.edu


Hi all,

	Could some post where the FAQ is located or send me a copy of
it?

	Thanks,
	--John

Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: GOTOo wars
Summary: Yes, but has it a future?
Organization: :
Date: Fri, 25 Sep 1992 20:35:55 GMT

In article <28632@vedge.UUCP>, hendrik@vedge.UUCP (Hendrik Boom) writes:
> mat@mole-end.matawan.nj.us writes:

> : Well, as one who spent some months enhancing a compiler, which is, after
> : all, a code generator, I'd like to find a processor whose instruction
> : set supports the Structured Constructs.

> Burroughs 1700 series were microcoded to support the Structured Constructs.

Yes, but does it have  Intel Inside(tm) ?  (Ok, ;') .)  BSF, does that
processor have a future compared to RISC machines?  Can it run at 10% of
the speed of a high-end workstation, or 2% of the speed of the first
generation DEC Alpha?

How many people are now engaged in writing compilers for it?  What
happened to Burroughs, anyway?  Didn't they become A Wrong Horse?
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c++
Subject: Re: downcasting (was Re: GOTOo wars)
Date: 1 Oct 92 18:53:31 GMT
Article-I.D.: ulogic.361
Organization: negligable

In article <9227521.28722@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>hartman@ulogic.UUCP (Richard M. Hartman) writes:
>
>>We're using the NIH Linked List.  When you get something off
>>the list it is just an Object *.  To actually use it you have
>>to downcast it to it's proper (and hopefully Object-derived :)
>>class.  If someone knows a way around this, please let me know
>>and I will *gladly* give up my use of castdown......
>
>The Politically Correct way of doing this, I believe, is to use a template
>linked list class. (Look Ma, no casts! :-)

That only works if you compiler supports templates.....	:(


		-Richard Hartman
		hartman@uLogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Disco isn't dead...			...it's just in witness protection!
Newsgroups: comp.lang.c++,comp.object,gnu.g++.help
From: plambert@plc.cs.psu.edu (Paul  Lambert)
Subject: LOOKING FOR JAMES COPLIEN...
Organization: Penn State Computer Science
Distribution: usa
Date: Tue, 29 Sep 1992 14:42:17 GMT

James Coplien, if you're out there, I would appreciate it if you could find
time to send me a message--I've lost your address.

If anyone knows his email address, I'd appreciate their sharing it with me, or
I guess the more appropriate thing to do would be to contact him and call
his attention to this post.

James Coplien:

I'd just like to thank you for all of your help this past spring, and for your
gift--it was most interesting and useful.  There are a few simple things I'd
like to clear up (like, for example, I'm not "Dr. Lambert," I'm just a mere
undergrad, Sophomore nonetheless).  I would really like to thank you for
your assistance, as I received a rather high mark in the course--for the
record, I was INSTRUCTED to seek assistance from others--and much of it is
because of your help.  While many of the techniques in your book were far
beyond the scope of my projects, I really learned a lot of what I was TRYING
to learn: the usefulness, structure, organization, and practicalities of
an object-oriented approach.  I've got a long way to go, but I've got plenty
of time now that I understand the general basics.  Thank you again.

Many belated thanks also to everyone else who was kind enough to reply to my
questions I left in comp.lang.c++.  It was a basic CompSci course which I
attempted to complete in C++ instead of Fortran and Pascal (just a little bit
of a difference!), and I couldn't have done it without outside help.  My`
instructor couldn't believe I could do so much after spending only a few
weeks with a reference book, and no experience in OOPS.  Sure, nothing quite
worked _perfectly_, but then, well, that's to be expected!

I also helped find an error in a string library--perhaps a useful service?

Thanks to everyone!
--Paul Lambert

-- 
plambert@psuvm.psu.edu, plambert@endor.cs.psu.edu, or just plambert@cs.psu.edu
a                       a                                  a
u                       u                                  u
l                       l                                  l
Newsgroups: comp.lang.c++
From: eb@ascent.com (Ed Barton)
Subject: Re: C++ style and enumerations
In-reply-to: daemon@bnr.co.uk's message of 30 Sep 92 10:15:32 GMT
Date: 1 Oct 92 09:03:58
Organization: Ascent Technology, Inc., Cambridge Massachusetts

In article <1992Sep30.101532.27566@bnr.co.uk> daemon@bnr.co.uk writes:

   I am in the process of porting a library to C++ and wonder how other
   poeple address two problems 

   a) 'Enumerations' with shared values [non disjoint sets of members]. 
      i)  Obviously you can simply rename enumeration values to avoid this,
	  but this may do some violence to the interface you are porting.
      ii) Break the enumeration values into disjoint sets, realised as enums.
	  Define a new class (not an enum) with an integer variable, with
	  assignment defined for itself and appropriate enums.

   b) Iterators over enums. It is obviously quite easy to write an iterator
      class over the values of an enumeration. But what do you return when
      the enumerations values are exhausted?  0 seems reasonable, but cannot
      be a member of the enum [if you want to do this for more than one enum].
      So, do you return zero or what?

   Regards, Peter

Your message does not contain an e-mail address that can be used for
responding privately.  Please change your signature file, or something
about your news-posting environment, so that your postings will
contain an e-mail address in case people do not feel that their
responses will be of interest to the entire group.  The only address
clues that come out in your posting are daemon@bnr.co.uk, which
apparently gets the mail to your system administrator, and the
"Regards, Peter" line.

Regarding (a.ii), it is sometimes useful to define enumerations that
are local to some class.  Then, if a subclass chooses to inherit from
the class where an enumeration is defined, the values from that
enumeration are directly visible in its methods.  Elsewhere, the
verbose notation classname::enumvalue can be used.

Regarding (b), there are various styles of iterators that have been
proposed.  If you use the style that returns the next value directly,
it is hard to see what you could use as a terminator.  However, if you
use a less popular style that returns the next value into a variable,
you can use the return value of the next() operation to determine
whether there was another value:

	Iterator iter(my_collection_of_doubles);
	double d;
	while (foo.next(d)) { ... } // int Iterator::next(double& d);

Here I have used doubles instead of anything to do with enumerations,
to avoid thinking about what you want to do in (a).
From: alfaroja@vtcc1.cc.vt.edu (L. D. ROPER)
Newsgroups: comp.lang.c++
Subject: Pascal 2 C
Date: 28 Sep 92 04:17:00 GMT
Organization: Virginia Tech, Blacksburg, Virginia
News-Software: VAX/VMS VNEWS 1.41

I am looking for a Pascal to C converter...Thanx in advance

Alfaroja@vtcc1.cc.vt.edu
From: michiel@baan (Michiel Wories)
Newsgroups: comp.lang.c++
Subject: NIHCL Doc's
Summary: WANTED: Book on NIHCL (or electro doc's)
Keywords: NIHCL
Date: 28 Sep 92 08:34:10 GMT
Distribution: comp
Organization: Baan International


Hi there!

I Just downloaded and compiled NIHCL for BC++3.1 and am now looking
for a (good) book on the subject. What I would prefer is the electronic
version of the book.
Please mail me. I'm not a frequent reader of this group (not enough time...).

Thanks!

Michiel (michiel@baan.nl)
-- 
michiel@baan.nl (Michiel Wories @ Baan International, The Netherlands)
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Newsgroups: comp.lang.c++
Subject: Re: BC++ 3.0 TDW and Windows 3.1
Date: 6 Oct 92 16:40:07 GMT
Article-I.D.: mksol.1992Oct6.164007.5032
Organization: Texas Instruments, Inc

In article <tpenttin.718029822@majakka.uku.fi> tpenttin@majakka.uku.fi (Tommi Penttinen) writes:
>"Can't load WINDEBUG.DLL". That's what my TDW tells me when I try to debug
>anything.. And I'v put WINDEBUG.DLL on the dos command path as told in a
>readme file on the distribution disk. So, what's the problem? Doesn't
>BC++ 3.0's Turbo Debugger for Windows work with Windows 3.1?

No, it doesn't.  There was at one time a patch for this, but now the
suggested fix is to update your compiler suite to the current version.

[I don't know if Borland is still providing the patch to 3.0 users or
not -- I never got the patch; I merely waited for the new release.]

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
From: david@csource.oz.au (david nugent)
Newsgroups: comp.lang.c++
Subject: C++ v3.0 specification
Date: Thu, 01 Oct 92 17:46:19 +1000
Reply-To: david@csource.oz.au
Organization: Unique Computing Pty Ltd, Melbourne, Australia

Is the C++ v3 specification available in electronic form at all?  If so,
where?  If not, what is the definitive document?


..............................................................................
david nugent          Public Access Usenet      "Only Nixon could go to China"
david@csource.oz.au     +61-3-792-3507                    - old Vulcan proverb
3:632/400@fidonet, 58:4100/1@intlnet, 199:4242/5@rainbownet, 33:300/6@admin
PO Box 260, Endeavour Hills, Victoria, Australia, 3802.
Xref: sparky comp.lang.c++:14617 comp.std.c++:1331
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: The concept of templates considered ill designed
Date: 6 Oct 92 17:45:37 GMT
Article-I.D.: alice.23822
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <Yeo91je00awVE_zEkI@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:

> What I say is just that inheritance constraint permits to check
> the file and compile it before using it !

I understand that that is what you're saying, but you haven't convinced me.

For example, suppose we have a class:

	class Foo {
	public:
		void mem(int);
	};

and a template function:

	template<class T> void f(T t) { t.mem(0); }

You are saying that constraining T to be of class Foo or a class
derived from Foo will make it possible to type-check this template
at compile time.  Wel, what about this?

	class Bar: public Foo {
	public:
		void mem(int);
		void mem(void*);
	};

If we call f with an argument of type Bar, it will fail during instantiation
with an ambiguity error.  The only way to avoid this is to say that the type
constraint also constrains the call of t.mem(0) to just those instances of
mem defined in the base class -- but in that case, you will still get in
trouble with this one:

	class Baz: public Foo {
	public:
		void mem(long);
		void mem(double);
	};

because now *neither* of the variants of Baz::mem matches the one in Foo.
Thus, you have two choices:

	1. Attempt to call Baz::mem(int), which doesn't exist;

	2. Call Foo::mem(int), in which case you might as well not
	   bother using templates at all, or

	3. Give an ambiguity error, in which case you can't type-check
	   the original template.

My point in giving this example is to show that statements like `constraining
template types makes compile-time type checking possible' cannot be made
casually -- it is the responsibility of the person making such a statement
to provide evidence that the statement is indeed true.

This stuff is **difficult**!  Don't take it lightly!
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++,comp.std.c++