HDTenEightyP/NetNews huggingface dataset:
From: jones@ils.nwu.edu
Subject: New Ph.D. Program
Organization: institute for the learning sciences
Date: Mon, 9 Nov 1992 20:03:13 GMT

T h e   L  E  A  R  N  I  N  G    S  C  I  E  N  C  E  S    P h. D.   P r o g r
a m


Preparing individuals for productive work and a   high quality of life in
today's society is a complex  challenge for schools and corporations. To meet
this challenge, Northwestern University has established a unique Ph.D. program
in the Learning Sciences. Its purpose is to advance the research and
development of innovative educational structures and technologies.

Research in the Learning Sciences is aimed at creating environments that offer
all students a rich variety of opportunities for learning to think effectively,
both within and outside of formal learning settings. Graduate student and
faculty research efforts are supported by a multimedia, networked computing 
infrastructure and an unusual commitment to developing technologies that
function effectively within their intended settings. 

The Learning Sciences is a synthesis of computational and social science
disciplines including artificial intelligence, cognitive and developmental
psychology, educational research, linguistics, computer science, anthropology
and fields that develop strategies for teaching complex subject matter. 

Through research, field work and apprenticeships, the Ph.D. program will
prepare its graduates to assume leadership roles in advancing the scientific
understanding and systematic practices of learning and teaching.

Students are eligible for competitively-awarded multi-year funding. To qualify
for financial aid, candidates should apply by January 15, 1992. Applications
received after that date may be  considered. Individuals with relevant teaching
experience or a strong academic  background in a field related to the Learning
Sciences are encouraged to apply. For  application materials or for further
information, contact:

Professor Roy Pea
Ph.D. Program Chair 
The Learning Sciences 
Northwestern University
1890 Maple Avenue
Evanston, IL  60201
phone: 708-491-8152
fax:    708-491-5258
email: jones@ils.nwu.edu
From: michael@sequent.com (Michael Squires)
Newsgroups: comp.lang.c++
Subject: Generate C++ from ANSI C?
Date: 11 Nov 92 03:03:17 GMT
Article-I.D.: sequent.1992Nov11.030317.14943
Organization: Sequent Computer Systems Inc.

I'm looking for a program which will read ANSI C header (.h) files
and generate a C++ "class" with the listed functions as methods.

(I know that I don't need to do this in order to call the functions
from C++. My problem is that I have some tools which read C++
class definitions and do Good Things with them, and I want to 
"objectify" some existing C API with minimal effort.)

That is, given a file - junk.h - with the following contents:

    int func1 (float x);
    void sub1 (int i, char c);

I'd like to generate two files - a "myjunk.h" which looks like:

    class junk {
    public:
	int junk_func1 (float x);
	void junk_sub1 (int i, char c);
    }

(not too tough so far! :-) )

and a "myjunk.cpp" which looks like:

    int junk::junk_func1 (float x)
    {
	return func1 (x);
    }

    void junk::junk_sub1 (int i, char c)
    {
	sub1 (i, c);
    }

Any suggestions?

			    Thanks,
			    Michael Squires
			    INTERNET: michael@sequent.com
			    CIS: 73510,1555
Newsgroups: comp.lang.c++
From: boag@world.std.com (Scott A Boag)
Subject: Criticisms Wanted
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: Tin 1.1 PL3
Date: Sun, 8 Nov 1992 21:14:56 GMT

Wow. I am kinda surprised at the amount of negative responses to an
honest question.

Two years ago we decided that we would go with C rather than C++ on
a large project.  I think that was the right decision then.  I have
a list of the reasons somewhere, but off the top of my head:

* This was a multiplatform project (Mac, Windows, HP-XWindows & SUN).
  At the time we were not comfortable that we could find acceptable
  compiler compatibility.

* At least on the Mac, our only choice was Apple's CFront. By the end
  of the project compile and link times were a significant problem
  for C.  C++ would have been disasterious.  Would the symbol tables
  fit in memory?  I doubt it.

* I was mistrustfull of debuging in C++, primarily because of the 
  need to do things like unmangiling.  In retrospect I think 
  needlessly so.

