HDTenEightyP/NetNews huggingface dataset:
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: typedefs in template class definitions
Summary: g++ & BC++ bug; rules for template classes same as regular classes
Date: 9 Jan 93 03:56:49 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

In article <7648@tivoli.UUCP> taylor@foraker.tivoli.com (Eric Taylor) writes:
>I am using GNU C++ ver. 2.3.3
>I am having problems with the following type of declaration:
>
>template <class T>
>class foo {
>	typedef int bar ;
>	void gag(bar x) ;
>} ;
>
>template <class T>
>void foo<T>::gag(bar x)
>{
>}
>[...]
>It does not matter if I change bar to foo<T>::bar or foo::bar
>(actually, I get different messages).

It's a compiler bug -- report it.  Coincidentally, BC++ 3.1 has the
same bug.  While the following is legal,

	template <class T>
	void foo<T>::gag(foo<T>::bar x) {}

it's unnecessary to qualify 'bar' in the parameter list since the
parameter list, like the body of the function, is in the scope of
foo<T>.  If gag() returned a 'bar', though, you would need to qualify
it since the return type of a function is declared in file-scope.

	template<class T>
	bar  // error: bar not in scope, use "foo<T>::bar"
	foo<T>::gag() {}

The only workaround for BC++ is to use the real type instead of the
typedef.  That's what I did throughout the JCOOL library (see
pub/GECOOL/JCOOL.TXT at cs.utexas.edu; btw, has anyone successfully
compiled a significant portion of it under gcc 2.3.3 or any other
compiler?).

As for your other attempt, I'm not sure if the following is legal:
	template <class T>
	void foo<T>::gag(foo::bar x) {}

I think it is legal to use 'foo' without "<T>" in other situations:
	template <class T>
	void foo<T>::gag(bar x) { foo* p = this; }
but you may have to use "<T>" with the '::' operator.  Anyone?

Jamshid Afshar
jamshid@emx.utexas.edu
Newsgroups: comp.lang.c++
From: brunner@crchh447.bnr.ca (James Brunner)
Subject: Re: Dynamic Multidimensional Array Allocation in C++
Date: Tue, 5 Jan 1993 20:24:19 GMT
Reply-To: brunner@crchh447.bnr.ca (James Brunner)
Organization: BNR, Inc.

In article <C0Cw7r.72t@dcs.ed.ac.uk>, tk@dcs.ed.ac.uk (Tommy Kelly) writes:
|> In article <C0C68I.MA7@dcs.ed.ac.uk> tk@dcs.ed.ac.uk (Tommy Kelly) writes:
|> >How do I implement a dynamically configurable two dimensional array in C++?
|> >
|> >For one dimension its easy, but doing:
|> >
|> >my_type *my_type_var = new my_type[a][b];
|> 
|> What I'm doing at the moment is explicitly creating a vector of vectors like:
|> 
|> 	My_type **my_type_var = new My_type*[a];
|> 	for(int i=0; i<b; i++) {
|>     	  my_type_var[i] = new My_type[b];
|> 	}
|> 
|> I can then access the array my_type_var[a][b] as normal.
|> But it seems kinda inelegant.  Maybe I expect too much from C++...

Actually, your method is very elegant.  The problem is that array access is
greatly a function of the compiler.  To access element [2][3] in a [][7] array,
the compiler creates code that does this:

  element address = (start of array) + ((2 * 7) + 3) * (element size))

or more generally, to access element [x][y]:

  element address = (start of array) + ((x * 7) + y) * (element size))

