HDTenEightyP/NetNews huggingface dataset:
From: silvia@rcf.rsmas.miami.edu
Subject: Re: DGROUP exceeds 64K
Reply-To: silvia@rcf.rsmas.miami.edu
Organization: RSMAS
Date: Mon, 28 Sep 92 02:13:34 GMT

In article <1992Sep25.131508.243@mble.philips.be>, stern@mble.philips.be writes:
>In article <1992Sep24.044904.15756@sol.UVic.CA>, dchivers@engr.UVic.CA (David  Chivers) writes:
>> 
>> I am working on a rather large project using Borland C++ 3.1. For various reasons
>> we are forced to use the large memory model.
>> 
>> The problem is the linker generates the error DGROUP exceeds 64K.  I have tried a
>> number of different approaches to solving this problem but I'm not having any
>> success.  I'm using the compile flag -Ff=10 to force the the data to _FAR_DATA.
>> The Borland manuals describe the data segment for the large model as a single
>> 64K block.  In part of the document, they imply that this is set in stone and
>> cannot be changed. Yet, they also imply that this can be manipulated and different
>> data segments/groups can be defined using the -z flags.  I've also tried -Vf
>> to remove the virtual tables from the data segment but this causes a number of other
>> problems.  The Borland manuals also suggest that for each huge function the data 
>> segment is different.  I've tried defining one of my functions as huge but this
>> makes no difference. The assembler code shows that it is using DGROUP as the
>> data segment.
>> 
>> 
>> Here is a very simplified version of my code.
>> 
>> void junk_fn( void )
>> {
>>    junk_stuff();
>> 
>>    junk_class* junk_array[] =
>>    {
>>       new junk_class( p1, p2, "HERE IS JUNK STRING 1" ),
>>       new junk_class( p1, p2, "HERE IS JUNK STRING 2" ),
>>       .
>>       .
>>       .
>>       new junk_class( p1, p2, "HERE IS JUNK STRING n" ),
>>    }
>> 	
>>    more_junk_stuff();
>> }
>> 
>> The problem seems to be with the strings always being put into the DGROUP.
>> 
>> Any suggestions or comments would be greatly appreciated.
>> Thanks.
>> 
>> Dave
>> 
>
>I had exactly the same problem and, after calling the support, I found
>a solution by myself. Just use the '-zS' flag to compile some of your
>modules (the biggest ones) with their data in another segment (any name).
>It works for me for a big project with TurboVision.
>
>
>--  Marc Stern  <stern@mble.philips.be>
Using that will only cause a warning with the linker and will cause the program
to crash when runned. The warning is "Segment DGROUP is in two groups:DGROUP
and group2". Unless there is something else that i missed in that message you
will get this warning.



              Manolo

Newsgroups: comp.lang.c++
From: anikzad@symbol.com (Arman Nikzad)
Subject: K&R C to ANSI-C Convertor
Organization: Symbol Technologies, Inc.
Distribution: All
Date: Mon, 5 Oct 1992 13:04:05 GMT

Newsgroups: comp.lang.c
Subject: K&R to ANSI convertor.
Summary: 
Expires: 
Followup-To: 
Distribution: ALL
Organization: Symbol Technologies, Inc.
Keywords: 

Hi everybody, 
             I am faced with a small problem. we are moving towards 
ANSI C/C++, but have tons of K&R style code which need to be converted
to the ANSI format. I was about to write a little program to do this,
then I thought there must be a program that can do this (and do it 
right). If anybody knows of such progam(s) please let us know. 

Thankx in advance !..



P.S. I know some compilers do take both styles, but that is not what we are
     after.
From: Ramon.Pantin@mailbox.bison.mb.ca (Ramon Pantin)
Newsgroups: comp.lang.c++
Subject: Re: C++ Style
Date: 25 Sep 92 07:30:21 GMT

Organization: Tandem Computers, Micro-Products Division

In article <1992Sep23.140340.3641@ultb.isc.rit.edu>,
mpk9172@ultb.isc.rit.edu (M.P. Kirby) writes:
> 
> I'm an old C hack trying to learn this new fangled C++ thing.  In reading
> stroustrups book, I see that C++ Allows a variable to be declared anywhere.
> 
>	... examples deleted ...
> 
> Is there a stylistic advantage for puting the declarations closer to where
> I use them? 

