HDTenEightyP/NetNews huggingface dataset:
From: langtonk@maccs.dcss.mcmaster.ca
Newsgroups: comp.lang.c++
Date: 17 Jul 92 22:25 MDT
Subject: help on dynamic multidim. array in 
Nf-ID: #N:1992Jul17.182514.24651@maccs.dcs:1510041107:001:714
Nf-From: maccs.dcss.mcmaster.ca!langtonk    Jul 17 22:25:00 1992


I am trying to dynamically allocate a two dimensional array using
the command "new" in Borland C++ version 2.0. The idea is that I want
to be able to change the size of the array at any time within the 
program and I don't know the array size ahead of time. As an example
I have tried the following:

int *arr;

arr = new int [10][5]

This gives the following error message:

Cannot assign 'int[5] far *' to 'int far *'

The Borland C++ Programmers Guide has the following example of page 111:

mat_ptr = new int [3][10][12]

but it does not give the data type for mat_ptr. Does anyone know how to
make this work? Any advice would be greatly appreciated. 

Many Thanks.

Joseph Ho

langtonk@maccs.dcss.mcmaster.ca
From: maxtal@extro.ucc.su.OZ.AU
Newsgroups: comp.lang.c++
Date: 17 Jul 92 20:30 MDT
Subject: Re: Novice? question: Designing for mul
Nf-ID: #R:1992Jul9.144630.10863@clpd.kodak:653025985:1992Jul17.163022.28974@ucc.su.oz:1135296309:001:2824
Nf-From: extro.ucc.su.OZ.AU!maxtal    Jul 17 20:30:00 1992


In article <rmartin.711299360@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>maxtal@extro.ucc.su.OZ.AU (John (MAX) Skaller) writes:
>
>|In article <1992Jul14.122238.9500@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John (MAX) Skaller) writes:
>|>In article <rmartin.711047889@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>|>>
>|>>|	WARNING: You can't do this using either cfront or Borlandc,
>|>>|	both have faults preventing use of virtual abstract bases.
>|>>
>|>>MAX: This is far too strong a statement.  There are indeed some
>|>>limitations, especially where virtual bases are concerned.  But you
>|>>CAN make mixin heirarchies quite successfully.
>|>
>|>	I don't agree. 
>
>|	Well, on re-reading, I would now change my comments:
>
>|	Yes, you can make mixin *heirarchies* without problems.
>
>|	But, that is almost an oxymoron: mixin is almost by
>|	definition using DAGs, it explicitly requires
>|	shared virtual bases to hook the implementations in,
>|	so it would not be possible to have a mixin *heirarchy*,
>|	mixin relies on 'sibling' virtual calls.
>
>But as I explained in a previous posting, mixin of pure virtual
>functions through DAGs is not precluded, the derived class must simply
>resolve the ambiguities by declaring the functions and routing them to
>the appropriate base.  Inconvenient, but not a disaster.

	My point is not that mixin through DAGS is, or is not 
*precluded*, but that mixin is ALWAYS through DAGS (otherwise
it is not mixin).

	And there are no ambiguities PLEASE read the section
in the ARM on name dominance, look at the examples
of sibling calls given there, and THEN read the definition
of abstract classes.

	See how it is a little fuzzy?

	See how it SHOULD read

	"An abstract class is one which, if it were instantiated,
	would be subject to virtual calls to pure functions,
	and therefore can't be instantiated. Any class for
	which all virtual calls are to non-pure functions
	is NOT abstract"

In other words: an abstract class is one with holes in it.
A concrete class is one without holes.

If a class is derived from some base, and a virtual call
though the base is resolved to some function in a class
derived from the base, then the base virtual can be
made pure (in this instance) without the most derived
object having any holes and therefore it would remain concrete.

This whole issue was argued out before. I started it.
Borland agrees it is a bug to be fixed. Others have
confirmed that this makes sense. How else could
you possibly interpret the definition of
ABSTRACT class?



-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------

Xref: sparky comp.lang.c++:11477 comp.std.c++:940
From: glw@io.uswest.com (Glenn Williams)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Date: 24 Jul 92 14:33:59 GMT
Organization: US WEST Communications

>(John MAX Skaller) writes:
>
>	Given the need to do downcasting, to do it safely run-time
>type information is required. But I am arguing it is not necessary
>to downcast. So the question of needing run-time type info to
>do it doesn't arise.
>
>We design our systems properly in the first place, and then the need
>to downcast never arises, when our thoughts wander in that 
>direction one can be sure we are not thinking virtuously,
>and perhaps the design itself is flawed.
>

