HDTenEightyP/NetNews huggingface dataset:
From: srinivas@lgc.com (Manapragada Srinivas)
Newsgroups: comp.lang.c++
Subject: Constructor arguments for template classes
Date: 20 Aug 92 22:41:11 GMT
Organization: Landmark Graphics Corporation


Hi,

	I  have a question about templates -

	Suppose I design a Vector template class as follows

	template <class T>
	class Vector
	{
	public:
		Vector( int size );
		// ... destructors, private members etc.

	}

	a. Does Vector< Vector<int> > make sense?

	b. If so how do I initialize it?

		g++ is not happy about
			Vector< Vector<int> > vec(10);

		nor does it accept
			Vector< Vector<int> > vec(10, 10);

	  both the times it complains about too few arguments for the
	  constructor.


	Any help on the above would be greatly appreciated.

Thanks in advance,

Srinivas
--
Yonder, beyond the event horizon!
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Proposal: auto T&
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 20 Aug 1992 20:41:25 GMT

pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:

>In <1992Aug19.234913.622@tfs.com> eric@tfs.com (Eric Smith) writes:
>
>>Much recent discussion about destruction of temporaries suggests a
>>better way to solve the whole problem, and to allow returning references
>>to temporaries from functions.
>
>>auto String& stringfunction(const String& input)
>>{
>>   // Calculate/create a new temporary or named automatic String
>>   // and return a reference to it.
>>}
>
>>The "auto" in the function return value type tells the compiler to allocate
>>the space for that automatic in the stack frame of the caller, instead of
>>the stack frame of the called function.
>
>*****>	It's not reentrant.
>
>	String a, b, c;			// also assume + has been overloaded
>	// ...
>	a = stringfunction( b ) + stringfunction( c );

Huh?

What do you mean by "it's not reentrant"? Why not?

-- 
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: destruction of temporaries
Date: 22 Aug 92 04:15:51 GMT
Article-I.D.: alice.23523
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <rmartin.714434539@thor> rmartin@thor.Rational.COM (Bob Martin) writes:

> In any situation where a
> pointer or reference to a temporary is being taken, the compiler
> should complain.

