HDTenEightyP/NetNews huggingface dataset:
ReplyTo: nikki@trmphrst.demon.co.uk
Subject: Another MSC 7 problem
Distribution: world
X-Mailer: cppnews $Revision: 1.19 $
Organization: Trumphurst Ltd.
Date: Mon, 5 Oct 1992 18:44:46 +0000

The following program will not compile under MSC 7 (it's O.K. under 
Zortech and Borland). Is it legal C++ ?
-----------------------------------------------------------
struct Base {
	Base();
	};

struct Command { 
	int (Base::*f)(); 
	Command(const Command &);
	};

Command::Command(const Command &d)
: f(d.f)
{
//x1.cpp(12) : error C2440: 'initializing' : cannot convert from 
// 'int (__far __pascal Base::*const )(void )__far ' to 
// 'int (__far __pascal Base::*)(void )__far '
//x1.cpp(12) : error C2439: 'f' : member could not be initialized
}

Note - if I cast away the const attribute of the parameter d, it works 
fine. But I don't want to do that (I could never hold my head up in this 
group again :-).
---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
Newsgroups: comp.lang.c++,comp.std.c++
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Re: NIHCL C++ class library and X11's libXt both use Object
Organization: Harvey Mudd College, Claremont, CA 91711
Date: Sat, 10 Oct 1992 21:01:45 GMT

In article <1992Oct10.022733.24514@netcom.com> geoff@netcom.com (Geoffrey Leach) writes:
>
>It appears that there is an unfortunate interaction between the C++
>class library NIHCL and X11's Xt intrinsics, in that both declare "Object".
>Is there a workaround, or am I missing something?

I think this shows up the massive shortcomings of C++'s namespace scheme.
Although as of 2.1 you can nest classes, you must define the entire class
inside the enclosing class (right?), which is not very practical for
something like the NIHCL (big header file).

Something like

class NIHCL {
    class Object;
    class ArrayOb;
    ...
}

would be useful.  Alternately, would declaring Object as

class NIHCL::Object {...}

without the forward declaration really hurt?

But then, suppose you're only using the NIHCL, and you don't really feel
like typing NIHCL:: every time you want to use one of its classes.  I think
that a 'with' directive, as per Ada, would be useful here...

--
Jason Merrill
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: static member and access control?
Summary: just because it's correct, doesn't mean it works
Date: 13 Oct 92 19:19:18 GMT
Organization: The University of Texas at Austin; Austin, Texas

In article <1992Oct6.133749.22272@cfa203.harvard.edu> murison@cfa203.HARVARD.EDU (Marc A. Murison, RG) writes:
>From article <1992Oct5.125039.16602@news.uni-stuttgart.de>, by LANG@nvdv01.ind.e-technik.uni-stuttgart.de (MARTIN LANG):
>> I have tried it with two different compilers. Cfront compiles without
>> error, Zortech complains because the enumaration is private. [...]
>> class Test
>> {
>>   private:
>>   enum E1 { a,b};
>>   static E1 e;
>> };
>> E1 Test::e=Test::a;
>
>Borland 3.1 complains with an error (no access to private...).

No, BC++ 3.1 does accept the above line

	E1 Test::e = Test::a;  // not strictly correct, but BC++ 3 compiles

That line is an error, I believe, because E1 must be qualified since
it is a nested type (BC++ makes it only a warning for backward
compatibility).  Btw, the "Test::" qualifier for "a" is redundant
since the initializer of a static is in the scope of the class.
Btw2, BC++ before 3.1 had even more problems with this.

So, the correct initialization is:

	Test::E1 Test::e = a;   // correct, but doesn't work under BC++ 3

Unfortunately, BC++ 3.1 erroneously flags this as an error.  It says
Test::E1 (not 'a') is not accessible.  Ironicly, the warning for

	E1 Test::e = a;  // incorrect, but portable to current compilers

correctly tells you to scope E1!