Ok, let's have an example of a properly designed system. 

>	Inother words, in a *domestic* system, any apparent 
>need for downcasting should be used as an indicator of flawed design.
>
 
What is the basis for your conclusions?

>class Animal {
>	int mate(Animal&);
>};
>class Dog : Animal {
>	int mate (Animal&);
>};

>We REALLY want Dog::mate(Dog&), but we can't have it.

>This is a flaw in Object Oriented Programming IMHO.
>The solution requires multimethods which are inherently
>functional.

What?

You have stated all this before, and every time you do, you fail to provide
any examples of how you would design without downcasting. 

So, as I asked for earlier, let's have an example of a properly
designed system.



Glenn Williams
US WEST


"Y'er spookin' the cattle." - Curly
Newsgroups: comp.lang.c++
From: paul@sco.COM (Paul Jackson)
Subject: Re: Committee Members -> What do you think?
Organization: SCO Canada, Inc.
Date: Mon, 20 Jul 1992 15:03:41 GMT

In article <1992Jul17.194202.14981@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>Your definition of what a "standard" "is" flies in the face of the reality
>of the ANSI-C++ committees actions.

The committee does have the mandate to fix "clear" deficiencies in the
language. Most people feel that this included templates and exception
handling. Many people feel that it includes little else. 

>|Getting back to operator dot, it may or may not make it into this (or any
>|future) standard. If "almost everybody" implements it, or "almost everybody"
>|demands it or "almost everybody" agrees that it is a good idea then it will
>|"almost certainly" make it in. If not, the chances are lower.
>
>On the contrary "almost everybody" will have no say in this matter, as
>history has already shown.  On the contrary, a couple people on the 
>extensions committee will either support the idea, or talk it down, and
>that will be sufficient to get it on, or keep it off, the floor of the
>committee whole for a vote.

Oh, baloney. I assure you that of all the customers of vendor X's compiler
clamour for operator dot then vendor X WILL put it into their compiler.
Vendor X is then likely to try and get it into the standard. Or, if you
convince 50% + 1 of the committee members then it will go in (note that
Bjarne doesn't have to be convinced, he doesn't even get a vote).

>|Personally, I feel that it is just not too important an issue one way or
>|another
>
>Operator.() is only necessary if one is interested in having complete
>and safe "smart pointer", "smart reference", "smart array", "reference
>counting" classes etc.

Convince me that it is NECESSARY and I'll recommend that my companies rep
vote for it. By necessary, I mean that you CANNOT implement "smart" classes
without it.

>This issue has been discussed dozens of times before.  OPERATOR.() IS NOT
>A LANGUAGE EXTENSION -- IT IS A LANGUAGE REDUCTION -- IT IS A REMOVAL OF
>AN ERRONEOUS AND UNNECESSARY PIECE OF SPECIAL CASE LANGUAGE IN THE SPEC.

Wrong. It changes the existing language and hence is, by the definition
being used by the committee, an extension. All Humpty Dumpty arguments
to the contrary don't impress me.


Newsgroups: comp.lang.c++
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: Power Operator vs NANs
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Wed, 22 Jul 1992 15:16:49 GMT

In article 849@nazgul.UUCP, bright@nazgul.UUCP (Walter Bright) writes:
>I don't have the specs in electronic form. But they have been included in
>the latest ANSI C++ mailing.
>
>The additional operators are:
>	<	less
>	>	greater
>	<=	less or equal
>	>=	greater or equal
>	==	equal
>	!=	unordered, less or greater
>	!<>=	unordered
>	<>	less or greater
>	<>=	less, equal or greater
>	!<=	unordered or greater
>	!<	unordered, greater or equal
>	!>=	unordered or less
>	!>	unordered, less or equal
>	!<>	unordered or equal
>
>
>Unordered means one or both operands is a NAN.

Could someone summarize the rationale for introducing these new operators.
If arithmetic conforms to IEEE-754 then the existing comparison operators
should deal with unordered quantities.  You can view IEEE-754 as a collateral
standard: if a translator conforms both to the C++ standard and to IEEE-754
then IEEE-754 defines the behaviour of certain operators in circumstances
where the (as yet non-existent) C++ standard leaves them undefined.

	Chris Flatters
	cflatter@nrao.edu