The rationale behind this feature is that with the original C rules
there would be scenarios where a variable of class type would have to be
declared and initialized by a default constructor because at that
point in the code the proper value to initialize the variable
is not available.  A subsequent assignment of the value would
cause an invocation of the assignment operator.  The costs of the
construction and the later assignment might be too expensive for
some clases.

For example:
	// C declaration rules
	foo()
	{
		C	c;		// call default constructor
		...;			// some stuff
		c = ...;		// valu dependent on stuff
					// call assignment operator

Instead of:
	// C++ declaration rules
	foo()
	{
		...;			// some stuff
		C	c = ...;	// valu dependent on stuff
					// call non-default constructor

Ramon Pantin

 * Origin: The Electronic Mailbox (1:348/7.0)
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Problems with Abstract base class and pure virtual functions.
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 1 Oct 1992 15:05:22 GMT

In article <CARNEY.92Sep29085615@rocky.rational> carney@rocky.rational (Mike Carney) writes:
>
>In article <8-+p9xr.kmr@netcom.com> kmr@netcom.com (KMR) writes:
>   I could not find an answer to my problem  of abstract base class
>   and pure virtual functions in ARM, any help will be appreciated.
>
>   Consider the following:
>
>   class A { public :
>	   virtual void foo1() = 0;};
>
>   class C : virtual public A {};
>
>   class B : virtual public A {public :
>	   virtual void foo1() {cout<<"I'm B::foo1\n";}};
>
>   class D : public B, public C {};

>   When compiling the above on SUN 2.1 Cfront, the compiler fails 
>   informing me that D is an abstract class and thus cannot be "newed"
>
>I think that your real problem here is that class C does not have an
>implementation of foo1(). If a class is an abstract class (i.e. any of
>its virtual members is declared line foo1() and foo2() in class A
>above), then all of its derived classes *must* have implementations of
>those virtual member functions that were declared abstract. 

	No, only the most derived class D must have implementations.
The function B::foo1() dominates A::foo1(), therefore all virtual
calls

	d->foo1();
	c->foo1();
	b->foo1();
	a->foo1();

bind to B::foo1(). Give A::foo1() a dummy body instead of the pure
specifier to test this out. See: A::foo1() cannot
be virtually called.

	It follows D is concrete. It has no holes. Whether
A::foo1 is pure or not should make no difference (since
it cannot be called).

	There is a section in the ARM dealing with the sibling
call mechanism. It is the basis of c++ "mixin" style.
Its operation depends on the name dominance rule (also discussed),
which is claimed to be the basis of polymorphism in C++.
It is unfortunate the ARM example did not use pure virtuals
in the base class in the example.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: declare keyword, type inference
Date: 5 Oct 92 12:10:15 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

jbn@lulea.trab.se (Silly Me) speaks:
: ark@alice.att.com (Andrew Koenig) writes:
: : 
: : 	void foo() {
: : 		auto x = 3.5;	// x would be type double
: : 		auto y = x;	// ditto y
: : 		auto n = 70000;	// n would be int or long,
: : 				// depending on the machine
: : 	}
: : 
: : But we can't do this because C already requires x, y, and n to be int in
: : the declarations above and I don't think we can get away with breaking
: : C compatibility here.
: 
: Why not?
:
: During a phase-out period, such expressions where the type would be
: "int" in C, but is different in C++, could generate warnings, and
: later become errors.

Andrew is of course right.  It would be impossible for
the compiler to know if those statements were indeed old
"default int", or new "inferred type" declarations.

Sorry 'bout that.
-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
From: david@csource.oz.au (david nugent)
Newsgroups: comp.lang.c++
Subject: constructors & sizeof in C++
Date: Fri, 02 Oct 92 17:59:31 +1000
Reply-To: david@csource.oz.au
Organization: Unique Computing Pty Ltd, Melbourne, Australia


Is this sort of constructur legal/advisable?

 class Foo
     {
     private:
         int mem1;
         int mem2;
         char mem3[10];
         .
         .
         .
     public:
         Foo (void);
         .
         .
         .
     };

 Foo::Foo (void)
 {

     memset (this, 0, sizeof(Foo));          // Or bzero()
     .
     .
 }


Is sizeof(Foo) guaranteed to be the size of the structure containing the
declared object's non-static data?  Does the result of sizeof() change
if there are any virtual functions in a base class?  Or is it 'safer'
to declare a structure to contain the members to initialse, and just
memset/bzero those?

I also assume sizeof() also takes into account the size of base class
non-static members?


Apologies if this is an FAQ, but I have 4 weeks of news.answers on-line,
and the c++ FAQ isn't there, and I've not seen the question raised since
I started reading this group.



..............................................................................
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.
Newsgroups: comp.lang.c++
From: sriram@tcs.com (Sriram Srinivasah)
Subject: Re: Persistance Problem Solved by Memory-Mapped Files?
Organization: Teknekron Communications, Inc
Date: Tue, 29 Sep 1992 15:49:38 GMT

In article <d8_p1zq.feustel@netcom.com>, feustel@netcom.com (David Feustel) writes:
|> I'm wondering whether the problem of persistant objects could be
|> solved by use of memory-mapped files to store the C++ data structures
|> used by C++ programs. Comments?
|> -- 
|> Dave Feustel N9MYI <feustel@netcom.com>
|>  
|> [.sig on vacation]


Yes, most definitely. Check out the paper on memory mapped databases in
pub/uDatabase/POS5.dvi from watmsg.waterloo.edu.

Sriram
(sriram@tcs.com)
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Access to file descriptor within fstream class?
Organization: TauMetric Corporation
Date: Tue, 6 Oct 1992 16:15:19 GMT

morss@ssd.kodak.com (Charlie Morss) writes:


>I recently asked a question in regard to record locking using
>the fstream class. Steve Clamage replied and suggested that
>I derive a class from fstream called lfstream in which I could
>then have a lock and unlock member function. Now the question
>is how do you get the file descriptor from the fstream class? 

Check <fstream.h>.  Class filebuf usually has a member function
fd() which returns the file descriptor.

This is all rather specific to Unix-like implementations.  If you
are trying to do file locking on a radically different system,
there may be slightly different functions.  Presumably the filebuf
class provides some way to get at the underlying file in a way
consistent with the file locking routines.

Example:


#include <fstream.h>

main()
{
    fstream f("foo.bar", ios::in|ios::out);

    // use fstream::rdbuf() to get the filebuf
    // then filebuf::fd() to get the file descriptor
    cout << "file descriptor = " << (f.rdbuf())->fd() << endl;

    return 0;
}
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: operator@julian.uwo.ca (Operator)
Newsgroups: comp.lang.c++
Subject: problem with format of while, for, if
Date: 28 Sep 92 14:49:35 GMT
Organization: University of Western Ontario, London


what would be the correct format of the following:


while ( condition )
   {
   for ( condition )
      {
      if ( several conditions )
         {
         if ( condition )
           {
           statement;
           statement;
           }
         if ( condition )
           {
           statement;
           statement;
           }
         if ( condition )
           {
           statement;
           statement;
           }
         }
      }
    statement;
    }



can you please show me the correct format for this, because the program hangs on the first if statement (several conditions) and does not continue after that!!!

Your help would be GREATLY APPRECIATED!!!!!!

Thanks!!!


            
Xref: sparky comp.lang.c++:14342 comp.realtime:1134
From: dsr@bnr.co.uk
Newsgroups: comp.lang.c++,comp.realtime
Subject: 80188 Emulators
Date: 30 Sep 92 17:03:30 GMT
Reply-To: dsr@bnr.co.uk ()
Organization: BNR Europe Limited, London Road, Harlow, Essex, GB

Hi,

I'm looking for an 80188 emulator for C++ work that runs on Unix
platforms, preferably Suns.  I only know of one which runs on a PC.
Are there any others?
   Dave Riches
   Email:  David.S.Riches@bnr.co.uk
   Smail:  BNR Europe Ltd, London Road,
           Harlow, Essex. CM17 9NA.  England
   Phone:  +44 (0)279-402496
   Fax:    +44 (0)279-451434
Newsgroups: comp.lang.c++
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: declare keyword, type inference
Date: 5 Oct 92 00:19:15 GMT
	<23794@alice.att.com>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: ark@alice.att.com's message of 4 Oct 92 14:08:17 GMT

In article <23794@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

   In article <TMB.92Oct3213654@arolla.idiap.ch> tmb@idiap.ch writes:

   > C++ made a decision to go with overloading. Overloading doesn't
   > coexist well with type inference.

   But this isn't type inference in the sense you mean. Rather, it is
   an attempt to exploit the fact that in C++ it is always possible to
   determine the (static) type of an expression, so why not allow a
   variable to be defined as having the same type, whatever it is?

   In other words, when writing something like

	   declare x = y;

   we are not allowed to infer anything about the type of y.  We are
   just saying that whatever type y has, x should have the same type.

It's not so clear to me that in the presence of a "declare" keyword,
you couldn't get circular dependencies. For example, what about:

	declare x = f(&x);

I will admit, however, that this is probably less of a practical
problem in C++ than I had originally thought, but it might cause
all sorts of problems when you try to pin down the details.

   The question therefore comes down to whether it's worth adding a
   new keyword and, if so, exactly what the rules for it should be.

Well, maybe as templates come into more widespread use, people will
discover a need for this. Currently, personally, I find that declaring
the types of my variables has been one my smallest pet-peeves with C++
syntax...

				Thomas.

PS: This reminds me, though: will template typedefs be allowed
eventually? I mean something like the following:

	template <class T> typedef Array<Array<T> > Foo;
From: osinski@AVENTINO.CS.NYU.EDU (Ed Osinski)
Newsgroups: comp.lang.c++
Subject: Re: pointer to function vs. pointer to member function
Keywords: pointer, member function
Date: 29 Sep 92 18:02:35 GMT
Reply-To: osinski@cs.nyu.edu
Distribution: comp.lang.c++
Organization: New York University

In article <37167@uflorida.cis.ufl.edu>, asher@qtp.ufl.edu (Robert L. Asher) writes:
|> I've been writing some code in C++ and have run into a problem.  I have a 
|> rootfinding function which I use for any function, by sending the pointer to
|> that function to my FindRoot function.  The problem is that now I'd like to use
|> a function which is in a class ie.) a member function.  I've tried various ways
|> to send the pointer to my function FindRoot but have as yet been unsuccessful.
|> Do I need to overload the FindRoot function to take pointers from member
|> functions.... And if I do will I have to overload it for every different class
|> that I make?  This would seem unnecessarily complicated since all I want to do
|> is sent the pointer for a double that happens to be a function/member function
|> to FindRoot.  Any help will be greatly appreciated.  Below is the code which
|> works for any function as long as it's not a member function.

... code deleted ...

A regular member function is not the same as a regular, non-member function,
because the member function has an implicit "this" pointer.  To call a
non-member function, you say

	f(...params...)

To call a (non-static) member function, you say

	obj.f(...params...)  // or
	obj_ptr->f(...params...)

Clearly non-static member functions and non-member functions are not the same
beast, and you cannot use one where the other is expected.  In your case, I
gather that your member function never uses the "this" pointer.  If this is so,
then it may be made a static member function by preceding the declaration with
the word static.  A static member function is a member function that has no
"this" pointer, and so it can be used wherever a non-member function is
expected.  To call a static member function, you say

	class::f(...params...)

See Stroustrup, pp. 165-6, 548-9, any good C++ book, or the C++ FAQ.  Look for
the question:

"How do I pass a ptr to member fn to a signal handler,X event callback,etc?"

|> -- 
|> Robert L. Asher          | 
|> Department of Chemistry  | 
|> University of Florida    | 
|> asher@qtp.ufl.edu        | 

-----------------------------------------------------------------------
 Ed Osinski                  |
 Computer Science Department |
 New York University         |           This space for rent
 E-mail:  osinski@cs.nyu.edu |
 Voice:   (212) 998-3515     |
 Fax:     (212) 995-4123     |
-----------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: s36474r@kaira.hut.fi (Mikko Malinen)
Subject: Segmentation fault
Organization: Helsinki University of Technology, Finland
Date: Mon, 5 Oct 1992 10:06:13 GMT

I compiled a C++ program with g++ compiler in IBM 6000.
Could anybody tell me why the runtime error "segmentation fault"
occurred? The compiler did not give any error messages.

Xref: sparky comp.lang.c++:14532 comp.std.c++:1310
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: The concept of templates considered ill designed
Date: 5 Oct 92 15:57:54 GMT
Article-I.D.: alice.23808
Organization: AT&T Bell Laboratories, Murray Hill NJ

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

> As are currently implemented templates, you don't know
> anything about the actual type at compile-time.
> So that no method calls or variable accesses can be compiled
> for any variable of 'template type'.

But you still haven't answered my question.

My question was: what reason do you have to believe that
adding inheritance constraints would solve the problem?

In thinking about the answer, don't forget about inline functions.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: mittle@siena.watson.ibm.com (Josh Mittleman)
Subject: Re: can != be used in compound if
Date: Wed, 30 Sep 92 17:57:16 GMT
Organization: IBM T. J. Watson Research

cnhasan@casbah.acns.nwu.edu (Nirmal Hasan) writes:

>if (rnum != number_set[1] && rnum != number_set[2] && rnum != number_set[3])

>is this if statement correct because the computer has been hanging on it

> Try
>   if ((rnum != number_set[1]) && (rnum != number_set[2]) && 
>       (rnum != number_set[3]))

> In other words, the problem may be because you did not use parenthesis
> around each of the conditions.

That should not be so: != has higher precedence than && (Lippmann, C++
Primer, p.81).  Adding parentheses can't hurt, and I think it makes the
code more readable, but it should not matter in this case.  

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
Newsgroups: comp.lang.c++,comp.std.c++
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: Conceptual Constness
Originator: pete@genghis.borland.com
Keywords: const, const member, lazy
Organization: Borland International
Date: Thu, 1 Oct 1992 16:22:38 GMT

In article <1992Sep30.190912.21322@watson.ibm.com> mittle@siena.watson.ibm.com (Josh Mittleman) writes:
>pete@genghis.borland.com (Pete Becker) writes:
>
>> I take a different view of this.  An array is characterized by indexed
>> access.  It can be implemented with a list, it can be implemented with a
>> vector, it can be implemented with a btree, and it can be implemented in
>> many other ways.  But regardless of the implementation that's chosen,
>> operator[] is always available, and always has the same semantics.
>
>You are confusing terminology: An array is an implementation that can be
>used to support a variety of abstract data structures, including a vector,
>a stack, a queue, a dictionary, a heap, etc.  

	No.  I'm not confused at all.  I used "array" and "vector" in exactly
the way that I meant to, and in a context in which their meanings are perfectly
clear.  To the best of my knowledge, there is no general agreement as to which
is which here, so I will continue to take pains to make my meaning clear,
rather than rely on obscure conventions.
	-- Pete
Newsgroups: comp.lang.c++
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Subject: Re: static member and access control?
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia
Date: Mon, 5 Oct 1992 20:20:45 GMT

LANG@nvdv01.ind.e-technik.uni-stuttgart.de (MARTIN LANG) writes:
: 
: Following a short class declaration with a private static field of an
: enumaration type. The enumaration is also declared private. The question
: now is: is the initialization illegal or not.
: 
: class Test
: {
: 	private:
: 		enum E1 { a,b};
: 		static E1 e;
: };
: 
: 
: E1 Test::e=Test::a;

It should be 

Test::E1 Test::e = Test::a; // 1

or

Test::E1 Test::e = a; // 2

ARM p.150 Sec. 8.4 says, "An initializer for a static member is in the
scope of the member's class," and 
ARM p.180 Sec. 9.4 says, "Static members obey the usual class member
access rules except that they can be initialized."

The above two quotes from ARM let us define private and protected
static data members in file scope.

-Sekar