HDTenEightyP/NetNews huggingface dataset:
From: cambler@zeus.calpoly.edu (The Squire, Phish)
Newsgroups: comp.lang.c++
Subject: BC++ compilation switches
Date: 30 Jul 92 09:18:36 GMT
Organization: Fantasy, Incorporated: Reality None of Our Business.

This may be FAQ, or in the wrong place. If the later, I'd appreciate a
pointer to the right place.

Does anyone have, or know of a reference that gives more detail about
BC++ (3.0 or preferably 3.1) compilation switches? Word alignment vs.
non, optomizations, stack frames, etc. Specifically harmful interactions
between switches, and what they "really" do to code.

Perhaps from th standpoint, "Okay, my program is done and works, now I
need to decide on the switches for the final production compile..."

If there is no such document, but someone out there has the knowledge
I need, I'd be willing to swap that help for help with Turbo Vision (with 
which I've become quite adept).

Thanks in advance. 

-- 
If you insist upon living in a  | cambler@zeus.calpoly.edu | Fubar Systems BBS
dream, you may be taken as mad. |                          | (805) 54-FUBAR
  I like my dream.              | Because all you of       | 3/12/24, MNP5, 8N1
Then you *are* mad!             | Earth are IDIOTS!!       | FSBBS 2/FSUUCP 1.3
From: gal@funsys.funsys.se (Gunnar Appehl)
Newsgroups: comp.lang.c++
Subject: Re: MATRIX C++ library - anyone????
Date: 30 Jul 92 09:00:38 GMT
Organization: Enator Functional Systems

In article <1992Jul27.123524.8657@odin.diku.dk> fedtmule@diku.dk (Jens Markussen) writes:
>Some time ago, I posted a request on a C++ Matrix manipulation library
>here, but didn't receive any replies. What I'm looking for is a simple
>Matrix Class, with functions that will allow me to do basic matrix
>manipulations (e.g. add, multiply, invert, transpose, calc. determinant).
>
>There MUST be someone out there that knows of such a library....
>
>Please help,,
>
>Jens Markussen
>
>
>fedtmule@diku.dk       DIKU = Department of computer science, Copenhagen.


I know of two C++ class libraries for matrix manipulation:

1. M++ from Dyad Software, Fax no: +1 206 637-9428
   They have an ad on page 49 of The C++ Journal, no. 1, 1992.

2. Matrix.h++ from RogueWave Software, Fax no: +1 503 757-6650
   Sold in Scandinavia by Linsoft, Sweden: Tel no: +46 13 111588