From: dahl@odie.ee.wits.ac.za (Bradley Dahl)
Newsgroups: comp.lang.c++
Subject: Re: MATRIX C++ library - anyone????
Date: 31 Jul 92 08:21:48 GMT
Article-I.D.: odie.dahl.13
Organization: Wits Electrical Engineering (Novell Users).

.In article <Bs687E.75p@comp.vuw.ac.nz> Ivan.Murray@comp.vuw.ac.nz (Ivan 
.Andrew Murray) writes:

.>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
    ....
>|> There MUST be someone out there that knows of such a library....
>|> Please help,,
>|> Jens Markussen

>Could you *email* them to me as well please (I don't have FTP access)

>Thanks,
>Ivan.

Definitely!   I would also appreciate knowing of such a source.  Please 
Email me the FTP site address too.

Brad
Newsgroups: comp.lang.c++
From: krc@wam.umd.edu (Kevin R. Coombes)
Subject: Conversion operators and typedef names
Keywords: Microsoft C++ new error bug
Organization: University of Maryland, College Park
Date: Tue, 21 Jul 1992 16:09:17 GMT

As I was about to explain to someone that you couldn't supply a
conversion operator to a typedef name, it suddenly occurred to me that
I wasn't sure. So I tried it. And it worked. So I looked in the ARM
and it seems to be legal. (Derivation given below.) My question today is:
should you do it?

Here's an example to clarify what I mean. The ANSI C standard requires
implementations to provide the typedef time_t. It has to be an integral
type. The compilers I'm familiar with use either long or unsigned long
for this type. Now suppose you want to build a class to handle certain
operations on times. Should you provide a conversion operator like the
following:

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

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);

Any opinions?

	Kevin Coombes <krc@math.umd.edu>


PS Here's the promised derivation from the ARM:

conversion-function-name:
	operator conversion-type-name

conversion-type-name:
	type-specifier-list ptr-operator[optional]

type-specifier-list:
	type-specifier type-specifier-list

type-specifier:
	simple-type-name
	class-specifier
	...

simple-type-name
	complete-class-name
	qualified-type-name
	...

qualified-type-name:
	typedef-name
	...


Newsgroups: comp.lang.c++,comp.std.c++
From: rhbartel@watcgl.waterloo.edu (Richard Bartels)
Subject: Re: run-time type checking (was: Re: Covariant Types in Derived Classes)
Organization: Computer Graphics Laboratory, University of Waterloo, Ontario, Canada
Date: Sat, 25 Jul 1992 19:10:38 GMT

As long as the downcasting discussion is open again,
the example we are confronting which requires something like
that, we think, is the issue of input from disk.

I would love to have a solution that did not require the cop-out of
isA() and cast/convert.

Consider the classic "List" class and "ListNode" class.
ListNode is a base class, and assume there are two flavors
of derived node.  We write a List that contains a mix of
these nodes out to a file; now we want to read the List back
in and reconstruct it.

Can it be done without resorting to an isA() member function,
some member data to identify node type, and possibly some
casting/conversion?

What's the authoritative answer?

-Richard
From: mbrinn@bbn.com (Marshall Brinn)
Newsgroups: comp.lang.c++
Subject: c++ 3.1 vs. 3.0 vs. 2.2 ....
Date: 22 Jul 1992 13:44:30 GMT
Distribution: usa
NNTP-Posting-Host: bbn.com

Could someone please give (or point me to) a brief description of the language 
features that distinguish the different C++ release levels? That is,
what is the difference between 3.1 and 3.0, 3.0 and 2.2?

Thanks.

Marshall Brinn
-----------------
mbrinn@bbn.com
BBN Systems and Technologies

Xref: sparky comp.lang.c++:11282 comp.lang.c:11413
From: jkelly@oodis01.af.mil (Jerry Kelly)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: Result of spawn
Date: 21 Jul 92 14:58:20 GMT
Followup-To: comp.lang.c++
Organization: Hill AFB, Utah

oops..
Newsgroups: comp.lang.c++
Subject: Borland C++ 3.1 fails to conform to C++ Standard
From: j_ohearn@dsg4.dse.beckman.com ()
Date: 24 Jul 92 15:29:30 GMT
Distribution: world
Keywords: C++ Standard
Summary: Reference variables and pointers.


Note:  This posting is not my own; I am doing this on behalf of one
of my colleagues, Jack Walker.  However, I think he has a valid
argument.

