HDTenEightyP/NetNews huggingface dataset:
Organization: University of Illinois at Chicago
Date: Thursday, 17 Dec 1992 10:54:42 CST
From: <U54294@uicvm.uic.edu>
Newsgroups: comp.lang.c++
Subject: Re: So What About the New IBM C++?
Distribution: comp
 <92351.152937U54294@uicvm.uic.edu>

   I had some more time to poke around the IBM C++ beta version for OS/2.
It's a full copy of C Set/2 (natch) with C++ on top. It's a Cfront 3.0 style
version (I guess), with templates and exceptions. There are basically two
class libraries. One has template-based container classes of about 9x10**6
different varieties and a FULL class library for PM, OS/2 threading and
just about anything else you can think of. The second "Basic" class library
is the USL iostream/complex/tasking library. For the beta distribution there
is a catch: They say licensing restrictions wouldn't allow them to ship the
USL library, only the documentation for it. You have to order it separately
from IBM (1-800-3IBM-OS2 I think). It costs exactly $26.28.
   The software comes with full hypertext-OS/2-style documentation for the
whole language, class libraries, etc. The class library doc is clearly a
pre-release version, but experienced C++ folks shouldn't have too much
trouble if they're also PM experienced.
   There are C++ extensions to Workframe/2 and Toolkit/20, and a new
PM-based debugger which includes class browser, source browser, etc.
Some of the more advanced debugger functions aren't complete in this beta
version, however. There's also a device driver for an execution-time
analyzer called Profit(?). There's no multithreaded C++ run-time library,
only a single threaded version (unlike CSet/2 for OS2 2.0). I don't know
whether this implies that the C++ run-time is fully reentrant or that
the multithreaded library will come out later.
   The bottom line is that this is a full 32-bit C++ environment for OS/2,
although it looks about 85% complete. It's big, about 30M on disk if I
recall. You'll be much better off installing it from CD. It looks good,
the disclaimer being that I have only TC++ 3.0 to compare it against.
                            Nick Geovanis
                            U54294@uicvm.uic.edu   <-- best
                            GEONI02@hera.cai.com
Newsgroups: comp.lang.c++
From: burr@seas.gwu.edu (Timothy J. Burr)
Subject: Looking for ftp site for linkedlist class
Organization: George Washington University
Distribution: na
Date: Fri, 18 Dec 1992 22:39:43 GMT

I don't want to recreate the wheel.  I'm looking to grab a linked list
class from some ftp site.         

Tim

burr@seas.gwu.edu or burr.enews.nrl.navy.mil
From: eker@loria.fr (Steven Eker)
Newsgroups: comp.lang.c++
Subject: classes within templates
Date: 14 Dec 92 12:08:42 GMT
Organization: CRIN (CNRS) Nancy - INRIA Lorraine

What is the semantics of nesting classes within a template class?
I want to implement a template container class where the internal structs are
hidden:

template<class T> class My_container {

  struct internal_stuff {
    internal_stuff* link;
    T data;
    ...
  };

  internal_stuff* ptr1;
  ...
};

This seems to work ok until I want to have an friend class for iterators
(assume "friend class My_iter<T>;" included in above def):

template<class T> class My_iter {

  internal_stuff* ptr2;
  ...
};

At this point the compiler (gcc v2.1) complains of a syntax error
before '*' and bombs.

What is the status of "internal_stuff"? Is it implicitly parameterised
by T? Does it make sense to declare a template within a template
(a) with parameters that are a subset of enclosing templete parameters
(b) with parameters that don't exist in enclosing template?

What's the best way to hide the internal classes/structs of a complicated
container class from global name space?

tia

Steven			eker@loria.fr
From: dad@se21.wg2.waii.com (Dennis Doussan)
Newsgroups: comp.lang.c++
Subject: Re: Real Time C++ ?
Keywords: Real-Time/C++
Date: 15 Dec 92 16:00:13 GMT
Followup-To: Real Time C++ ?
Organization: Western Geophysical Expoloration Products

Summary of the responses I have received to the following inquiry about C++ 
used in embedded systems:

>|1) Is anybody developing code in C++ for an embedded system that runs VRTX?
>|   If so:
>|     a) what processor is he/she/it using?
>|     b) which compiler  is he/she/it using?
>|     c) what run-time libraries is he/she/it using?
>|     d) what sort of development system is he/she/it using?

>|2) Is anybody developing code in C++ for an embedded system that runs any 
>|   other real time operating system kernel? If so:
>|     a) which kernel is he/she/it using?
>|     b) what processor is he/she/it using?
>|     c) which compiler  is he/she/it using?
>|     d) what run-time libraries is he/she/it using?
>|     e) what sort of development system is he/she/it using?