Suppose we have class String with a member function called `size'
that returns the number of characters in the string.  If f is a function
that yields a String, do you really want to prohibit f().size()?
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: How to hack c++ into doing late binding ?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 13 Aug 1992 15:10:03 GMT

In article <1992Aug11.000613.6607@leland.Stanford.EDU> kocks@jessica.stanford.edu (Peter Kocks) writes:
>Here's a qestion for all you c++ fanatics.
>
>I want my application to support late binding.  By that I mean:
>
>I want to write some code and compile and link it together so I have
>my application.  At some later time, I want to be able to give the
>user of my application a new version of an object (or should I say
>virtual class) already in the excecutable code.  I want the user to be
>able to simply add the new definition for that class of object to the
>excutable without needing to recompile the thing.
>

	C++ has no run-time system (except for new/delete).
Instead it relys on the operating system.
What you need to do 'dynamic linkage' is a decent operating system.
Windows and OS/2 do exactly what you want. I do it, it
works superbly. So your problem is that Unix is a brain dead
operating system :-) 

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: tom@fokus.gmd.de (Tom Pfeifer)
Subject: Turbo Vision Color Palette
Organization: GMD-FOKUS, Hardenbergplatz 2, 1000 Berlin 12, Germany
Date: Fri, 14 Aug 1992 11:10:11 GMT


I would appreciate some help with saving the color palette in Turbo Vision.
As I already learned the palette string differs from C style having the length
stored in the first byte.

I tried the following in a member function inheriting getPalette() from TApplication:

char myPalString[256];
TPalette * xx = (TPalette *) myPalString;
*xx = getPalette();

According to TFM the overloaded operator = should copy the string. All I get is 4 bytes
for the complete application. Can't be all.
When I try:

getPalette() = *xx;
redraw();

the colors are messed up completely.

Tnx for help
Tom

BTW, does getPalette() work with all three palettes (color, mono, b/w) or do I have
to switch the modes before access?
Tom
Newsgroups: comp.lang.c++,comp.object,comp.databases
From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: A POET Tutorial
Keywords: OODBMS, C++, POET
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 13 Aug 1992 05:05:46 GMT

I have a couple of questions regarding Jonathan Robie's posting:

----------------------------------------------------------------------

>    main ()
>    {
>      PtBase    objbase;
>    
>      objbase.Connect ("LOCAL");    // Connect to the server
>      objbase.Open ("test");        // Open the database
>
>      Person    *man = new Person(objbase);
>      man->Store();
>    
>      objbase.Close();    
>      objbase.DisConnect();
>      delete man;
>    }

Why aren't Close() and DisConnect() automatically called by the
destructor?

----------------------------------------------------------------------

>    PersonAllSet*    allPersons = new PersonAllSet("objbase");
>    Person*    thisPerson;
>
>    allPersons->Seek(0, PtSTART);
>    while (allPersons->Seek (1, PtCURRENT) == 0)
>    {
>    allPersons->Get(thisPerson);
>    thisPerson->DoSomething();
>    allPersons->Unget(thisPerson); // deletes the object if nobody 
>                                  // else is using it.
>    }
>    delete allPersons;
>
>[...]
>Note that we call Unget() when we are done with the object.  Every 
>object you read takes up memory, so you should get into this habit.

Again, weren't destructors invented so that we wouldn't have to rely
on programmers habits?

Also, is there any particular reason why allPersons is dynamically
allocated in this example? Wouldn't it be simpler and more efficient
to just use a local (automatic) variable?

-- 
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: Garbage Collection for C++
Date: 17 Aug 92 23:51:27 GMT
Organization: Microsoft Corporation

In article <1992Aug13.151749.15679@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|	GC pointers are like *ordinary* C++ classes, not GC classes.
|If GC objects were allowed on the stack, they would have to be
|copied when the lexical scope was exited if there were still
|existant pointers to them. So why not just allocated them
|on the GC heap in the first place?

For the same reason that in today's C++ why all objects are not allocated
on the heap.  Namely because the vast majority of objects do not survive
the lifetime of the scope of where they are created.  Therefore, a 
strategy where all objects are created first on the stack, and then
evacuated if and only if they survive the scope, would be faster than creating
everything on the heap.  An interesting variation on this idea would be
to change our computers from being stack-based to being fifo-based.
From: perry@isgtec.com (Perry Lee)
Newsgroups: comp.lang.c++
Subject: Real World Experience with C++
Date: 12 Aug 92 19:37:18 GMT
X-Newsreader: Tin 1.1 PL4


Request For Information
-----------------------

We are about to embark on a large software project that will constitute a
key component of future products to come.  One of our options is to
use C++ as the implementation language.  Unfortunately, we have had little
experience using the language and its environment, so we aren't sure
whether this may be a good decision or not.

If anyone out there in Netland has developed large projects with C++,
we would appreciate hearing about your experiences and recommendations
in this world.   Points of particular interest are:

   - What has it bought you?  (Not what is it SUPPOSED to buy you.)

   - Learning time?  This is an estimated 10 (hu)man-year project
     and will be staffed by experienced C programmers (5+ years).
     What is it going to take to get people to thinking C++ instead
     of traditional C?

   - Maturity of C++ development environments?  What tools are needed
     and/or are essential?  We are presently using public domain tools
     such as Imake and CVS for our C product development.  (It seems as
     though a native C++ debugger is an essential).

   - C and C++ co-existence?  This new software will constitute only a
     piece of larger products that follow.

   - C++ and X/Motif co-existence?  The software is intended for use
     in an X/Motif environment.

Please reply by E-mail.  Thanks in advance!

--
Perry Lee                                  Phone: (416) 672-2100
ISG Technologies                           Fax:   (416) 672-2307
3030 Orlando Drive                         UUCP:      perry@isgtec.uucp
Mississauga, Ontario, Canada, L4V 1S8      Internet:  perry@isgtec.com
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: destruction of temporaries
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 21 Aug 1992 01:07:55 GMT

In article <1992Aug19.111836.25070@lth.se> dag@control.lth.se (Dag Bruck) writes:
>In <comp.lang.c++> tmb@idiap.ch writes:
>>The properties of temporaries are no different (and no worse) than the
>>properties of automatic variables: pointers to them become invalid
>>when the object disappears.
>
>I think there is a major difference.  The programmer controls the
>scope of automatic variables and hence their lifetime.  Temporaries
>are created by the compiler (possibly because of ill-advised
>programming techniques) and the programmer has no control over their
>lifetime.
>
>The language does not specify under what circumstances temporaries are
>created, and I'm willing to accept that, but it should at least
>specify their lifetime in expressions that potentially create
>temporaries.
>
>Given the deliberations for and against different models [no details
>given] I would probably prefer destruction at greatest enclosing
>expression, 

	Do you mean the next semicolon? I think thats what
you just said isn't it?

>with the additional constraint that temporaries created in
>one "arm" of a conditional expression are destroyed at the end of that
>conditional expression.

	As a matter of interest, what is the status of

	(a<b ? a : b )=1;

If a and b were just integers, they would need to be construed as
lvalues for the above to make any sense. But that is not
true for classes where the concept of lvalue is not so well
defined. It is possible if not sensible to assign a value
to a temporary class object and obtains a persistent
result through side effects. Because assignment has no
special status for class objects.
>
>With respect to difficulty of implementation, in particular combined
>with exception handling, it would probably pay off to look at existing
>implementations (I can think of HP and IBM) before making any judgements.

	Desstroying temporaries at the right time seems not so hard.
Defining the right time is harder (if not impossible without GC).
And making exceptions work is harder still (since RTTI is required
in their present form)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: iscooibc@nuscc.nus.sg (Beng Chin)
Subject: Actions not found error!
Organization: National University of Singapore
Date: Fri, 21 Aug 1992 10:15:47 GMT


Hi,

I would like to add a translation (actually to overide) which
would cause a widget to activate a callback when selected.

However, when I run the program, it always give me a run-time
error of

Warning: Actions not found: selectCallback.

This is how I use the WidgetAction:

action = new WidgetAction();
action->addTranslate( <a widget> );

I am using C++ with Motif. Appreciate help
of any kind. Thanks!

KC Phua
National U. of Singapore

---------------------- cut here ------------------------

WidgetAction Class
------------------
:
:
:
void WidgetAction::selectCallback( Widget w, XEvent *event,
	XtPointer clientData ) {
	WidgetAction *obj = (WidgetAction *) clientData; 
	obj->select( w, event );
}

void WidgetAction::select( Widget w, XEvent *event ) {
	...................
}

void WidgetAction::addTranslate( Widget w ) {
	static char defaultTranslations[] = 
	"None<Btn1Down>: selectCallback()";
    static XtActionsRec actionsTable[] = {
	{ "select", (XtActionProc) &WidgetAction::selectCallback },
	};
    XtTranslations trans_table;
    XtAddActions(actionsTable, XtNumber(actionsTable));
	trans_table = XtParseTranslationTable(defaultTranslations);
	XtVaSetValues( w,
				   XmNtranslations, trans_table,
				   NULL );
	XtOverrideTranslations(w, trans_table);
}
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Newsgroups: comp.lang.c++
Subject: Re: Return value for the constructors.
Date: 19 Aug 92 23:19:26 GMT
Article-I.D.: sunb10.1992Aug19.231926.28218
Distribution: usa
Organization: University of Illinois at Urbana-Champaign

In <1992Aug19.175852.38459@watson.ibm.com> mittle@watson.ibm.com (Josh Mittleman) writes:

>pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:

>*****>	No; the allocator new() is returning zero, not the constructor.
>> 	Also, if the ctor further allocates it's own stuff, there is 
>> 	currently no clean way of returning that fact to the caller--
>> 	new() will return success, i.e., non-zero.

>Sure there is: Overload operator new().  For example, give your class a
>static status flag.  operator new() sets it to 1, then calls ::new() to
>allocate the object.  Your constructors make whatever internal checks they
>need, and set status to 0 if there is a problem.  Then, operator new()
>returns a pointer to the new object or 0, depending on the success of the
>process.  From the users point-of-view, it simply looks like a normal call
>to new().

*****>	Clever...but it's not reentrant.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.lang.c++
Subject: Re: linkage specification and const objects
Date: 15 Aug 92 14:59:21 GMT
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Followup-To: comp.lang.c++
Distribution: gnu
Organization: Prifysgol Cymru, Aberystwyth

On 13 Aug 92 17:41:57 GMT, hassey@matrix.rtp.dg.com (John Hassey) said:
Followup-To: comp.lang.c++

hassey> So g++ wants something like this to be happy:
hassey> 	extern "C" extern const int a;
hassey> But cfront doesn't like that at all.
hassey> It looks to me like g++ is wrong on this one.

No, it's actually correct. extern "C" does not change the linkage of an
object. The 'extern' in it is just another example of the remarkable
keyword overloading of C++.

hassey>		extern "C" const int a;
hassey> is a declaration not a definition (7.4). But

No, the opposite. It is the definition of a constant 'a' which is
exported using "C" conventions. Just ignore the presence of extern "C".
The language in the ARM on this may be imprecise, but the general
principle stands.

hassey>		extern "C" { const int a; };
hassey> Is a definition, so the error is justified on this, and cfront
hassey> 2.1 does give an error.

extern "C", with braces or not, does not confer extern linkage by
itself. Indeed this is a little known thing.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
Newsgroups: comp.lang.c++
From: jes@grendel.demon.co.uk (Jim Segrave)
Distribution: world
Subject: Re: (SUMMARY - no replies!) INDENT for C++ ?
X-Mailer: cppnews $Revision: 1.14 $
Organization: None
Date: Fri, 21 Aug 1992 21:24:13 +0000


In article <1992Aug20.141202.5265@bradford.ac.uk> T.D.G.Sandford@bradford.ac.uk (TDG SANDFORD) writes:

> In article <1992Aug11.145758.15266@bradford.ac.uk> I wrote:
> >Is there a version of the (Unix) indent program which will work on C++
> >programs. The versions I've used all work only on std. C, and get upset
> >by certain C++ syntax (especially // comments)
> >
> >I am particularly interested in MSDOS versions, but Unix source would
> >probably do (eg GNU).
> >
> >Reply by e-mail if possible, I will post a summary in about a week's time.
> >--
> I got no replies, so I guess the answer to my original question was no :-(
> ---
> Thomas Sandford | t.d.g.sandford@bradford.ac.uk
I have (somewhere buried on some old backup discs) something called
indentpp - I beleive it was a rework of gnu indent, allegedly for C++
and C. I looked at porting it to Turbo C at the time, but since I
haven't actually been doing much C++ programming, I stuck with the C ony
version of indent which I already had modified to include some personal
quirks of my own. I didn't respond to your post since I assumed that
there's probably a more recent version someone would tell you about. I
beleive it came from comp.sources. If you are really stuck, mail me and
I will try to dig it out. I can't say what it was like, since I never
built it - I suspect the only documentation is in the source itself.
From some recent work I've been doing with other Unix based utilities, I
would recommend using djgcc (the DOS port of gcc) if at all possible,
since porting to this is usually a matter of hours compared to several
days to shoehorn these prgrams under a 16 bit compiler. Of course, you
have to use a [34]86, but they are getting cheap these days. 
--
Jim Segrave (Segrave Software Services)     jes@grendel.demon.co.uk

Newsgroups: comp.lang.c++
From: eric@tfs.com (Eric Smith)
Subject: Re: Garbage Collection for C++
Organization: TFS
Date: Sat, 15 Aug 1992 01:52:37 GMT

In article <TMB.92Aug14130323@arolla.idiap.ch> tmb@idiap.ch writes:
>What "hits"? In all the cases that I have looked at, the GC overhead
>has been _smaller_ than the overhead of explicit memory management in

Explicit memory management functions have traditionally favored memory
economy over speed.  That was because memory was very expensive.  But
now that memory prices have fallen through the floor, e.g. from $4000
per megabyte in 1983 to $25 per megabyte in 1992, it no longer makes
much sense to waste cpu time to save memory.

One easy trick to get around the slowness of obsolete memory management
functions is to allocate memory in bigger chunks and then parcel it out
to individual objects using the fastest algorithm possible.  For example,
if your program typically allocates 10000 500-byte blocks, you can have
it allocate 500000 bytes at a time and parcel them out as needed, and
allocate another 500000 bytes when those are exhausted.

Comparing GC overhead with obsolete memory allocation functions doesn't
make GC look good.  The advantages of GC are overwhelming, but so are
the disadvantages, and that's why it almost seems like a religious
issue now.

The main advantage of GC is that it simplifies programs and makes them
easier to maintain.  This is a very substantial advantage, worth
sacrificing a lot for.  But, if non-GC memory management can obtain
nearly the same advantage, without the disadvantages of GC, then the
sacrifices aren't necessary.  So, the question would be, how can non-GC
memory management gain the advantage of simplifying programs and making
them easier to maintain, to approximately the same extent that GC gains
that advantage?

One answer would be that modern programming languages, using OOP and
genericity, make complexity so much easier to manage that the complexity
of non-GC memory management is no longer anywhere near as big a problem
as it was with older languages.  OOP and genericity have almost unlimited
potential to simplify complex software, to the point where the additional
simplification provided by GC might become superfluous.
Newsgroups: comp.lang.c++
From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Reference counting for vectors, (Tony Hansen's book).
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 15 Aug 1992 01:46:25 GMT

brister@decwrl.dec.com (James Brister) writes:

>On 15 Aug 92 03:22:08 GMT, tmb@arolla.idiap.ch (Thomas M. Breuel) said:
>> Copy-on-write is not really an option for classes like arrays that
>> require high-performance updates. You don't want to pay the price for
>> the memory fetch and conditional branch on each array store.
>
>If the array copies itself the first time it is written to, then you don't
>loose anything except on the first access, and with large data it would be
>better to have COW than to duplicate everything to protect against
>unintended changes.

You lose on every access, since you must *check* to see if the COW flag has
been set. Some of the time a clever compiler may be able to optimize away
that check, but it general it is unavoidable.

Eg. (simplified):

	inline int& COW_Array::operator[](int i) {
	    if (this->theArray->needs_to_be_copied())	// this is the test
		this->do_copy();			// you want to avoid
	    return this->theArray->data[i];
	}

-- 
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: daniel.edelson@inria.fr (Daniel R. Edelson)
Newsgroups: comp.lang.c++
Subject: Re: template static data members
Date: 20 Aug 92 08:30:45 GMT
Reply-To: Daniel R. Edelson <daniel.edelson@inria.fr>
Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France

In article <Bt8K2o.Azy@apollo.hp.com>, vinoski@apollo.hp.com (Stephen Vinoski) writes:
|> In article <4086@seti.UUCP> Daniel R. Edelson <edelson@sor.inria.fr> writes:

|> Regardless of my error, the real problem underlying all of this is
|> that the compiler cannot tell a legal program containing an
|> uninitialized definition for each static data member from an illegal
|> program containing only declarations, no definitions, for each static
|> data member, since in both cases a bss symbol is created.  It never
|> used to matter until templates and automatic instantiation came along.

|> Thanks for making me go back and try this again, Dan, and also thanks
|> for embarrassing me in public. :-) You should already know that I am
|> perfectly capable of doing that without anyone's help. :-)

You'll just have to return the favor next time I open my mouth too
wide. :-O

Ciao,

|> -steve

d-
Newsgroups: comp.lang.c++