I have been using a version of the following class which is adapted 
from an example in the Borland C++ 3.0 Programmers Guide (page 149):

class Vector
{
    double huge *data;
    unsigned long low, high;

    public:

    Vector ( unsigned long, unsigned long );
    ~Vector(){ delete[] data; }

    double& operator()( unsigned long i )
    {
        return data[i - low]; //Line that offends ver 3.1 but compiled without
                              //error under 3.0
    }
};

Vector::Vector(unsigned long L, unsigned long H)
{
    low = L;
    high = H;
    data = new double huge[H - L + 1];
}

The above class compiled and functioned successfully under version 3.0 
but under version 3.1 I receive the error message:
    "Reference initialized with 'double' requires lvalue of type 'double'"
which referred to the line I have indicated in the above class listing.

This contains no syntax error that I am aware of and is essentially given 
in various textbooks on C++ as a method for implementing 'safe arrays'.

I would appreciate any assistance regarding this problem.



Send any private responses to (I will make sure Jack gets them):
j_ohearn@dsg4.dse.beckman.com

Newsgroups: comp.lang.c++
From: wgunadi@IASTATE.EDU (Wiwih Gunadi)
Subject: Text file manipulation in C++
Reply-To: wgunadi@IASTATE.EDU (Wiwih Gunadi)
Organization: Iowa State University
Date: Tue, 28 Jul 1992 17:07:55 GMT

Hi, I am doing a program that manipulates a large text file.
How do I insert several characters only to the file without having to 
rewrite all of the file, also how to delete characters.

If someone has ever do something like this or have read it in a book, please
give me some hints.

Mail me directly to : wgunadi@iastate.edu , please....

Thanx
-Wiwih-
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: Thu, 30 Jul 1992 02:14:14 GMT

mat@mole-end.matawan.nj.us writes:

>In article <9220801.5026@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>> 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?
>
>> >> 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?
>
>It affects what version of overloads are applied to the variable/object
>and the confidence of the reader that the variables are/are not changed.

It does NOT affect what version of overloads are applies to the variable/object.
For example:

	fergus> cat > test.c
	int foo(int a) { return a; }
	int foo(const int a) { return -a; }

	fergus> CC test.c
	"test.c", line 2: error: the overloading mechanism cannot tell a int (int ) from a int (const int )

Furthermore the only reason why it might affect the confidence of the reader
that the variables are not changed is if the reader does not understand the
semantics of pass-py-value in C. (If this is the case then the reader,
not the program, is broken :-). Besides, the "confidence of the reader" is
a fairly dubious thing in general; this is very much a matter of style (ie.
"nitpicking").

Thus I still maintain that it IS just nitpicking.

-- 
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: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Borland charges before delivers
Date: 21 Jul 92 14:49:46 GMT
Article-I.D.: alice.23253
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ

In article <1992Jul21.002536.20968@thunder.mcrcim.mcgill.edu> leying@alpha (Leying Zhao) writes:

> I ordered BC++ 3.1 on June 21 (BEFORE THEIR SHIPPMENT BEGAN) and I
> have not get it now (today is July 20). But I get the BILL! It billed
> on June 24 throug Master Card. I called them again. A rep told me
> that I have 2 choices:  1) just wait. 2) cancel the order, they
> reverse the charge and reorder again. But I will lose my position on
> the waiting line. It sounds that I made a mistake!

You probably have a third choice:  call Master Card, tell them
that you have been billed for merchandise you have not yet recieved,
and ask whether you are really required to pay in advance.

I think the answer to that question varies from state to state,
but I would not be surprised to find that you don't have to pay.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Xref: sparky comp.lang.c++:11422 comp.lang.c:11529
From: sdarbha@ho12.eng.ua.edu (Subrahmanyam Darbha)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: A Question on masking
Date: 23 Jul 92 19:21:47 GMT
Organization: The University of Alabama, Tuscaloosa


           I need to convert a three dimensional identifier to a one,two or
three digit number.
I am doing it for converting a three dimensional pointer to a one dimensional   one .
I know for sure that it has got to do something with the masking.
Can somebody suugest me a way out of this
For Example what I have to do is find a unique number for each of three         dimensional Identifiers.
I need to find out a single unique number for each of all [1-999][1-999][0-3]
numbers.
Any help will be highly appreciated
Thanks a lot in advance

Subbu
  