See the October issue of IEEE Computer, pg. 66.

See the latest Dr. Dobb's Journal.

See American Programmer. October 91. Vol 4, no.10
    "Real-Time Object-Oriented Programming Systems"
    Brian M. Barry

See Barry, Brian M. "Using OOP for Realtime Programming."
    Addendum to the Proceedings of OOPSLA/ECOOP'90.
    Ottawa, ON, Canada. New York: ACM Press, 1991.


VxWorks
Motorola MVME-133
Gcc 2.3.2
libg++-2.2 ( streams only )
Developed on Suns

pSOS
M68030
Microtek Research's C++ compiler/assembler/debugger
MRI ansi compatible runtime library

Chimera Real-Time Operating System 
(For details on Chimera, finger "chimera@cmu.edu".)
Motorola MC680x0
GNU C++ as a cross compiler
We provide most of the standard libg++.
Sun Workstation

// From Scott Herzinger at Wind River Systems ( scotth@wrs.com )
VxWorks "wind"
680x0 and i960
compiler based on cfront 3.0.1
ANSI C library, USL iostreams class library for I/O.
Host workstation

pSOS+
68030
Apple's MPW compilers running off Macintoshim
pSOS comes with an ANSI C runtime library
Apple's MPW environment plus a lot of our own work.

pSOS+
68040's m167/m147
Microtex complier, XRAY+ source level debugger.
ISI ships a SVID c library, Booch components from Rational
Sun Sparc

HP-RT
HP 9000 Model 742rt (PA-RISC 7100)
Standard C++ compiler on HP-UX.
The same.
HP-UX host development system.



----------------------------------------------------------------------
Dennis A. Doussan                               doussan@wg2.waii.com 
Design Engineer                                 VOICE: (713) 964-6131 
Western Geophysical Exploration Products        FAX:   (713) 781-2585
3600 Briarpark Drive      
Houston, Texas 77042     
USA 


Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Need help implementic data structures of generic objects
Organization: Rational
Date: Tue, 15 Dec 1992 14:36:08 GMT

kocks@leland.Stanford.EDU (Peter Kocks) writes:

>My $0.02.  Use Obj-C.  I have just spent a fair amount of time
>comparing strong vs weak type casting systems [...]

For any significant industrial application, I think strong typing is
utterly essential.  It is just too easy to create horrible run time
errors without type safety.  

Does type safety preclude OO?  No.  It constrains it, certainly.  But
the constraint is IMHO not serious.  We can still have polymophic
types, and containers of heterogenous objects.  We just limit the
amount of heterogeneity by building type walls.  This means that you
can't put Car objects in a list that is meant to hold Shapes.  But you
can put circles, squares and rectangles in this list.  And, when
accessed as Shapes, the circles, squares and rectangles will behave
polymorphically. 

Although mixing type safety with OO causes a slight rearangement of
thinking in people who are used to OO without type safety.  Very
little capability is actually lost, and a great deal of safety is
added.  

--
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++
Newsgroups: comp.lang.c++
From: ghageman@dw3f.ess.harris.com (George Hageman)
Subject: RE: NIHCL on Sparc ...
Date: Wed, 16 Dec 1992 14:46:29 GMT
Reply-To: ghageman@dw3f.ess.harris.com (George Hageman)
Organization: Harris GISD
Keywords: C++ NIHCL Sun Sparc Class Libraries


Hi,
	I have version 3.1.12 up and running using CFRONT 2.1.X on a sparc IPX
-- had to modify some of the IMAKE files to make this possible and read
some of the release notes to make some adjustments in make files ... but
it seems to do
just fine in both single and multiple inheritance modes.  However, the
debug 
version of MI does not do much but convert otherwise usable disk space
to core files.  

	I have attempted to change the object names by prepending "Nih"
to each as was done by those fine folks at Martin Marietta ... but have
not been able to do this without breaking the library in unnervingly subtle
ways even though I used their sed files to accomplish the "required" changes.
If anyone has had any luck in this area please let me know what the trick
is.

	I don't know what I could do to help at this time besides
provide emotional support, but I suggest looking at the 3.1.12 beta
release of the NIHCL, there are some fixes included that are expressly
for the CFRONT 2.1.X releases on sun platforms.  They seem to work.