Jamshid Afshar
jamshid@emx.utexas.edu
From: sdk@cci632.cci.com (Stephen Knight)
Newsgroups: comp.lang.c++
Subject: Re: C++ Compiler for Mac.
Summary: MPW, Zortech or Think C (sort of)
Date: 15 Oct 92 18:30:54 GMT
Organization: [Computer Consoles, Inc., Rochester, NY

In article <1992Oct15.144054.26552@rs6000.bham.ac.uk> pickerig@dns0.bham.ac.uk (Mr. G. Pickering) writes:
>> Can anyone tell me if there is a Borland compatable C++ compiler
>> for the Macintosh?  I have written a program using Turbo C++, and
>> I would like to run it on the Mac without having to do a whole
>> bunch of re-coding.
> 
>What does "Borland Compatible" mean? Do you want a compiler that supports
>the C++ language as defined by ARM, or would you like one that supports
>any non-standard features of the Borland compiler.
>
>Sorry for the sarcy comment.
>
>If you do not get a reply about a product available on the Mac, there is
>one solution if all you want to do is a straight port:
>
>If you have access to CFRONT, you can use CFRONT purely as a translator
>to produce C code. This C code can then be compiled on the Mac using
>a normal C compiler.
>
>This solution isn't great, but if there is no other way...
>
>
>Guy.
>
	As far as I'm aware, there are only two C++ compilers for the 
Macintosh.  MPW C++, from Apple, is AT&T CFront 2.1.12 (my version) and 
runs under the MPW environment.  The other is Zortech's C++ (which I have
no useful information about, sorry).
	As a sort of C+-, there is Think C.  Which according to the manual
does not support operator overloading or multiple inheritance.

	To get MPW C++ to run on your Mac, you also need the MPW 
environment along with C and some other goodies.  The total price from
scratch will nail you for $750+.
	Think C (which almost certainly isn't "Borland" compatible) is
app. $200 (from find mailorders everywhere).

steve knight
sdk@cci.com
Newsgroups: comp.lang.c++,comp.lang.c,comp.os.msdos.programmer
From: 401yclee@vax9k.nchu.edu.tw (YC Lee)
Subject: TV/OWL memory models? <- revised
Organisation: National Chung Hsing University, Taiwan
Organization: NCHU, TAIWAN 
Date: Mon, 12 Oct 1992 05:00:40 GMT

Hi everybody,

I've been a long time reader to news, but until recently, this news reader can
only read but not write, so be tolerated with my bad etique(sp?).
I posted an article on comp.os.msdos.programmer last friday in a hurry with
vague indication about my question. Here's my revised statements:

The TV/OWL demo programs' project files or makefiles listed (at least all that
I've been thru), show them need Large memory models. My question is -

On what condition would the libraries require a large model for apps?
As the Installation process installed S, C, M, L model libraries as I
specified. <- This specification almost blows up my hard disk :-< 

Thanks in advanced.

YC

InterNet: 401yclee@vax9k.nchu.edu.tw
Newsgroups: comp.lang.c++
From: jgg@evb.com (Xmiester)
Subject: Re: NIHCL C++ class library and X11's libXt both use Object
Organization: EVB Software Engineering, Inc.
Date: Mon, 12 Oct 1992 01:37:57 GMT

 ark@alice.att.com (Andrew Koenig) writes:
>
>In article <1992Oct10.210145.12634@muddcs.claremont.edu> jason@jarthur.claremont.edu (Jason Merrill) writes:
>
>> But then, suppose you're only using the NIHCL, and you don't really feel
>> like typing NIHCL:: every time you want to use one of its classes.  I think
>> that a 'with' directive, as per Ada, would be useful here...
>
>Well, maybe.  Such things have a potential problem.  Suppose you have
>something like this:
>
>	int count = 0;
>
>	void foo()
>	{
>		count++;
>		// ...
>	}
>
>Suppose also that foo uses things from some library, which it brings into
>its namespace with something like Ada's 'with' directive.
>
>That means that if a future version of the library acquires a component
>named "count," it will conflict with the global one, either by hiding it
>or by causing an ambiguity.  Either way, the purpose of the feature has
>not been fulfilled.
>

This name conflict or ambiguity would only occur in Ada if 
the programmer not only "with"ed the package, but also "used" the
package.  The USE statement is pretty much regarded as a 
"don't use" feature of Ada by most software engineers, hence it
would only be a problem if you were not following "good" Ada programming
practices.

>For that reason, I think it is much more important in general to be able
>to import specific names than to import a namespace wholesale.  The latter
>might be handy sometimes, but it is essentially always hazardous.

Correct, for the same reason that most Ada software engineers don't
utilize "USE" statements to pollute the namespace.

John Goodsen
goodsenj@ajpo.sei.cmu.edu

-- 
John Goodsen
The Dalmatian Group
U.S. PCIS Expert Review Team
goodsenj@ajpo.sei.cmu.edu
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Another MSC 7 bug
Date: 16 Oct 92 22:12:52 GMT
Organization: Microsoft Corporation

In article <718597047snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
|Here is another bug I found in MS C7.
|Is anyone interested in these ?

Yes, MS is very interested in any bugs people find.

|Is there a better place for them ?

Yes, you can email them to me, or any other MS employee should be happy
to accept the responsibility of forwarding your bug report to the appropriate
people.

|Is there an existing list of known bugs (so I don't have to spend hours
|isolating them myself) ?

Yes.  This information is available via "MSDN" "Microsoft Developers Network"
which is a "don't make a profit" support service that MS has recently started
to support programmers.

Try (800) 227-4679 ext 11771 or CompuServe "GO MSDN"

|Needless to say, I do contact MS support when I find them, but I have the 
|feeling it's not doing me any good (they are hardly likely to rush me a 
|bug fix, are they ?). I wish they would accept bug reports via e-mail, 
|it's so much easier than hanging on the phone.