Notice that the size of the lower dimensions are compiled in (the element size(
is as well).

By creating an array of pointers to one dimensional arrays, you can access it
(syntax wise) like a two dimensional array, but the compiler generates this:

  pointer address = (start of array) + x * (pointer size)
  element address = (dereferenced pointer address) + y * (element size)

There is no need for the compiler to know any of the dimensions in advance.

Of course other benefits depend on how the 2 dimensional array is to be used.
If for example you were mapping a terminal screenful of characters, with your
method, a scroll operation would only involve shifting the pointers and clearing
the last line.  Must faster than moving all of the elements.
-- 
---------------------------------------------------------------------------
Jim Brunner - (brunner@bnr.ca)
All opinions are my own and have nothing whatsoever to do with BNR, NT,
NTI, Bell Canada, or any of the BCE corporations or affiliates.
From: hlf@nic.cerf.net (Howard Ferguson)
Newsgroups: comp.lang.c++
Subject: Clarification of Callbacks in C++
Date: 9 Jan 1993 00:21:00 GMT
Organization: CERFnet Dial n' CERF Customer Group
NNTP-Posting-Host: nic.cerf.net

In article <1iikcuINN6fr@news.cerf.net> hlf@nic.cerf.net (Howard Ferguson) writes:
>The FAQ for this group describes how to put wrapper functions around 
>member functions so they can be called as callbacks from X libraries
>and the like. But if I am writting a c++ class library, surley I should
>be able to provide a cleaner mechanism to my customers. Is there
>a standard way of doing this???
>
>	ta,
>		hlf

What I am really asking is how do I solve the problem above IN C++
ONLY. Many thanks to those who supplied info on calling between C
and C++ but that is  not the problem I am trying to solve. I was to 
supply my colleges who are coding in C++ with some classes written in
C++ which require calbacks. My point is that I should be able to
provide something cleaner than what I must use if I am writting a
C library which may be used by C++ coders ( e.g. Xview).

	hlf


Newsgroups: comp.lang.c++
From: pauljo@microsoft.com (Paul Johns)
Subject: Re: Simulate "Pointer to char" by an array
Date: 05 Jan 93 02:16:07 GMT
Organization: Microsoft Corp., Redmond, Washington, USA
Distribution: usa

The previous posters' ideas are right, but be SURE you understand
how to write your own assignment operator, copy constructor, and
destructor before you try this.  Time you spend learning this
crucial information will save you hours of painful debugging.
From: matt@centerline.com (Matt Landau)
Newsgroups: comp.lang.c++
Subject: Re: Motif GUI Builders and C++
Date: 8 Jan 1993 19:38:47 GMT
Organization: CenterLine Software, Inc.
NNTP-Posting-Host: 140.239.1.32

In <1993Jan8.155314.6621@zoo.bt.co.uk> fad@zoo.bt.co.uk (Francisco A de Carvalho) writes:
>I need to find out more about what functionality the products provide (eg Drag
> and Drop, which Class library it provides etc...)
>
>To add to the discussion, CenterLine also has a product called 'ViewCenter'
>which provides run-time selection of Motif/OpenLook, the OI Class Library,
>Drag and Drop etc...

ViewCenter and ObjectBuilder\C++ are basically the same product, and
they're both based on the OI class library.  OI provides runtime selection
of 2D- or 3D- OPEN LOOK behavior, or Motif behavior.  Most of the usual
widgets/objects are there, although OI does not yet support drag-and-drop,
paned windows or tearoff menus in Motif model, or splittable views in the
OPEN LOOK models.  All of these features should show up in OI version 4.0
and the corresponding versions of ViewCenter and ObjectBuilder, all of
which are due out sometime in 1993.
--
 Matt Landau			Waiting for a flash of enlightenment
 matt@centerline.com			  in all this blood and thunder
From: taylor@foraker.tivoli.com (Eric Taylor)
Newsgroups: comp.lang.c++
Subject: typedefs in template class definitions
Date: 8 Jan 93 22:22:15 GMT

I am using GNU C++ ver. 2.3.3

I am having problems with the following type of declaration:

template <class T>
class foo {
	typedef int bar ;
	void gag(bar x) ;
} ;

template <class T>
void foo<T>::gag(bar x)
{
}

It is as if bar was not entered into the symbol table as a typedef
when parsing gag.

It does not matter if I change bar to foo<T>::bar or foo::bar
(actually, I get different messages).

Am I doing something wrong, or is this a compiler bug?
Newsgroups: comp.lang.c++
From: bytor@grumpy.NoSubdomain.NoDomain (Ross Huitt)
Subject: Re: How to prevent local instances, but allow "new"
Organization: Bellcore
Date: Tue, 5 Jan 93 18:56:12 GMT

In article <1icij0INNdhc@news.cerf.net>, hlf@nic.cerf.net (Howard Ferguson) writes:
....
|> I suppose writing a satic member function called "createSomething"
|> which would then call a private constructor via new woulod work,
|> but it seems a little kludgy. I want my library users to create
|> their objects using new, as our creator intended, rather 
|> than calling some   non-standard function.

Actually, I find myself using static 'create' methods more frequently these days.
If there is any chance at all that the constructor might fail, this is almost a
necessity. Sure, you can use exception handling for this task, but in many cases
this would be more 'abuse' than 'use'.  Returning a NULL pointer is often enough
information about the failure. If I need more than this, I'll throw a 
'precondition_failure' exception or whatever is appropriate for the situation.

...
|> 	tanx,
|> 		hlf
|> 

     -bytor
From: rune@nta.no (Rune Henning Johansen FBA)
Newsgroups: comp.lang.c++
Subject: Re: Passing 2-d arrys to functions
Date: 10 Jan 93 11:52:55 GMT
	<24568@alice.att.com> <726521188snx@trmphrst.demon.co.uk>
Organization: Norwegian Telecom Research

In article <726521188snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:

  >  For a two (or more) dimensional array, to access element [m][n], the 
  >  compiler needs to know the address of the first element, the size of each 
  >  element, and the number of elements in the least significant dimension. 
  >  The calculation for an array declared [DIM1][DIM2] is 
  >  ((m * DIM2 + n) * sizeof(element)).

I'm including a little program that seems to work fine. Here I'm pas-
sing only the pointer to  a two dimensional array.  Can I expect such
programs to work, and if so, why?

 - Rune

 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

#include <stream.h>

#define begin {
#define end   }

void Input ( double **b )
begin
    b[0][0] = 1.0;
    b[1][0] = 2.0;
    b[0][1] = 3.0;
    b[1][1] = 4.0;
end

void Output ( double **b )
begin
    cout << b[0][0] << "\n";
    cout << b[1][0] << "\n";
    cout << b[0][1] << "\n";
    cout << b[1][1] << "\n";
end

int main ()
begin
    double **a = new double*[2];
    a[0] = new double[2];
    a[1] = new double[2];

    Input  ( a );
    Output ( a );

    delete a[0];
    delete a[1];
    delete a;

    return 0;
end
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: "type safety" deemed essential
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Wed, 6 Jan 1993 11:51:46 +0000

In article <450@genie.UUCP> roger@genie.UUCP (Roger H. Scott) writes:
> In article <725053473snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk writes:
> >In article <448@genie.UUCP> roger@genie.UUCP (Roger H. Scott) writes:
> >> ... [W]ho has written a non-trivial commercial C++ 
> >> application *without* making significant use of either type casting [(T *)]
> >> or run-time type checking [Bar *bar_p = foo_p->asBar();]?  
> >
> >Does my Text Mode User Interface Toolkit count ?
> 
> Not to denegrate tool kits in general in any way, but the short answer is "no".
> The sorts of code one writes for a general purpose tool kit tend to be
> rather different than the code one ends up writing for an end application.
> [It has often seemed to me that C++ has evolved to be more closely tuned
> to the needs of tool kit, or library, writers than for "end" users.]
> A non-trivial commercial application *using* the T.M.U.I. kit *would* count,
> of course.

O.K., then I had better look to see if the main applications I have 
written in C++ (using the toolkit) are non-trivial ...

Application				Lines of code
Toolkit					16000
Mainframe comms document retrieval	 8000
PC Usenet newsreader/mailer		 7000

Do these count as non-trivial ?
[ Note - lines of code computed by wc. ]

-- 
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Newsgroups: comp.lang.c++
From: pkoch@news.weeg.uiowa.edu (Peter F Koch)
Subject: C++ coding style guide??
Organization: University of Iowa, Iowa City, IA, USA
Distribution: usa
Date: Wed, 6 Jan 1993 14:02:37 GMT


Anyone know of a good C++ coding style guide?


===========================================================================
Peter Koch                                              Phone: 708-534-5200
Weston Gulf Coast Labs                     email:pkoch@umaxc.weeg.uiowa.edu
2417 Bond St.
University Park, IL 60466
===========================================================================
From: t1gopal@shekel.wr.tek.com (Gopal Kulkarni)
Newsgroups: comp.lang.c++
Subject: Re: Converting EXE files back to C source code
Date: 4 Jan 93 21:33:22 GMT
Organization: Tektronix, Inc.


Few days back I came across a software tool called C Sourcer. I really don't know of any source from where you can get it.
Xref: sparky comp.lang.c++:18800 comp.object:4729
From: js@montaigne.lif.icnet.uk (Jack Shirazi <js@biu.icnet.uk>)
Newsgroups: comp.lang.c++,comp.object
Subject: Re: Pros and cons of C++
Date: 7 Jan 1993 17:05:25 -0000
Organization: Imperial Cancer Research Fund
NNTP-Posting-Host: montaigne.lif.icnet.uk

In article <C0Hp1n.vp@gpu.utcs.utoronto.ca> yjohn@gpu.utcs.utoronto.ca (John Ross) writes:
>I have recently come to grips with having to learn C++; mainly due to
>the bandwagon effect. It doesn't look like there will be any pure C
>programmers left in a couple of years.  I agree that the language is
>very complex, and has many shortcomings.  
>
>Why then is it becoming so popular?  Why the deluge of texts, articles,
>magazines, news groups, compilers, etc?  It seems to me that C++ _will_
>be the language of choice for programmers (except in specialized areas
>where other languages will continue to be used). It would be nice to get a
>balanced view of where C++ fits into the scheme of things.
>Unfortunately, language issues often assume the aspect of a religious
>war, with rabid supporters and detractors.
>
IMHO C++ is much better than C. A great many people agree (in fact 
I've never heard anyone disagree). For this reason, C programmers
have a natural inclination to move "up" to C++ since it allows them
to retain all their C experience while learning the OO paradigm.
Moreover, most C programmers swear by it (C), and so are not generally
inclined to properly learn another language unless they must.
So it is not at all surprising that the large number of C programmers
will cause C++ to be popular - just because something else is better
does not mean it will be more successful, as we've seen in so many
things in the computing world.

However, having said that, everything I've seen indicates that against
C++, Smalltalk is currently holding its own. I have only seen
non-rigorous surveys of groups using OO technology, (Object magazine
springs to mind) but these indicate that currently for OO development
projects there are actually more Smalltalk groups than C++ ones. My
own personal experience is that the Smalltalk development environment
is just _so_ nice that I prefer to steer clear of the retrograde C/C++
environment.  However, there are things that I still have to do in C
because of all those system functions which I need to call from
Smalltalk and which as yet don't come as standard with Smalltalk.

Each to their own. If you feel peer pressure (or workplace pressure)
to move into C++, thats up to you. Personally, I feel that you should
test a variety of languages, and settle on the one that makes you
spark - whichever that is. I believe there are still more COBOL
programmers than C, and I don't think they have any trouble finding
jobs. Nor do pure C programmers. Nor will they for a long time.
-- 
       Jack               js@bison.lif.icnet.uk
                         
If you only have a hammer, you tend to see every problem as a nail.
                -- Maslow
From: pete@borland.com (Pete Becker)
Newsgroups: comp.lang.c++
Subject: Re: A Fine Beginner's Book on C++
Date: 12 Jan 93 17:59:34 GMT
Article-I.D.: borland.1993Jan12.175934.9573
Organization: Borland International
Originator: pete@genghis.borland.com

In article <1993Jan11.222634.19826@microsoft.com> pauljo@microsoft.com (Paul Johns) writes:
>
>By the way, I've noticed a lot of posts on here from
>people who are clueless about copy constructors:  could
>this book be part of the reason why?  :)

	No, the book is a symptom.  Beginners have trouble with copy
constructors.  Fortunately, most beginners don't write books.
	-- Pete
From: cshaver@informix.com (Craig Shaver)
Newsgroups: comp.lang.c++
Subject: Re: feedback wanted on appropriate OOPL
Date: 12 Jan 93 17:05:04 GMT
Organization: Informix Software, Inc.

In article <rmartin.726795186@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
......
........
>
>Deferring error detection to runtime is risky, since the error may be
>encountered several months after its release.  Also, there are several
>C++ development environments that catch runtime errors just as nicely
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Could you provide a few names?  Are they interpretor based? 
Expensive?  Available on multiple platforms?

>as stalk does.  So, I don't accept that runtime error detection is
>either an advantage or the exclusive domain of stalk.

A good development environment can make up for a lot of deficiencies
in a language :'}.

>
>
>--
>Robert Martin                        Training courses offered in:
>R. C. M. Consulting                       Object Oriented Analysis
>2080 Cranbrook Rd.                        Object Oriented Design
>Green Oaks, Il 60048 (708) 918-1004       C++


-- 
Craig Shaver  (cshaver@informix.com for now) (415)390-0654 (415)926-6407
Productivity Group POB 60458 Sunnyvale, CA  94088
From: Neal.Sanche@ttlg.UUCP (Neal Sanche)
Sender: postmaster@ttlg.UUCP
Newsgroups: comp.lang.c++
Subject: RE: Turbo Vision Query
Date: 04 Jan 93  00:10:02 mst

 On 01-02-93 Neal Sanche wrote to All... 
 
 > I am having some difficulties with a particular part of my latest 
 > Turbo Vision application. I have an event which does various things, 
 > a dialog pops up for user input, then various ofstream objects are 
 > instantiated and some ostrstreams are used for in memory formating 
 > and so on. 
 
 As a note to people who may be wondering how I fixed this bug, it 
 was a problem in code imported from the TVEDIT program. In the 
 openFile() method of the main application object, the execDialog 
 call passes a char * as the data parameter. This is incorrect 
 and results in an invalid stack pointer. This correct code should 
 pass the address of the char *. 
 
 Any comments? 
 
 -Neal 
 
... OFFLINE 1.41 

 * Origin: Paradigm BBS: A programmer's paradise. (42:100/11)
Newsgroups: comp.lang.c++
From: chrisg@cs.umr.edu (Chris Gorsuch)
Subject: Re: Protogen/ Owl directories
Date: Wed, 6 Jan 1993 21:11:49 GMT
Organization: University of Missouri - Rolla
Originator: chrisg@mcs213b.cs.umr.edu

Thanks to the people who have responded thus far.
I have the Borland C++ for windows but Without Application
frameworks...Although it doesn't say it has Object windows it 
does imply that it has several windows products...one of which
pictured *yeah i know don't believe them* on the back is
a directory list including...OWLDEF.H *the file I need*
Why would they 1. include a file which couldn't be run
and 2. list a file which they didn't include.
The help does have info on the command I need also but
of course with out the owl lib there is little I can do about it.
They did say I could check the manuals for the source code
since they might not have installed it, but the manual doesn't have
said portion.

As for protogen, it appears to be a very nice product, fairly easy to
use with a little manual which walks you through a windows creation
Of course it doesn't have any real info in it or how to link it up 
when you get done but the professional version of this would be worth
looking into.

In short, does anyone know where one might be able to get the OWL libraries?
besides repurchasing bc++ for windows with applications frameworks.
chrisg.
.
From: nistuk@unixg.ubc.ca (Richard Nistuk)
Newsgroups: comp.lang.c++
Subject: How do I get a smaller array "inside" a bigger array?
Date: 4 Jan 1993 23:33:43 GMT
Organization: University of British Columbia, Vancouver, B.C., Canada
NNTP-Posting-Host: unixg.ubc.ca
Summary: Help!

Hello,

  I'm having a bit of a problem with pointers.  What I
have done is overloaded the "=" and "+" operators to
return a pointer to a two element array, and I would like
to place this two element array inside a larger array:

...
individual *a,b,c; // create a pointer to an array of
                   // "individual" classes and two 
                   // instances of the "individual"
                   // class 

a=new individual[4];

b.create(); 	// initialize b and c
c.create();

a=b+c; // this works o.k.: a[0] and a[1] hold the
       // solutions of b+c.

?=c+b; // now how do I get a[2] and a[3] to hold the
       // solutions of c+b?
...


Is what I want to do possible?
  
Can I make it work when _a_ has 1000 elements instead
of 4?  For example, assume b,c,and d are instances of
the class "individual", and a is pointer to an array of
1000 "individuals" I would like a[0] and a[1] to be the
solutions of c+d, say, a[2] and a[3] to the solutions
of c+d... and a[1998] and a[1999] to be the solutions
of d+c.

Is what I want to do bad programming style?  
Should I do something else?

BTW, I'm attempting this with TC++.  

Thanks in advance for your help.
-- 
Richard Nistuk               4th Yr Physics at U.B.C.
nistuk@unixg.ubc.ca
Newsgroups: comp.lang.c++
From: c313023@cs.UAlberta.CA (Sanche Neal Andrew)
Subject: TResourceFile Memory loss with BC++ 3.1
Keywords: Turbo Vision BC++ 3.1
Organization: University of Alberta, Edmonton, Canada
Date: Wed, 13 Jan 1993 00:36:20 GMT

Hi All,

I posted a query a few days ago regarding the loss of
memory when a TResourceFile object is instantiated while
using Turbo Vision for BC++ 3.1. Whew... I have come to the
conclusion that the culprit is the Turbo Vision Stream manager
itself that is causing this loss of memory.

Is there any way to tell the Stream Manager to let go of its
Database of written and read objects? Is this memory automatically
deallocated when the system shuts down? If heap space is low
will this database be freed? Can I manually free this database?

Please direct replies to neal@manning.cs.ualberta.ca

Thanks!

Newsgroups: comp.lang.c++