-----------------------------------------------------------------------------
George W. Hageman       407/242-5367  	| "A government that is big enough to  
Harris GISD, Melbourne, FL  32902     	|  give you all you want is big enough
Internet: ghageman@dw3f.ess.harris.com	|  to take it all away." -- B. Goldwater
Newsgroups: comp.lang.c++
From: tma@encore.com (Thanh Ma)
Subject: Re: UMAX C++ compiler
Organization: Encore Computer Corporation
Date: Wed, 16 Dec 1992 14:51:42 GMT

cbusch@ub.d.umn.edu (Chris) writes:

>Here at UMD, we use a computer made by Encore Computer Corp. I was
>wondering if there was a C++ compiler for it.  It is an Encore Multimax
>running UMAX Unix 4.3 version.
>Thanx
>--
>Chris Busch   CBUSCH@ub.d.umn.edu
>"C++ is the language of choice."
>"The use of COBOL cripples the mind; its teaching should, therefore,
>    be reguarded as a criminal offense." - E. W. Dijkista 
>"High-level languages should remove burden from the programmer, not
> put burden on the programmer!"
>"Don't ask 'why would you do that?' instead ask 'why wouldn't you do that?'"

Yes. There is. Post your article to comp.sys.encore and you will hear
response.

thanh ma
tma@encore.com
From: kanze@us-es.sel.de (James Kanze)
Newsgroups: comp.lang.c++
Subject: NULL in C++ (was: Is this a compiler bug?)
Date: 18 Dec 92 04:18:57 GMT
	<1992Dec11.193023.27787@news2.cis.umn.edu>
	<1992Dec14.212823.20514@microsoft.com>
Organization: SEL

In article <1992Dec14.212823.20514@microsoft.com> jimad@microsoft.com
(Jim Adcock) writes:

   [The thread that started this discussion deleted...]
|> I think the confusion lies in assuming that ((void*)0) could be an
|> acceptable implementation of NULL in C++.  ((void*)0) is acceptable
|> in C.  It is not acceptable in C++.  The rules of pointer type compatibility
|> have changed, and are more restrictive in C++.  Thus ((void*)0) no longer
|> flies.  This is a source of frequent trouble for C++ programmers trying to
|> use old C .h files.

This brings up another point.

The C++ committee have aready changed wchar_t into a true type, rather
than the typedef it was in C.  Why couldn't NULL become a true
reserved word in C++?  Then we wouldn't have to worry about whether it
was defined in a compatible way.

Logically, this should lead to the deprication of assigning 0 to a
pointer, or comparing a pointer to 0.  The NULL pointer would then be
represented as NULL, and not 0, and would unambiguously be a pointer.

And of course, this would solve the ambiguity problem with overloaded
functions:

	extern void	f( int ) ;
	extern void	f( void* ) ;

	f( 0 ) ;	//  Currently ambiguous, should call f( int )
	f( NULL ) ;	//  Currently ambiguous, should call f( void* )

Somebody will no doubt prove me wrong, but I can't think of a single
program that this would break (supposing the depricated implicit
conversion).  And the depricated conversion wouldn't hinder the above
from working, since an exact match would be preferred over a
conversion.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung
Newsgroups: comp.lang.c++
From: vaitkus@lexmark.com (Keith Vaitkus)
Subject: C++ compiler recomendations wanted
X-Disclaimer: These views are the poster's and not necessarily those of Lexmark
Organization: Lexmark International
Distribution: na
Date: Tue, 15 Dec 1992 17:55:35 GMT

I want to start programming in C++, so I need help in choosing the right compiler
for a PC. I have three related criteria at the moment:

(1) Which compiler will be the easiest to port code between the GNU C++ compiler
	on a Sparc Unix workstation and a PC.

(2) For the next few months, I will need/like to run this compiler on an IBM
	PC 286 AT. Soon I will be upgrading my hardware, most likely to a 386-40.

(3) Although I would like to use this compiler now in DOS (as I mentioned on a PC AT),
	I definately will migrate to an OS/2 2.0 platform. At that point, I will
	completely abandon 640K-DOS and move to an OS/2 flat memory module. (I hope.)

If one compiler cannot help me with all three concerns, I would choose to get one
	that will do the OS/2-2.0 code and just wait for my new hardware.


I am also interested in what libraries are available to do GUI programming in OS/2.

Any information would be much appreciated.

Happy Holidays!
--

---------------------------------------------------------------------------
                                              /\    Keith Vaitkus
                                             //\\   
                                            ///\\\  Lexmark International
                                            \\\///  email: vaitkus@lexmark.com
                                             \\//   voice: (606) 232-4382 
                                              \/