I'm not C7, but rather just an internal user of C7 like yourself,
but I would be happy to accept your or any other person's bug reports
by email.  I will verify them then forward them via internal email
channels to the appropriate people.

Believe it or not, people's bug reports *do* get logged into the bugs
database, the compiler developers *do* spend a lot of effort tracking 
bugs down and fixing them.  If you submit the bugs when you find them,
you'll find they get fixed at least by the next major release, and chances
are someone can tell you a good workaround in the meantime.
Newsgroups: comp.lang.c++
From: mittle@siena.watson.ibm.com (Josh Mittleman)
Subject: Re: My objects are too big - why?
Date: Fri, 09 Oct 92 19:28:08 GMT
Distribution: comp
Organization: IBM T. J. Watson Research

James Brister writes:

> Why must an empty class have non-zero size? Speculation around here was so
> that:
> 
> 		int foo ;
> 		base bar ;
> 		base bat ;
> 
> 
> would all have unique addresses.

Exactly.  That is the explanation given by ARM, p.164.  A more
immediately-understandable explanation might be so that the members of an
array of base will have distinct addresses.

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
From: ivo@NEXT.AGSM.UCLA.EDU (Ivo Welch)
Newsgroups: comp.lang.c++
Subject: Microsoft C/C++ 7.0 including Windows Development Kit
Date: 16 Oct 92 22:35:24 GMT