* It was hard enough finding good C programmers for the project.
  Because of the very quick ramp-up time on this particular project,
  I did not feel we could find good C++ programmers nor did we
  have time to train them.  Today there are many more programmers
  who are familiar with C++ than two years ago.

* C++ tends to do a lot of things behind your back, particularly
  with memory, such as automatic destructers being called on 
  exit from a function.  Lots more neat ways to hang yourself.
  Also, I would be, even today, mistrustfull of memory management
  in a large program on Windows or Mac when memory was a 
  problem.  

If I were to start the same project today, I would choose to go the
C++ route because of the more advanced state of the technology.

Good luck with your project.

-sb

-- 
**********************************************************
*  Scott Boag
*  
**********************************************************
Newsgroups: comp.lang.c++
From: hclam@cuse1.se.cuhk.hk (LAM Ho Cheong)
Subject: Linking C++ and C
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Wed, 11 Nov 1992 14:17:26 GMT

I got a problem of linking C & C++ programs using the Turbo C++ for
Windows on PC. I'm going to link some C source codes and some C++ 
source codes. I need to invoke certain C-like functions defined in a C++
codes in a C codes. However, the linker replies me that no such functions
have been declared. That means the functions defined in the C++ codes are
not accessable from the C codes. Can anyone give me some advice?

test1.cpp                          test2.c
...                                main()
void f(void)                       {
{                                     ...
    printf("Hello, World\n");         f();
}                                     ...
...                                }

linker error: "function _f is not declared in module "test2.c""!

It's natural because I'm using some more advanced stuff (C++) by a less 
advanced stuff (C). But, I need to solve this ...

I'll appreciate any advice sent to me at hclam@se.cuhk.hk

Thanks in advance.

Newsgroups: comp.lang.c++,comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: PROPOSAL: Hidden private parts of classes
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 7 Nov 1992 15:41:37 GMT

In article <1992Oct30.113234.15010@daimi.aau.dk> sabroe@daimi.aau.dk (Morten Sabroe Mortensen) writes:
>        Lately I've coded a lot of small libraries in C++, and been
>thinking, why it's not possible to hide private parts, -it doesn't 
>seem to be possible! 


	You will note that 'private' means inaccessible to the public,
not invisible. It was explicitly defined that way in the ARM.

	Having hidden data variables causes the compiler some minor
inconvenience, not knowing the length. However private non-virtual
member functions cause no problems (if they were allowed). These are
IMHO needed so as to be able to write small helper members in
the implementation, I've suggested this be allowed, a suitable 
syntax does not suggest itself though.

	Having an explict 'hidden' keyword could also be done:

	class A { ..
	hidden: int x;
	};

where x is not just inaccessible but invisible. (But not to the programmer)

	However there IS a way to separate the implementation and
the interface, namely to use an abstract class for the interface

	class X { public: f(); };
	class Y : public X { public: f(); private: int x;};

This makes x truly invisible to users of X objects, but not those
that must construct them. Note that this scheme will fail
if downcasting is allowed :-)

-- 
;----------------------------------------------------------------------
        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: paulf@cbnewsb.cb.att.com (paul.fillinich)
Subject: Re: WHERE CAN ONE BUY AN ELEGANT AND EFFICIENT CLASS LIBRARY?
Organization: AT&T
Date: Fri, 6 Nov 1992 20:26:25 GMT

In article <1992Nov6.150838.21490@alchemy.chem.utoronto.ca> mbersohn@alchemy.chem.utoronto.ca (M. Bersohn) writes:
>One is C++ Standard Components Release 3.0, sold by UNIX
>System Laboratories, 190 River Road, Summit, N.J. 07901. One person
>discussing this library pointed out that USL is a subsidiary of AT&T
>where the inventor, Bjarne Stroustrup, and his colleagues work. He said
>that the library had the strong influence of these experts.
>...
>There was universal agreement that C++ Standard
>Components is difficult to buy since USL is not too approachable. As
>one respondent said "They basically don't want to deal with
>individuals". 