From: sabroe@daimi.aau.dk (Morten Sabroe Mortensen)
Newsgroups: comp.lang.c++
Subject: Re: Special-purpose-heap-managers - references
Date: 20 Dec 92 15:32:18 GMT
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark

euamts@eua.ericsson.se (Mats Henricson) writes:

>In article 11510@daimi.aau.dk, sabroe@daimi.aau.dk (Morten Sabroe Mortensen) writes:
>#Could anyone, -who have tried-, tell, what kind of experiences they have with 
>#special-purpose-heap-managers like 'Pool', in what kind of program, with what 
>#kind of result/speed-up? 

>We did a test of several class libraries, of which one was using a Pool class.
>In one test (putting and removing integers from a Set class) the Pool-based
>solution was ~20 times faster. That was the extreme case. In another test the
>gain was "only" 2.3 times.

Nice, nice, - sounds interesting!!! 
Are some of these classes, you tested, availably on the net - 
do you remember where?

>BUT REMEMBER: all this performance difference is NOT because of a Pool class.
>The libraries differed in many other respects, which affected performance.

>And then again: size and performance isn't everything...

You're right! -size and performance isn't everything!

BUT: If you want high performance, doing SOMETHING to dynamic allocation
     seems to be one of the better ways to gain speed, i think! 
     _IF_ allocation could be handled transparently, -like 'Pool' _nearly_ 
     can do, then.... But arrays...-one should be careful with arrays, 
     since they can't be managed transparently...YET! 

It ought to be possible to let a special manager manage ALL kinds of
allocation involving a certain class, -that's what I want, I think!
TRUE TRANSPARENCY - ABSTRACTION, ABSTRACTION, ABSTRACTION - HIGHLY WANTED!

I'm thinking: When constructing a special-purpose-heap-manager, one should
be careful not to ramble into some kind of ALIGNMENT-PROBLEM (it could
easily happen!!!) - that is, it should, -of course(!)-, be portable; 
size and performance isn't everything!

        -- Morten.

---------------------------------------------------------------------------
 Morten Sabroe Mortensen,         e-mail: sabroe@daimi.aau.dk
 Department of Computer-science - University of Aarhus, Denmark.
---------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: A modest proposal...
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Mon, 14 Dec 1992 18:26:56 +0000

In article <1992Dec11.172729.20503@newshub.ariel.yorku.ca> cs911461@ariel.yorku.ca (C. Armour-Kidson) writes:
> comp.lang.c++'ers,
> 
> Due to amount of traffic on this group concerning Borland C++ and
> other DOS specific compilers, would it be rude to suggest that 
> such material be moved to another newsgroup, say, comp.lang.c++.borland
> or comp.lang.c++.dos or something?  I can't speak for everyone but
> it's getting hard to find articles specific to C++.

Yes, I find these just as irrelevant as the numerous questions about HP, 
Sun, X, NIH and Interviews :-)

I agree that this group has (in practice, even if not in theory) too wide 
a remit. It would be a good idea to separate out queries about specific 
compilers (whether Borland or GNU or cfront).

Whether it would be a good idea to have a separate group for each 
compiler, or each operating system, or each hardware platform, I don't 
know. If there were groups "comp.lang.c++.unix", "comp.lang.c++.dos" and 
"comp.lang.c++.other", is there any chance that users (particularly new 
users) would use the correct group for OS/compiler specific questions ? 