Unopened.   (I   received it   for     my   participation  in  their    
survey. Unfortunately, I found the package to be too overwhelming;  
I'll buy the MS QuickC for myself.)

For sale:  $200 +  shipping (obo  by  next Friday).  You *MUST*  have  
academic status (student, faculty, university staff).

/ivo welch
iwelch@agsm.ucla.edu
Newsgroups: bnr.lang.c++,comp.lang.c++
From: andrzej@bnr.ca (Andrzej Bieszczad)
Subject: Re: Is pointer in my address space?
Organization: Bell-Northern Research Ltd.,
Date: Fri, 9 Oct 1992 18:54:47 GMT

In article <1992Oct9.160154.2427@bnr.ca> crlstu4@bnr.ca (Goetz von Escher) writes:

   Hi there!

   Is there a way to find out if a pointer is a valid pointer in C/C++?
   Or in other words: If I want to read a value in memory, how do I
   know wether I can read the value at this address without causing
   an exception (bus error, segmentation fault and that stuff)?

   Anything?
   Goetz

Perhaps you can intercept the signals?

However, using an invalid pointer is a bug that should be fixed and
not handled. Use PURIFY to clean up your programs.

--
==========================================================================
Andrzej Bieszczad                     | Phone:  (613) 763-2259
Bell-Northern Research, Ltd.,         | Fax:    (613) 763-2626
Dept. 9K12, P.O. Box 3511, Station C, | email:	andrzej@BNR.CA
Ottawa, Ontario, Canada, K1Y 4H7      | "Welcome to the machine"-Pink Floyd
===========================================================================
From: smclewin@ultrix.ramapo.edu (Scott M McLewin)
Newsgroups: comp.lang.c++
Subject: Borland 3.1 nested comment highlighting problem.
Date: 8 Oct 1992 23:34:45 -0500
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu


In <1160@ncrspks.SparksNV.NCR.COM> karl@ncrspks.SparksNV.NCR.COM (Karl Held) writes:

>>My apologies if this topic has already been covered. Highlighting of nested
>>comments under Borland C 3.1 does not extend beyond the innermost comment.
>>Everything between the initial comment and the end of the most nested comment
>>is properly highlighted. The rest of the comments beyond the innermost comment
>>is not highlighted. Is anyone aware of a patch to fix this problem? Please
>>respond by email, if possible. Thanks in advance.
>
>It's highlighting the comment (from start of comment to first close of
>comment).  Comments don't nest unless you explicitly turn on the
>switch to allow it (which is, IMHO, a terrible idea).  The 'fix' for
>this 'problem' is to not nest comments.

But that switch is ignored by the syntax highlighter.   This is the 
glitch the original poster was commenting on.  I am not saying nested
comments are either bad or good, but if a company puts a feature in
their product, they should support it all around.

Scott
----
#include <disclaimer.h>
Newsgroups: comp.lang.c++
From: mittle@siena.watson.ibm.com (Josh Mittleman)
Subject: Re: My objects are too big - why?
Date: Fri, 09 Oct 92 14:10:39 GMT
Distribution: comp
Organization: IBM T. J. Watson Research

barmar@think.com (Barry Margolin) writes:
> In article <RWK.92Oct7142833@silver.sbi.com> rwk@silver.sbi.com
(Richard W. Kreutzer Consultant) writes:
> >When executed on a Sparc (with either AT&T cfront 2.1 or gcc-2.2.2)
> >sizeof(Derived) displays as 8.
> 
> Since you have virtual functions, the size 8 is due to 4 bytes for the data
> member of type int and 4 bytes for the virtual table pointer.

That doesn't entirely answer the question.  The same experiment without the
virtual function shows that sizeof(Base) = 1 and sizeof(Derived) = 8.   Any
idea why?

class Base { };

class Derived : public Base {
public:
  int a;
};

main () {
  Base b;
  Derived d;
  cout << sizeof(b) << " " << sizeof(d) << endl;  // output: 1 8
}

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
From: mallen@carla.Wichita (mallen)
Newsgroups: comp.lang.c++,att.lang.c++
Subject: GNU C++
Keywords: c++
Date: 7 Oct 92 13:13:16 GMT
Organization: wichita

Is anyone using the GNU C++ package for any development?  I'm curious how
it compares with commericial packages.  Please email me directly.

Thanks in advance.
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: My objects are too big - why?
Date: 16 Oct 92 22:32:26 GMT
Organization: Microsoft Corporation
Distribution: comp

In article <BRISTER.92Oct9112125@tirade.decwrl.dec.com> brister@decwrl.dec.com (James Brister) writes:
>Why must an empty class have non-zero size? 

Remember that sizeof(Foo) literally means the number of bytes an element
in an *array* of Foos takes.  Thus:

	Foo f[2];

	Foo* pf0 = &(f[0]);
	Foo* pf1 = &(f[1]);

	char* pc0 = (char*)pf0;
	char* pc1 = (char*)pc1;

	assert((pc1 - pc0) == sizeof(Foo));