Actually, we do indeed want to deal with individuals!  However I had not
had much indication of difficulty in connecting to the 800 number.  With 
this in mind, I would like to offer alternatives:

For those in the Northeast, Canada, and the Central part of the country,
please call Clemmie Hoffman at (919)379-5176 or email to gccab@gcss20.usl.com.

For those in the remainder of the East (ie. NY south and west to about 
Illinois, call Jeri Beenders at (908)522-6010 or email jerilyn@usl.com.

For those in the West (ie. Colorado westward) call Lynn Berry at
(919)379-5179 or email to gclcb@gcss20.usl.com.

If in doubt, call any of the numbers.  Each of these people is interested
in selling products.  They will call back!

However, if all else fails, call me at (908)522-5099 or email to paulf@usl.com.

>
>So I avoid, in principle, what SUN chooses.
>

Does this mean that if Sun chose the C++ Standard Components to resell, 
you would not buy them???

>mbersohn@alchemy.chem.utoronto.ca

Paul Fillinich
C++ Product Manager
Newsgroups: comp.lang.c++
From: jimw@empros.cxn.dec.com (Jim West)
Subject: What compliers are available for SCO/386 UNIX ?
Reply-To: j_west@zebpik.enet.dec.com
Organization: Random Mixed
Date: Tue, 10 Nov 1992 20:02:31 GMT



  I am looking for any info on available compilers for SCO UNIX on 386/486
machines.

  Any help will be greatly appreciated.

  Thanx,

-/ Jim /-
From: mike@sdd.comsat.com (Mike Stennett)
Newsgroups: comp.lang.c++
Subject: Confusion on :: and protected (Simple?)
Date: 13 Nov 92 15:41:27 GMT
Distribution: na
Organization: SDD, COMSAT Labs, Clarksburg, MD

This is probably a simple question.  I've looked in my manuals and
read the FAQ and I don't see why the following program does not work.

Can anyone tell me why?  (This is obviously a simplified example.)
Why does the :: operator interfere with the derived class accessing
the protected function?

I tried to compile with both DEC's cxx 1.0 and GNU's g++ 2.2.2 but got 
the following errors:

[39] cxx test.C
test.C:24: error: In this statement, "foo::print" is not accessible.
Compilation terminated with errors.
[40] g++ test.C
test.C: In function `int  static joe::something (int)':
test.C:24: method `int  static foo::print (int)' is protected


#include <stddef.h> 	// For "size_t" type
#include <iostream.h>	// For stream I/O

class foo 
{
public:
   int x;

protected:
	static int print(const int y) { cout << y << endl; return 1;}
};

class  joe : public foo
{
public:
   static int something(int z);
protected:
	 static int print(const int y) { cout << "what" << y << endl; return 1;}

};

int joe::something(int z)
{
    foo::print(5);
    cout << "Did it." << endl;
    return 1;
}

main()
{
    joe xyz;
    
    cout << "Starting Program" << endl;
    xyz.x = 4;
    xyz.something(4);
    cout << "Ending Program" << endl;
}

--
Signed: Mike Stennett           Domain: mike@sdd.comsat.com
Phone: +1-301-428-4083          Fax: +1-301-428-7747
USPS: COMSAT Labs, 22300 COMSAT Drive, Clarksburg, MD 20871
Newsgroups: comp.lang.c++
From: adam@dadhb1.ti.com (Adam Hudd)
Subject: Re: FortranTOc
Organization: Texas Instruments, Inc., Houston, TX
Date: Wed, 11 Nov 1992 20:42:34 GMT

Max, there's a FORTRAN77 to C/ANSI C/C++ translator around somewhere called
"f2c", just use archie to find it.

It uses a combination of structure statements and #defines to rework the COMMON
blocks, thus making the code very hard to read.  Also the format statements are
not reworked into printf() statements, but instead use the standard f77
libraries.

It does its job well, but you'll have to rework the code if you want it to be
pure C.
--
Cheers,
Adam Hudd               adam@dadhb1.ti.com             __o
Texas Instruments Inc,                                -\<,
Houston, TX                                     .....O / O
From: bab@se39.wg2.waii.com (Brian Button)
Newsgroups: comp.lang.c++
Subject: Problem defining underflow for Tcp streambuf class
Date: 12 Nov 92 14:52:09 GMT
Organization: Western Geophysical Exploration Products

I'm having a problem defining the return codes from the underflow
function for a Tcp streambuf class I've written.

The problem is that underflow only returns one of two conditions,
either a read failure or the first char successfully read. This works
if the data being read is static, but if new data is coming in all the
time, there seems to be a third case to be handled. It is possible
that there is no data available to be read now, but there will be in
the future.

The problem I had arose using sbumpc(). When data was available in the
get area, it was read and returned. When no data was already in the
get area, underflow was called to read it, which it did, provided
there was data available. If there wasn't, underflow was returning the
first character available in the get area, which was put there by the
previous read. The net effect of this was to have that character
returned to me every time I called underflow until something else came
available on the socket.

One way to handle this is to make underflow return EOF if nothing is
available on the socket. This would detect this case for us, and allow
us to use clear() to recover and check the socket later with another
call to sbumpc or whatever. The problem with this is that it would not
let us detect the difference between a no-data failure and a
socket-closed failure, from which there is no recovery.

Does anyone out there in net.land have any suggestions about this? I
have described it as a Tcp problem, but it really is more generic than
that, dealing with all cases in which data is received dynamically and
sporadically.

Thanks,

bab
--
|-----------------------|----------------------------------------------------|
| Brian Button          | email : button@wg2.waii.com                        |
| Design Engineer       |         71023.276@compuserve.com                   |
| Western Geophysical   | voice : (713)964-6221                              |
| 3600 Briarpark        |----------------------------------------------------|
| Houston, Texas  77042 |                  Opinions Be Mine!!                |
|-----------------------|----------------------------------------------------|
Newsgroups: comp.lang.c++
From: cgh6m@darwin.clas.Virginia.EDU (Craig G. Hocker)
Subject: Re: Need Yacc & Lex retargeted to C++
Organization: University of Virginia
Date: Fri, 13 Nov 1992 15:41:07 GMT

In article <BxJ8Gp.B9L@iat.holonet.net> rkinder@iat.holonet.net (Robert J. Kinder) writes:
>You might also look into a product called YACC++ by Compiler Systems (I
>think that's the company?).  Call or send e-mail and I'll look up the
>phone number for you.  It is very nice and much simpler than MKS YACC/Lex.
>-- 
>// rkinder@holonet.net            International Software Solutions, Inc.  -
>// Robert J. Kinder, Jr.                             Boca Raton, Florida  -
>//                                                        1-800-788-4774  -

This seems to be a topic of some interest, so I will mention a 
C++ Parser Class Kit I came across by accident yesterday while
downloading another file. Nobody has mentioned it.

anonymous ftp to  export.lcs.mit.edu

    contrib/yacc.shar.Z


warning: it's a beta version, but the author does seem to be actively
soliciting people to modify and send him enhancements.

I can't comment on it, since I haven't tried to do anything with it
yet.

cgh6m@darwin.clas.virginia.edu
Craig G. Hocker
NSF-Center for Biological Timing
University of Virginia, Charlottesville, VA 22901
---- yep, that means I'm a scientist and not a computer jock! ----
Newsgroups: comp.lang.c++
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Casting to an object of a derived class
Organization: University of Jyvaskyla, Finland
Date: Tue, 10 Nov 1992 10:34:49 GMT

In article <rmartin.721099675@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
> ...
>This is one of the difficulties with contravariant return types.  It
>would sometimes be very nice if a member function could return a
>pointer or reference to the most derived object, rather than to the
>base.  However, the language does not support this feature.

Of course, if the return type is a pointer or reference to a class,
the derived-class function _can_ return a reference or pointer
to a derived-class object.  Virtual functions will work correctly.
The big problem remains that only members declared in the original
return-type class can be denoted.

>It will, soon, support covariant return types, but these will require
>that each derived class repeat the function declaration with the new
>return type.

Of course they must do that:  how should the compiler or anybody
know otherwise that there is supposed to be a new return type?

Even if this becomes true, the above problem goes away only in the case
where it is statically known that indeed the function of the derived class
will be invoked.  The absence of run-time type information makes
covariant return types a less powerful feature in C++ than in other
OO languages.

> ...

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Newsgroups: comp.lang.c++,comp.std.c++
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: PROPOSAL: Hidden private parts of classes
Organization: University of Jyvaskyla, Finland
Date: Tue, 10 Nov 1992 07:11:10 GMT

In article <1992Nov9.032225.10320@taumet.com> steve@taumet.com (Steve Clamage) writes:
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>> ...
>
>If you mean private non-virtual member functions which don't appear in
>the class definition, it would cause another language change.
>Overloading is resolved before accessibility is checked.  Suppose we have:
> ...
> ...  Overloading
>is resolved first precisely to avoid quiet semantic changes based only
>on access rights.

In my opinion, it was a bad choice in the first place to resolve
overloading before accessibility, although the argument presented in the ARM
makes partial sense.  However, that argument does not apply at all
to this new suggestion:  since such helper functions were to be declared
outside the class definitions, they cannot be made accessible to derived
classes or outside cliennt just by changing access rights.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: John Matthews <jm@vcd.hp.com>
Subject: MPW C++ bug?
X-Useragent: Nuntius v1.1a5
Date: Thu, 12 Nov 1992 02:07:13 GMT
Organization: Hewlett-Packard

I seem to have run into a possible bug between the C++ compiler and the
MPW linker.
The problem concerns statically (globally) allocated objects with
constructors.
If the global object is not referenced anywhere else in the program, but
does have
a constructor that causes side-effects, I believe the semantics of C++
states that
that object must be constructed.

However, since the linker notices that no-one is actually using the
global variable,
it strips out the object, along with its constructor call, from the
program.

Although the code that ran into this problem is complicated, here is an
example
of the kind of problem I've encountered:

              int gGlobal = 0; // Used by main()

              main()
              {
                    // Should print out: "gGlobal = 1",
                    cout << "gGlobal = " << gGlobal << '\n'; 
              }

              class StaticClass
              {
              public:
                         StaticClass();
              };

              StaticClass::StaticClass()
              {
                        gGlobal = 1;
              }

              // Global declaration
              StaticClass gStrippedOutByLinker;

If I were to build this  program, neither gStrippedOutByLinker nor 
StaticClass::StaticClass() would be linked into the final program.
However, if I add the following line as the last statement in the main()
routine,
everything works as expected (gGlobal == 1).

I have created a class whose sole purpose is to have a
statically-allocated
constructor perform a useful action WITHOUT having to reference the
variable
anywhere in the program. I don't see any way I can currently achieve this.

John Matthews
Hewlett-Packard
From: allan@piano.sta.sub.org (Allan Brighton)
Newsgroups: comp.lang.c++
Subject: Re: Multiple Header Files Problem
Date: 10 Nov 92 15:29:27 GMT
Reply-To: allan@piano.sta.sub.org
Organization: Brighton Software

In article 721359424@thor, rmartin@thor.Rational.COM (Bob Martin) writes:
>A more interesting variation on this issue is the problem of "circular
>inclusion".  Consider a source file: "a.h" which includes "b.h".
>However, "b.h" includes "a.h".  This trivial example will fail to
>compile.  Unless the compiler is very clever (I haven't seen one yet),
>it will sit and spin until it exhauses some resouce (usually memory),
>and then it will die a horrible death.  If it prints an error at all,
>the error is nearly certain to have nothing to do with the circular
>containment.
>

Am I missing something here ?  I thought everyone puts #ifdefs at the
top of each .h file like this:

#ifndef _A_H_
#define _A_H_

#include <b.h>

class a {
..
};

#endif /* _A_H_ */

In this case, I don't see a problem with circular inclusion.




---

				--Allan Brighton
				  allan@piano.sta.sub.org
Newsgroups: comp.lang.c++