No, I thought not :-(

Oh, and I think this group IS the correct place to ask questions of the 
form "My brand X compiler won't compile the following code - is it a bug, 
or is it my code ?".

-- 
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: arlet@erasmus.et.tudelft.nl (Arlet Ottens)
Subject: Trouble with task library on HP730
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Wed, 16 Dec 1992 09:08:25 GMT

Hello all,

I have been experimenting with the AT & T task library. This is my source
file:

--------------------
#include <task.h>
#include <stdio.h>

int main( )
{
   printf( "hello world" );
}
--------------------

I linked it with the -ltask option.

On Sun-4s the program runs as expected, but on my HP-730 and HP-710, I get
a core dump. This is the output :

***** task_error(27) FrameLayout::FrameLayout(): frame size
Bus error (core dumped)

Am I doing something wrong, or is there a bug in the task library ?

Thanks in advance!
From: jordan@aero.org (Larry M. Jordan)
Newsgroups: comp.lang.c++
Subject: Zortech C++ v3.1
Date: 11 Dec 1992 19:55:12 GMT
Organization: The Aerospace Corporation
Distribution: usa
NNTP-Posting-Host: uniblab.aero.org

Just got an upgrade announcement in the mail for Zortech C++ v3.1.
AT&T version 3.0 for DOS/Windows, OS/2 and NT.  One can upgrade to
either of three packages listed.  

Included in the DOS/Windows package:
o Compiler(s)--C++ v3.0 and ANSI C
o Multiscope Debugger for Windows (and DOS?).  This is a Windows
  hosted debugger.
o Support for Windows 3.1
o Whitewater Resource Toolkit
o WINC stuff

The upgrade announcement left many unspecified details, but
included an 800 phone number where one could fax (additional?) details.

Well, I don't have a fax, but have many questions:
[1] Is there a Windows hosted IDE included in the package?  
    i.e. has zwb been ported to Windows?
[2] Does the debugger debug ALL memory models?  Does the debugger debug 
    the DOS extender code?
[3] Does the debugger support AT&T version 3.0? 
[4] Has the earlier debugger been completely supplanted by Multiscope?
[5] Is the product shipping as we speak?

I'd appreciate a Semantic response.

Thanks,

--Larry Jordan

Newsgroups: comp.lang.c++
From: draper@ais.org (Patrick Draper)
Subject: Re: Death of Borland C++ Compiler
Organization: UMCC
Date: Fri, 18 Dec 1992 20:15:13 GMT

In article <chaolin.88@fcit-m1.fcit.monash.edu.au> chaolin@fcit-m1.fcit.monash.edu.au (CHAOLIN CHANG) writes:
>bundled.  But as my programs are becoming complex (using pointer, pointer 
>to pointer, pointer to pointer to pointer and farmalloc extensively), 
>Borland compiler begins to fall over.  One of my colleagues is also 
>suffering for the same experience when he tried to push the Borland compiler 
>to its limits.
>
>I had pulled all my hair out.  If the program is run within the debuger line 
>by line, it works fine.  But as soon as I let go, it hung my PC.  
>
>I recompile the same source code in Zortech.  It WORKS. 
>
>I wonder if anyone else has the same experiences with me?
>
>Charles
>18/12/92
>

The Borland compiler is reliable for programs of almost any complexity. I
imagine there are some limits of loop nesting, etc, but if you reach thouse
you almost certainly are doing something wrong.

In your case, it sounds like you've got memory bugs. The fact that you're
using pointer->pointer->pointer type expressions indicates to me a hard to
debug program. The compiler shouldn't have any trouble with these, I've
never had these problems at all.

Try using the 80386 debugger. It loads the program into the same memory
address as DOS does from the command line. Any location dependent errors
will show up as they do without the debugger.

The program when compiled with Zortech also will have the same bugs as those
existant under Borland, the difference might be segment ordering (different
program arrangement) under the different compiler. Bugs that clobber unused
memory are still bugs, even if the effects are not obvious.

By the way, I DO know what I'm talking about because my current project at
work is a Point of Sale package that is over 70,000 lines long and requires
a DOS extender to run. It is compiled under Borland C++ 2.0 and 3.1.

---One more thing, you might want to try the DOS extender included with
Zortech because it will help show your memory bugs. Development with a DOS
extender is much much better than plain old unextended DOS.


------------------////////////////////\\\\\\\\\\\\\\\\\\\\------------------
| Patrick Draper-ZBT       Disclaimer:  I can't control my fingers,        |
| draper@umcc.ais.org                   I can't control my toes! - Ramones |
| University of Michigan Computer Club                                     |
NO CARRIER                     We are a nation of laws, not people         |
------------------\\\\\\\\\\\\\\\\\\\\////////////////////------------------
Newsgroups: comp.lang.c++
From: raymond@Xenon.Stanford.EDU (Eric A. Raymond)
Subject: Nested Fn's (or Displays) (was Re: Give me safe C++)
Organization: CS Department, Stanford University, California, USA
Date: 18 Dec 92 20:49:31 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>	So, I feel unhappy when C/C++ takes away abilities
>I have as an assembler programmer. I am especially annoyed
>that NESTED FUNCTIONS are not supported.

>	My very hardware (486) has direct support, and their
>easily implemented on other machines with a display stack,
>for example. While they were overused in Pascal, they are
>quite handy. How can one call C++ a block structured
>language otherwise? Anyone else for nested functions? Against?

Hardware support does not mean that it will be efficient in the
general case.  It also makes the compiler a bit more involved (but
that's not a veery good argumen).  I think there is also a tradeoff
between the generality of fn pointers (pass them?  return them?)  and
displays.
Newsgroups: comp.lang.c++