Thus it is then obvious why sizeof(Foo) for an empty class Foo cannot be zero.

A compiler is not required to consume sizeof(Foo) bytes in other situations --
such as in single Foo autos, globals, inheriting from a base class....  However,
since many C/C++ programmers *assume* sizeof(Foo) is identically the
same as the number of bytes "always" consumed by a Foo, then so have to
the compiler implementers.  Otherwise programmers complain that they
just memcpy'ed between some auto's and their program mysteriously crashed....

Newsgroups: comp.lang.c++
From: feustel@netcom.com (David Feustel)
Subject: Re: Email address to Zortech Tech Supp
Organization: DAFCO: OS/2 Software Support & Consulting
Date: Wed, 7 Oct 1992 23:55:40 GMT

le@maja.teknikum.uu.se (Lars Ericsson) writes:

>I have encountered some problems with Zortech C++ v3.0r4 and would like to
>get in touch with their Technical Support group. Does anyone know if they
>have an email address?
>I can make zorlibx crash and think they might like to know how,
>in case they don't know it already.

	Zortech Technical Support			1992

DOMESTIC TECHNICAL SUPPORT

	Please call:		617-275-4800 (phone)
				617-275-2124 (fax)


FOR CUSTOMER SERVICE

	Please call:		800-441-7234 (USA+Canada)
				408-252-3570 (Others)


FOR EMAIL SUPPORT

	We have two accounts and a mailing list.

	ztc-bugs@zortech.com	For well-identified bugs.
			        You will NOT get a response.

	support@zortech.com	For technical questions.
				These will be answered by
				Zortech Tech Support

	ztc-list@zortech.com	General forum for our
				customers.


TO GET ON THE SYMANTEC BBS

	Please dial:		408-973-9598 (2400 Baud)
				408-973-9834 (9600 Baud)

OTHER 

	We also have accounts on Compuserve and Applelink. 				
Dyad's phone numbers are

(206) 637-9427
(206) 637-9428 FAX
(800) 366-1573

If you are not in either North or South America, for all
technical, sales, customer support please contact:


		Zortech Technical Support
		European Support Centre (ESC)
		Symantec, Ltd.,
		Kanaalpark  145
		2321  JV  Leiden
		The Netherlands

Their fax #:	+31-71-353-153
Their BBS #:	+31-71-322-852

Their telephone #'s are:

			The Netherlands:	+31-71-353-111
			Fed. Rep. of Germany:	+49-211-9917-110
			France:			+33-1-42-04-24-46

This includes upgrades, all technical info., etc.

The upgrade from 3.0rx to 3.0r4 is a free upgrade. However,
Symantec's European office is charging a $10 fee for shipping,
handling and customs costs.

-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
[.sig on vacation]
Newsgroups: comp.lang.c++
From: feustel@netcom.com (David Feustel)
Subject: Another Good C++ Book!
Organization: DAFCO: OS/2 Software Support & Consulting
Date: Fri, 9 Oct 1992 23:57:34 GMT

"Effective C++: 50 Specific Ways to Improve Your Programs and Designs"
by Scott Meyers(ISBN 0-201-56364-9, $24.95, Addison Wesley).

This book covers so many ways that you can hang yourself in C++ that I
wonder why someone doesn't write a Lint++ that checks for all of them.
-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
[.sig on vacation]
From: myhre@plains.NoDak.edu (Robert Myhre)
Newsgroups: comp.lang.c++
Subject: ProtoGen is worthless?!?
Date: 8 Oct 92 23:18:44 GMT
Article-I.D.: plains.21070
Organization: North Dakota Higher Education Computing Network


  HI all.  I recently purchased BC++ 3.1 and it includes a free copy of
Protogen.  However, from what I have seen from the initial reading the
Resource Workshop already does what Protogen does.  Further, Protogen
requires Resource Workshop for creating the menus, dlg, etc.  Can anyone
tell me what the real use of Protogen is?  I must have missed it!  :)