-- 
It is from Darbha                                sdarbha@buster.eng.ua.edu
                                                   OFF : (205) 348 - 9289   
                                                   RES : (205) 750 - 0481
From: bradav@auto-trol.com (Brad Davidson)
Newsgroups: comp.lang.c++
Subject: Looking for a class expander tool
Date: 22 Jul 92 20:32:49 GMT
Organization: Auto-trol Technology Corporation
Originator: bradav@bradav


I am searching for a tool that will take a set of header files and for
each class definition expand it to comment in or include all the
inherited classes.

For example

Class A
{
protected:
    int A_data;
};

Class B
{
protected:
    int B_data;
};

Class C : public A : public B
{
    int C_data;
}

Through the class expander I get the following for Class C

Class C
{
    int A::A_data;
    int B::B_data;
    int C_data;
};

so that I can see all the inherited data and methods since in real life the
classes are not quite this simple.

Brad Davidson
From: rmd@quack.sac.ca.us (Robert M. Diamond)
Subject: Object Oriented Design Question
Followup-To: poster
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
Date: Wed, 22 Jul 1992 01:05:19 GMT

Hello,
	I am attempting to design a system which reads data in from a
file and writes it back to another file.  Data items can be of various
basic types, like number, string, date or time.  They can be read from
the file or calculated from other read or calculated data items.  They
can be stored in the database (in various ways) or marked for temporary
use only.  The scheme I have come up with is thus:  
Have a class "data_item" which can store itself or retrieve its value.
Have subclasses "numeric_data_item," "date_data_item, " etc. which
instantiate the ::store() and ::retrieve() functions.
	The problem is that the typed_data_item either needs to know how
to store itself in each possible way, or the storage_class has to know
how to store each possible type, or I must create classes for the
cartesian product of type and storage class.
	This is my first OOD project, and I would appreciate any ideas
that people can come up with.
	thanx,
	Robert Diamond
	+1 415 493-4122
From: kinne@delfin.com (Kinne Strong)
Newsgroups: comp.lang.c++
Subject: Re: classes referenced each in their declaration
Date: 22 Jul 92 19:23:26 GMT
Distribution: na
Organization: Foxglove Associates
X-Newsreader: Tin 1.1 PL4

mittle@watson.ibm.com (Josh Mittleman) writes:
: 
: Use references:
: 
: class Y;
:  
: class X {
:   Y& b;
: };
: 
: class Y {
:  X& d;
: };
: 
: You must initialize X::b in every constructor for X and Y::d in every
: constructor for Y, but otherwise everything should work just fine.  

Not really. To construct an X you must give it an already-constructed Y
for X::b. To construct this Y, you must give it an already-constructed X
for Y::d. To construct this X, you...

--
Kinne Strong
kinne@netcom.com
From: arthur@solomon.technet.sg (Arthur Sombrito)
Newsgroups: comp.lang.c++
Subject: Re: scope of typedef declaration within a class declaration?
Date: 21 Jul 92 10:56:13 GMT
Organization: National University of Singapore

casey@gauss.llnl.gov (Casey Leedom) writes:
: 
:   I'm working with SGI's C++ 2.1.1 which is based on AT&T's cfront 2.0.
: SGI's C++ promotes typedef declarations within class declarations to the
: global scope.  Moreover, it doesn't even let me access the typedef name
: via class-name::typedef-name.  This seems to be contrary to the C++ 2.0
: specification.  Section 10.4, Summary of Scope Rules, in the AT&T C++
: Language System manual even specifies:
: 
: 	``... These rules apply uniformly for all names (including
: 	  typedef-names (sec.7.1.3) and class-names (sec.9.1)) wherever
: 	  the grammar allows such names in the context discussed by a
: 	  particular rule. ...''
: 
:   Here's an example of what I'm trying to do:
: 
:    1	class foo {
:    2	    public:
:    3		typedef int bar;
:    4		bar x;
:    5	};
:    6	
:    7	main()
:    8	{
:    9		foo::bar i;
:   10		foo f;
:   11	
:   12		i = 1;
:   13		f.x = i;
:   14	}
: 
: SGI's C++ compiler complains about line 9 (getting confused about missing
: semicolons, etc.) and the only way I can make it work is if I change line
: 9 to read ``bar i;''
: 
:   Am I completely misconstruing the meaning of the scoping rules with
: regard to typedefs???
: 
: Casey

You got it right. It's just one of the specifications that cfront does not
adhere to.

Art