I haven`t heard of anyone using them though, but they were both mentioned by
Jon Hopkins at the LOOK'92 conference in Helsingoer ("A Comparison of C++
Class Libraries").

Regards,

	Gunnar Appehl

----------------------------------------------------------------------
Gunnar Appehl			Enator Functional Systems AB
				Box 1213
Tel: +46 8 703 6200		S-164 28  KISTA
Fax: +46 8 750 6394     	SWEDEN

gal@funsys.se
From: whm@sunquest.UUCP (Bill Mitchell)
Newsgroups: comp.lang.c++
Subject: DEC C++ right or wrong on member pointer construct?
Date: 29 Jul 92 07:47:51 GMT
Organization: Sunquest Information Systems, Tucson

The following program compiles ok with cfront 2.0 and 2.1, but DEC C++
complains (at the line marked "error?"):

error: In the initializer for Bpmap[0].Bp::a, "&U::d" is of type "pointer to
Derived member of U", and may not be converted to "pointer to Base member of U".

    class Base {
	};

    class Derived: public Base {
	};

    class U {
      public:
	Derived d;
	};

    struct Bp {
	Base U::*a;
	};

    struct Bp Bpmap[] = {
	&U::d,  // error?
	0
	};

It seems to me that it should be ok because the derived class D should
acceptable in places where the base class B is acceptable.

If I try to cast:

    struct Bp Bpmap[] = {
	(Base U::*)&U::d,
	0
	};

the error is essentially the same:

error: In the initializer for Bpmap[0].Bp::a, "(Base ...)&U::d" is of type
"pointer to Derived member of U", and may not be converted to "pointer to
Base member of U".

I welcome your comments.
--------------------------------------------------------------------
Bill Mitchell				whm@sunquest.com
Sunquest Information Systems		sunquest!whm@arizona.edu
4801 E. Broadway                        {arizona,uunet}!sunquest!whm
Tucson, AZ, 85711                       sunquest!whm@uunet.uu.net
602-570-2585
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: const on pass by value
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 25 Jul 1992 15:58:14 GMT

mat@uunet.uu.net!mole-end writes:

>In article <1992Jul24.151010.11969@PacBell.COM>, pjcondi@lepton (Paul Condie) writes:
>> Should pass by value arguments be declared as "const" for
>> good coding style?  Or is that nit picking?
> 
>> For example:
> 
>> void foo (const int a);
>> or
>> void foo (int a);
>
>It's not nitpicking.  It's part of something called const correctness.
>Your program has it or doesn't.  Programs that have it are almost immune
>to a certain large family of errors.

Huh? In this example, it IS just nitpicking.
How could the presence or absence of const in the declaration for foo
affect the program's const correctness?

For pass-by-value arguments, using const is a matter of taste.
Personally I don't bother: programs have been traditionally written without
const in these cases, and I don't see any reason to change.
(Besides, this avoids unnecessary typing :-)

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: doug@foxtrot.ccmrc.ucsb.edu (Douglas Scott)
Newsgroups: comp.lang.c++
Subject: Re: Programming guidelines: naming of data members?
Date: 23 Jul 92 17:08:02 GMT
Reply-To: doug@foxtrot.ccmrc.ucsb.edu
Distribution: usa

In article <1992Jul20.232457.8295@taumet.com> steve@taumet.com (Steve Clamage)  
writes:
] sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
] 
] >Some people have suggested using the convention of prefixing data members
] >with an underscore, e.g. _name, _virtual and _template.   This is  
recommended
] >by Plum & Saks in "C++ Programming Guidelines", and recommended *against*
] >in the Ellemtel coding standards.
] 
] >I ...  am also somewhat alarmed by the ARM, p.7:
] 
] >   Identifiers starting with a single underscore (_) should also be
] >   avoided by ordinary users since C implementations reserve those for
] >   their own use.

I use underscores *after* the names, like length_ and name_.  These conflict  
with nothing I know of.

--
Douglas Scott                              (805)893-8352
Center for Computer Music Research and Composition
University of California, Santa Barbara
Internet: (NeXTMail ok)   <doug@foxtrot.ccmrc.ucsb.edu>
Newsgroups: comp.lang.c++
From: eb@ascent.com (Ed Barton)
Subject: Re: Conversion operators and typedef names
In-reply-to: krc@wam.umd.edu's message of Tue, 21 Jul 1992 16:09:17 GMT
Date: 27 Jul 92 08:59:34
Organization: Ascent Technology, Inc., Cambridge Massachusetts


In article <1992Jul21.160917.27353@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:

   class MyTime {
     ...
     operator time_t(void);   // Does this make you queasy?
     ...
   };

Technically, this works.  However, when I have tried it, I have found
that it is usually a bad idea in practice.  Remember that a typedef
does not define a new type, so on a particular machine, this is just
as if you had defined operator unsigned long() or operator long() or
whatever, depending on how time_t is actually defined.  That means you
can't have an operator time_t() and an operator other_t() at the same
time, if other_t is a typedef name that happens to come out the same
as time_t on your machine.  Also, the compiler will insert a call to
operator time_t() if you call a function f(unsigned long) on one of
your MyTime objects.  time_t is just the same as unsigned long (or
whatever) for purposes of overloading, so you will get a conversion
even when the unsigned long that is expected is not really a time_t.

(In my case, I had two different time representations that were both
internally represented as the same basic type.)

   The alternative, assuming you really do want to be able to convert your
   time objects into time_t's, is to supply a method like

     time_t MyTime::getValue(void);

At least when typedefs are involved, this is a better idea.  For
operator struct tm(), the answer might be different, if you can figure
out whether it should do a GMT or local time conversion.

The implicit conversions provided by constructors lead to similar
problems, if you have one-argument constructors that take time_t or
similar arguments.  Depending on the actual typedefs on your machine,
you might be surprised to have a plain integer in the code converted
into a MyTime when there is a constructor taking a time_t.

Any kind of overloading on typedef names can lead to portability
problems, if the typedef names are likely to be defined differently on
different machines.  For instance, if you have both operator int() and
operator time_t(), and time_t happens to be defined as int on some
machines, then you will have a clash on those machines but not others.




Xref: sparky comp.lang.c++:11687 gnu.g++.help:1053
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++,gnu.g++.help
Subject: Re: porting to g++ (from other "dialects")
Date: 28 Jul 1992 20:16:25 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Jul28.160935.11839@cs.ucla.edu> martin@oahu.cs.ucla.edu
(david l. martin) asks about portability problems encountered when porting
code that compiles under cfront-based and other compilers to g++.

I am writing here about g++ version 2.2.2.  At this time, the major
language incompatibilities are as follows:

1.  The "placement" form of operator new.  The ARM specifies that you
write

	new (address) Foo

and g++ requires

	new { address } Foo

This incompatibility has already been fixed and I believe that version
2.3, when released will support the ARM syntax.  This is the only
significant divergence between g++ and the ARM at this point, other
than exceptions which cfront doesn't have either.

2.  The template implementation is still buggy, but it's been improving
rapidly (2.2.2 is much better than 2.1).  g++ doesn't implement the cfront
hack that lets you declare template functions in Foo.h and define them in
Foo.c, and then do a hidden #include of Foo.c so everything will work.  If
you do this in g++ you'll need to #include "Foo.c".

3.  g++ used to have trouble with some complicated declarations
(pointers to arrays of functions, etc) if you didn't use typedefs.
I think these have been fixed.

4.  Lifetime of temporaries.  cfront-based compilers don't call
destructors on temporaries until the end of the enclosing block;
g++ destroys them earlier.  The g++ behavior is legal according to the
ARM, but cfront-based programs often rely on the extended lifetime
of temporaries that cfront provides.  This may cause some problems,
but the bugs aren't in g++ but in the unportable code.



--
Joe Buck	jbuck@ohm.berkeley.edu
From: jimad@microsoft.com
Newsgroups: comp.lang.c++
Date: 18 Jul 92 00:41 MDT
Subject: Re: boolean (was: Re: typedef vs enum)
Nf-ID: #R:1992Jul11.195547.18323@cmcl2.nyu:1382747533:1992Jul17.204136.17450@microsoft:864179071:001:825
Nf-From: microsoft.com!jimad    Jul 18 00:41:00 1992


In article <1992Jul16.222530.4197@sunb10.cs.uiuc.edu> pjl@sparc9.cs.uiuc.edu (Paul Lucas) writes:
>	I use:
>
>		enum { false, true };		// intentionally unnamed
>		typedef unsigned char Boolean;
....
>	(I don't think it's possible _to_ use it improperly).

Excuuse Me?

======



#include "iostream.h"

enum { false, true };

typedef unsigned char Boolean;

Boolean BoolInvertFunc(Boolean b)
{
	return !b;
}

void SomeFunc(int i) { cout << "SomeFunc(int) invoked\n";}
void SomeFunc(Boolean b) { cout << "SomeFunc(Boolean) invoked\n";}

main()
{
	Boolean b = true;
	unsigned char c = 'c';

	cout << c << '\n';
	cout << b << '\n';	// UNDIAGNOSED ERROR

	cout << ( c == BoolInvertFunc(BoolInvertFunc(c)) ); // UNDIAGNOSED ERROR
	cout << '\n';

	SomeFunc(b == true);	// WRONG FUNCTION INVOKED

  // etc etc etc

	return 0;
}
From: dwo1@gte.com (Donald W. Ottens)
Newsgroups: comp.lang.c++
Subject: tutoring, help, assistance
Keywords: tutoring
Date: 30 Jul 92 01:43:40 GMT
Distribution: usa
Organization: GTE Laboratories Incorporated, Waltham MA

Greetings,

Due to a demanding schedule, I need some tutoring in c++ during the
next two weeks only.

I will pay dollars ($) based on a negotiable and reasonable rate.

I would like the assistance via email or in-person, whichever is easier.

If there is anyone out there who can help, please call me at:

wk 617-466-2071

lv. mess.

thank you!
Newsgroups: comp.lang.c++
From: glenm@bnr.ca (Glen Martin)
Subject: Wanted: Class browsers
Reply-To: glenm@bnr.ca
Organization: Bell-Northern Research Ltd.
Date: Tue, 28 Jul 92 16:21:01 GMT

Hi all

A few days ago I posted a query as to what class browsers,
preferably public domain, are available. So far I have had
but one response.

Please forward any responses direct to me, and I will summarise
to the net.

thanks

--------------------------------------------------------------------------------
Glen Martin              Bell-Northern Research          Ottawa, Ontario, Canada
Phone : (613) 763-7299   Fax: (613) 763-2626             Internet: glenm@bnr.ca
--------------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: 128-bit math
Date: 30 Jul 92 17:45:40 GMT
Organization: Microsoft Corporation

In article <AVENGER.92Jul28134534@realsoon.WPI.EDU> avenger@realsoon.WPI.EDU (Sam Pullara) writes:
>
>Has anyone implemented a quad precision library for C++?  How
>difficult would something like this be?

typedef short int16;
typedef unsigned short uint16;
typedef long int32;
typedef unsigned long uint32;

template <class LONG, class ULONG, class SHORT, class USHORT> class double_int
{
	....
};

template <class LONG, class ULONG, class SHORT, class USHORT> class double_uint
{
	....
};

typedef double_int<int32, uint32, int16, uint16> int64;
typedef double_uint<int32, uint32, int16, uint16> uint64;
typedef double_int<int64, uint64, int32, uint32> int128;
typedef double_uint<int64, uint64, int32, uint32> uint128;
typedef double_int<int128, uint128, int64, uint64> int256;
typedef double_uint<int128, uint128, int64, uint64> uint256;
....
From: gordie@duts.ccc.amdahl.com (Gordon Freedman)
Newsgroups: comp.lang.c++
Subject: Re: C++ member pointer error
Date: 29 Jul 92 17:59:40 GMT
Reply-To: gordie@duts.ccc.amdahl.com
Organization: Happy hacker bait and tackle shop


>"junk.cc", line 21: error:  object missing in call through pointer to
>member function
>
>Example code follows.
>
>#include <iostream.h>
>
>class V{
>public:
>  int i;
>  V() { i = 0;};
>  void run();
>  char * print(int x) {cout << "x is " << x << endl; return "Foo!";};
>};
>
>struct E {
>  typedef char * (V::*fnptr)(int);
>  fnptr fn;
>  E() { fn = 0;};
>};
>
>void V::run() {
>  E e;
>  e.fn = (fnptr) &V::print;
>  i = 42;
>  cout << (e.fn)(i) << endl;  //ERROR: (*(e.fn))(i) gives the same error
>};

Try changing 
e.fn = (fnptr) &V::print;
to
e.fn = &this -> print;
or some other variation ...

It looks like your compiler doesn't realize that &V::print mean's "this
instance of V's" print function, so it doesn't assign the object pointed to
by "this" (in V::run) to the function pointer (remember that a pointer to 
a member function is more than just a ponter to a function, it also has the
value to assign to "this" when the member function is invoked).

I don't think you need to cast print to a (fnptr), since it already matches
the typedef (i.e. e.fn = print; rather than e.fn = (fnptr) print;).

>-- 
>Tim McBrayer                                tmcbraye@thor.ece.uc.edu
>Computer Architecture Design Laboratory     (513) 556-0904
>University of Cincinnati                    "Visualize Whirled Peas"



---
Gordon Freedman: gjf00@duts.ccc.amdahl.com OOPs, did I code that?
Newsgroups: comp.lang.c++,comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 25 Jul 1992 09:04:38 GMT

shang@corp.mot.com (David (Lujun) Shang) writes:

>Now I give you an example that truely needs multiple dispatch.
>
>class Animal
>{  Animal * fight (Animal * a)
    // simplified version for brevity
    {  return this->strength() > a->strength ? this : a; }
>};
>
>and we have the following fights:
>
>Animal * victor;
>..
>victor = wolf.fight (jackal);
>victor = lynx.fight (victor);
>victor = bull.fight (victor);
>..
>
>You'll suprise me if you say, okay, I don't care who is the winner, anyway,  
>some animal or none. Then what's the purpose of the above codes? Just for
>some thing unknown, unknown forever?  You can say it is a bad design again, as
>easily as blowing off dust. But be aware, it is an example of your beloved  
>multiple dispatch.

I don't quite understand you example.
It seems to be incomplete.
Presumeably after all the fights, you are going to do something like

	if (typeof(victor) == typeof(wolf))
		cout << "The wolf won!\n";
	else if (typeof(victor) == typeof(lynx))
		cout << "The lynx won!\n";
	else ...

To me that looks like horrible design.
Why not just have

	cout << "The " << victor->name() << " won!\n"; 

instead? Then there is no need for downcasting (and you also have a better
design!).

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: ".", "->" operators and member data declarations
Date: 23 Jul 92 00:48:21 GMT
Organization: Microsoft Corporation

In article <1992Jul21.141038.20704@usenet.ins.cwru.edu> exk11@po.CWRU.Edu (Erik Kangas) writes:

|    I would like to use some operator, ( I know "." is reserved and  "->"
|only returns a pointer to the structure.) that would know the offset of
|"xfer" in structure foo without me having to declare all the defines.
|I should be able to do a "Fooptr.xfer = "P"".

The following are the conceivable operators that could potentially 
"make sense" for you to use:

1) built-in binary operator.()		ref2obj . ref2mem
2) built-in binary operator->()		ptr2obj -> ref2mem
3) built-in binary operator.*()		ref2obj .* ptr2mem
4) built-in binary operator->*()	ptr2obj ->* ptr2mem

5) overloaded binary operator.()	SmartRef2Obj . SmartRef2Mem
6) overloaded binary operator->()	SmartPtr2Obj -> SmartRef2Mem
7) overloaded binary operator.*()	SmartRef2Obj .* SmartPtr2Mem
8) overloaded binary operator->*()	SmartRef2Obj ->* SmartPtr2Mem

9) overloaded "unary" operator.()	SmartRef2Obj . (implied ref2mem)
10) overloaded "unary" operator->()	SmartRef2Obj -> (implied ref2mem)

1-4 are built-in so they can't do it -- I just list them as an aid to 
understanding what I'm talking about.

5 isn't allowed since you'd have to be able to declare a RHS parm of
type "reference to member" in order to be able to retain the built-in
behavior on RHS non-smart members -- but C++ doesn't allow "references
to members" so this can't be done.

6 likewise isn't allowed

7 has been proposed but is blocked by the C++ committee

9 has been proposed but is blocked by the C++ committee

10 is allowed but doesn't meet your requirements since you need to overload
   based on the RHS.

This eliminates all your "reasonable" possibilities except 8:

SmartPtr2Obj::operator->*(SmartPtr2Mem)

which has ugly syntax but that's the way it goes:

	pobj ->* pmember;

  (pobj ->* pmemberFunc)(parms);

This choice kind-of makes sense syntactically when one is doing associative
member lookup:

	SmartPtr2Mem pmember = "foo";

	pbar ->* "foo";

	pbar ->* pmember;


Better choices would be available if the committee could be convinced to
adopt operator. [and operator.*] :

	bar .* pmember;

	bar .* "foo";
Newsgroups: comp.lang.c++
From: nh@cbnewsg.cb.att.com (nicholas.hounsome)
Subject: Re: OO databases OBJECTSTORE vs ONTOS
Organization: AT&T
Date: Tue, 21 Jul 1992 07:47:43 GMT

From article <1992Jul20.173530.28999@athena.mit.edu>, by berczuk@space.mit.edu (Steve Berczuk):
> 
> Does anyone out there have any experiences with either Ontos or
> ObjectDesign;'s object store as a database for C++ objects? (even better, has anyone done any comparisions?)
> 

I am currently doing a comparison - I have tried ObjectStore but I 
have not received a copy of ONTOS yet so I probably
know no more than you.

> what I know comparison wise (so far) is this (please correct me if I misstate anything):
> 
> *) Ontos seems to support a richer (and more SQL like if that is worth anything) query facility.

That is my impression too. ObjectStore queries appear to be there 
for performance reasons only - to gain the advantage of indexing. They
are nothing like SQL. ObjectStore is very definitely for programmers
to make objects persistent rather than for ad hoc queries.

> *) Ontos is inheritance based while Objectstore is not.

I think that this is true. You can make anything persistent in
ObjectStore.

> *) Object store has less effect on your code but is based on  language extensions

You do not have to use the extensions. Talking to people on the 
course I went on most of them that either do not or will not use
the extensions. If you do not use the extensions then the only 
intrusion on your nonpersistent  C++ is:
	a) stuff to handle database roots (entry points)
		this can be handled by macros.
	b) transaction handling.
		this is obviously unavoidable.
	c) stop gap exception handling macros pending
		cfront support.
	d) you must use ObjectStore collections if you want queries.
	e) you must change all new calls for persistent allocation
		Less trouble than you might think .

Of these only (e) is realy noticeable.

> *) ODI sales reps seem to not return calls 
> 

Their distributors in the UK are good (but then they are only 15 minutes
drive away) and one of the founders at least seems keen to deal with
problems promptly.

> Any comments would be appreciated,,, thanks,
> steve berczuk
> 

Please keep me informed of your investigations,

Nick Hounsome

Newsgroups: comp.lang.c++