Thanks

Robert Myhre
Computer Engineer in Training... and Training... and Training
North Dakota State University
myhre@plains.nodak.edu   (Internet)     
myhre@plains             (Bitnet)      
uunet!plains!myhre       (UUCP)         
 
Newsgroups: comp.lang.c++
From: mcrocker@titan.ucc.umass.edu (MATTHEW S CROCKER)
Subject: Class library for TCP/IP  dBase
Organization: University of Massachusetts, Amherst
Date: Tue, 13 Oct 1992 12:44:33 GMT

This might not be the correct news group. as it is os specific, but
it is also C++ specific so here goes...

I'm looking for a good C++ classlib (Commercial or public) with 
classes for 
  TCP/IP
  database management

I'm looking to build a couple of client/servers in C++ using GNU C++
on an ultrix platform. (I will be porting to linux also)

Any help would be appreciated.

PLEASE RESPOND VIA E-MAIL
mcrocker@titan.ucc.umass.edu

advaTHANKSnce

-Matt


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- Matthew Crocker
s1949782@titan.ucc.umass.edu <-  Til 1/1/93
mcrocker@titan.ucc.umass.edu <-  Til I Graduate  LOOOOOOOONNG TIME
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
ReplyTo: nikki@trmphrst.35demon.co.uk
Subject: Another MSC 7 bug
Distribution: world
X-Mailer: cppnews $Revision: 1.19 $
Organization: Trumphurst Ltd.
Date: Thu, 8 Oct 1992 18:40:11 +0000

Here is another bug I found in MS C7.

Is anyone interested in these ?
Is there a better place for them ?
Is there an existing list of known bugs (so I don't have to spend hours
isolating them myself) ?

Needless to say, I do contact MS support when I find them, but I have the 
feeling it's not doing me any good (they are hardly likely to rush me a 
bug fix, are they ?). I wish they would accept bug reports via e-mail, 
it's so much easier than hanging on the phone.

------------------------------ cut here ---------------------------
class Base1 {
	};

class Base2 {
    };

class Derived : public Base1, public Base2 {
	};

class Command {
	int (Derived::*f)(void); 
	Derived *to; 
	virtual int doit();
	};

int Command::doit()
{ 
	return (to && f) ? (to->*f)() : 0; 
//x5.cpp
//x5.cpp(23) : fatal error C1001: INTERNAL COMPILER ERROR
//		(compiler file '@(#)grammar.c:1.147', line 179)
//		Contact Microsoft Product Support Services
}


---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
Newsgroups: comp.lang.c++
From: cnhasan@casbah.acns.nwu.edu (Nirmal Hasan)
Subject: Linking problems with g++ 
Organization: Northwestern University, Evanston, Illinois, USA
Date: Tue, 13 Oct 1992 16:33:51 GMT

I am new to programming on work stations. I have a program of about 7000 
lines in several source files, originally written on BC++. 
When I *compile* these files using g++ on a sun workstation, I get no problems. 
Problems come when I link them.  I get error messages like

ld: Unknown symbol
	__Foo_Bar__7FOOBAR

Now I have a function in my code called Foo_Bar() and a data structure called
FOOBAR, but nothing like Foo_Bar__7FOOBAR.

I am getting several messages like this. What is happening? Can somebody help
me with this?

Nirmal()
From: djd@csg.cs.reading.ac.uk (David J Dawkins)
Newsgroups: comp.lang.c++
Subject: Standard for Class Information?
Date: 15 Oct 92 09:20:42 GMT
Reply-To: djd@csug.cs.rdg.ac.uk
Organization: University of Reading

I was sitting here thinking how class browsers might work, and wondered
if C++ compilers should be able to produce a file containing class
descriptions according to a _standard_ format.  This would remove the
necessity for class browsers to be able to parse C++ code, and be
completely decoupled from dialect and compiler.

Does anyone know of any proposals in this vein?

Comments please.

-dave
-- 
djd@csg.cs.rdg.ac.uk
djd@csug.cs.rdg.ac.uk
davidd@integ.uucp