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:16:00 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
 
Newsgroups: comp.std.c++,hepnet.lang.c++,relcom.fido.su.c-c++,de.comp.lang.c++,ssc.comp.lang.c++,slac.lang.c++,comp.lang.c++
From: khoda@ptsun02.cern.ch (Arash Khodabandeh)
Subject: searching for FAQ
Organization: CERN, CH-1211 Geneva 23, Switzerland
Date: Sun, 8 Nov 1992 10:14:21 GMT

Can anyone send me the FAQ of this ng please?
Thanks,
A.


-- 
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
                              <>            Arash Khodabandeh
                              <>                  CERN
    /|                        <>               Division ECP
   /_|_ _, ,_  ,  /_          <>   CH-1211 GENEVE 23  F-01631 CERN CEDEX
  / \| / _(_/_/)_/ /          <>      Suisse                France
                              <>       Telephone : + 41 22 767 8263
			      <>       Email: khoda@ptsun00.cern.ch
			      <>              khoda@ptsun02.cern.ch
                              <>              akhodaba@cernvax.cern.ch
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
From: kilitzir@antigone.csi.forth.gr (Xristos Kilitzirakis)
Newsgroups: comp.std.c++
Subject: c++ implementation (hard)
Date: 12 Nov 1992 09:34:22 +0200
Organization: Institute of Computer Science, FORTH Hellas
NNTP-Posting-Host: antigone.csi.forth.gr
Summary: a implementation problem
Keywords: c++

Welcome to the hardline accoarding to XXXristos.
here's the problem:
suppose class a is a base class and b,c are derived,that is:

a--->b
|
---->c

all right by then.The problem is,that any operator between these
2 classes , can give any of the 4 classes,depending on many
things , not only the type of operands.for ex.
a+b --->c|d|a,
so I cannot define the return type ,before inspecting the operands.

Any suggestions of implementing (reordering,add a new class,
  forgetting the hole thing, etc).          ^^^^^^^^^^^^^^^

Well , the implementation is 
a -> m_n matrix
b-> n-n topelitz matrix (needs only 2*n-1 elems)
c-> n_n circulant matrix(needs only n elems)

It may look easy to you,but for me is ...
'the answer is always easy , when you know it'




XXXXristos
e-mail yr answers in
kilitzir@csd.uch.gr
kilitzir@csi.forth.gr
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.std.c++
Subject: Re: return values and destructors
Date: 12 Nov 1992 02:19:32 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <BxKs87.417@scd.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
>"A return statement with an expression can be used only in functions
>returning a value; the value of the expression is returned to the
>caller of the function."
>
>Given the statement
>
>	return foo;
>
>where foo is an object with some value, does the statement from the
>ARM mean that the compiler *must* return the value that foo has in the
>return statement, rather than the value foo might have at some point
>after the destructors for local automatic objects have been executed?

[ example deleted: it's designed so that the destructor of an auto
  variable will alter foo's value. ]

Your example is the kind of thing that I think language standards should
leave explicitly undefined; otherwise compiler vendors will have to
generate worse code just in case someone like you gets tricky. :-)

>Shouldn't both of these cases perform the same way?

I don't think so (if that means a change is required in the draft
standard, so be it).

>Is this a cfront bug?

Again, I don't think so.  I'm not willing to pay the cost of the
extra copy operation that might be required were the committee to
force your example to work.  It's simply not worth slowing down reasonable
C++ programs to have defined behavior on your unreasonable example (it is
cute, though).  There is already precedent: the ANSI
C standard leaves the order of side effects explicitly undefined in
examples like

	void func(int,int);
	int i = 3;
	func(i++,i++);

The ARM statement needs amendment in any case, as it says elsewhere that
the copy constructor is called to return objects, and there is no
guarantee that the user will write a proper copy constructor.





--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Unitialized dynamic reference
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 10 Nov 1992 01:31:15 GMT

In article <1dessbINNn1b@darkstar.UCSC.EDU> daniel@cse.ucsc.edu (Daniel R. Edelson) writes:
>
>The draft standard has the following to say about references:
>
>``The declaraion of a reference must contain an initializer except
>when the declaration contains an explicit extern specifier, is a
>class member, declaration within a class declaration, or is the
>declaration of an argument or return type.''
>
>So, given that, is the following illegal?
>
>	new (int&)
>
>All the compilers I tried permitted it.
>

	Wow, wonder what they allocated? IMHO: It does not make sense
to allocate a reference, only an object.
-- 
;----------------------------------------------------------------------
        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.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Date: 05 Nov 92 18:29:17 GMT
Organization: Microsoft Corporation

In article <1992Nov4.071814.10880@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|	Yes, I see. You are saying that by upgrading the requirements
|to a total order existing confrming programs which are not strictly
|conforming suddenly become non-conforming and are thus broken.

Yes, exactly.

|	Yes, I understand now I think. Leaving things 'implementation
|defined' is then a complete barrier to ever upgrading those things
|to be defined by the language without possibly breaking existing programs.

Yes, except the word is not "possibly" but rather "probably" because
the vast majority of programs written are written in non-portable manner
by programmers who neither understand nor care about portability.  Unfortunate,
but true.

I'm not saying that you can't ever change an "implementation defined" to
a "language defined" -- it just that you need to understand that such changes
are *major* changes to the language -- not *minor* changes, and you better
be darned sure that everyone buys into the associated cost.  Because a
lot of programs are going to be suddenly busted, and a lot of compiler
vendors are going to be solidly cursed by 100s or 1000s of customers for
"gratuitously" changing their compilers in ways that suddenly "bust" programs
that use to be "correct."  And such customers are right --  their programs
were "correct" -- just not strictly conforming.

|	It might be the case if the class used < for the purpose
|Andrew mentioned, and was otherwise a general purpose class.
|This makes the class (rather than the program) the thing that we want
|to make portable, i.e. the unit of reusability.

Agreed.  But note that requiring strict ordering would also make this
class non-portable non-reusable on systems using C++ OODBMSs -- because
you can't reasonably maintain a total ordering over a DB over a series of
complete or partial passivations/activations.  Also merging/splitting DBs
accross several computer systems becomes problematic if one assumes a total
ordering.

|	I have not had access to these proceedings so know nothing
|about previous battles. This sort of thing happens all the time here,
|it would be good if there were better access to the proceedings,
|as I'm sure you'll agree :-)

I agree, but the battles I was referring to happened even more moons ago
in the ANSI-C committee.  The ANSI-C committee was pretty smart.  Things
left implementation-defined were hard-won compromises between two or more
groups that couldn't agree and so agreed to not agree.  Unfortunately, such
has also got to be true of the ANSI/ISO-C++ effort.  You can only standardize
what people widely agree to.  Everything else has to remain implementation
defined.  If one faction or the other was truly "correct" in their strongly
held position, then one can only assume their compilers will ultimately win
in the marketplace -- and maybe could be agreed upon at the C+n standardization
effort ;-)

Newsgroups: comp.std.c++
From: lewis@sophists.com (Lewis G. Pringle)
Subject: Re: Zero-length structures and pointer comparisons
Date: Tue, 10 Nov 1992 18:52:47 GMT
Organization: Sophist Solutions

In article <1992Nov4.080805.13496@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
...
>I would first like to return to a much more important, related problem,
>which somebody brought up here rather recently.
>Namely, there is nothing in the ARM explicitly saying that
>p == q  might not yield 1 even when p and q are pointing at two different
>objects.  This hole makes e.g. some standard idioms in Stroustrup's books
>implementation dependent.

I'd like to ask a related question.

Given code like:

char* start = new char [10];
char* end   = start+10;
char* p     = start;

assert ((p >= start) && (p <= end));		// this is gauranteed by ANSI-C
p += 10;
assert ((p >= start) && (p <= end));		// this is gauranteed by ANSI-C
p = start;
p--;
assert (! ((p >= start) && (p <= end)));	// ???????

Is the last assertion portable? ARM/ANSI-C References?


				LeWiS.



-- 
Reading peoples signatures is a real waste of time.

lewis@sophists.com                                  (Lewis Gordon Pringle, Jr.)
From: daniel@cse.ucsc.edu (Daniel R. Edelson)
Newsgroups: comp.std.c++
Subject: Unitialized dynamic reference
Date: 6 Nov 92 22:50:51 GMT
Organization: University of California, Santa Cruz (CE/CIS Boards)
NNTP-Posting-Host: oak.ucsc.edu


The draft standard has the following to say about references:

``The declaraion of a reference must contain an initializer except
when the declaration contains an explicit extern specifier, is a
class member, declaration within a class declaration, or is the
declaration of an argument or return type.''

So, given that, is the following illegal?

	new (int&)

All the compilers I tried permitted it.

Thanks,
Daniel Edelson
From: yang@bmsr10.usc.edu (Fang Yang)
Newsgroups: comp.std.c++
Subject: Has anyone used C libraries in C++ program?
Date: 12 Nov 1992 10:02:39 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: bmsr10.usc.edu

I have a bunch of C libraries and want to used them in my C++ program.
Someone who has experience please E-mail me. Thanks. No flames.
 


Newsgroups: comp.std.c++
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Subject: Re: Can Standard C functions be overloaded
Date: Wed, 11 Nov 1992 18:26:05 GMT
Organization: University of Birmingham

In article <83359@ut-emx.uucp>, jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:
> Can Standard C functions be overloaded?
Yes - according to the book a function may have only one extern "C" defintion
but can also have as many C++ definitions as it wants.
-- 
    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)
 .  _\\__[oo 
.__/  \\ /\@  E-mail: B.A.McCauley@bham.ac.uk
.  l___\\        Fax: +44 21 625 2175
 # ll  l\\     Snail: 197 Harborne Lane, Birmingham, B29 6SS, UK
###LL  LL\\     ICBM: 52.5N 1.9W
From: mccauleyba@vax1.bham.ac.uk (Brian McCauley)
Newsgroups: comp.std.c++
Subject: Array anachronisms
Date: 6 Nov 92 19:03:20 GMT
Organization: University of Birmingham

Since array of objects requiring constructors can exit it follows that any
C++ complier must contain the requisite logic for automatically inserting
loops to handle arrays.

Why must be live with the anachonistic restictions on the use of array
variables?

typedef T TA[5];
TA a; //this correctly calls T::T() five times
TA b=a; // should call T::T(const T&) five times
TA b(a); // same as above
a=b; // should call T::operator=(const T&) five times

One can of course say...
T b[5] = {a[0], a[1], a[2], a[3], a[4]};
...but this is ugly and its unlikely that the optimizer will spot that it's
a loop. Also this won't work if the size of the array is not determined until
compile time (for example as a macro passed in from the makefile).

BTW I realise that that it may be possible to create a class TA with all these
properties but I don't think that should be necessary.

More controversially why can't we pass by arrays by value?

typedef T TA[5];
void foo(TA a); // should pass by value (and optionally give a warning)
void foo(TA& a); // if I'd meant this I'd have said it
void foo(T* const a); // if I'd meant this I'd have said it

void foo(T a[]); // should do what is always has but give:-
  // "Warning: obsolete argument declaration syntax"

There is some question as to how the complier should handle
void foo(T a[5]);
 ...like `void foo(TA a)' a lot of old programs would fail
 ...like `void foo(T a[])' uglier but pragmatically better

You may well ask, "How can...
 typedef T TA[5];
 void foo(TA a);
...and...
 void foo(T a[5]);
...mean something different?"

OK I agree is ugly, but there is a precedent in the new operator.

typedef T TA[5];
TA* p1=new TA; // valid
T* p2=new T[5]; // valid
T* p3=new TA; // invalid

I realise some old code would fail to compile correctly even with this
distiction but this is a reasonable price to pay for removing the language's
most unsightly wart.

Note that none of what I've proposed inteferes in any way with the use of an
array in a pointer context.

If this question has been flogged to death in the past, I'm sorry.
 
    \\   ( )  NO BULLSHIT! from BAM (Brian McCauley)          
 .  _\\__[oo  ============
.__/  \\ /\@
.  l___\\     E-mail: B.A.McCauley@bham.ac.uk
 # ll  l\\ 
###LL  LL\\
Newsgroups: comp.std.c++
From: daniel@cse.ucsc.edu (Daniel R. Edelson)
Newsgroups: comp.std.c++
Subject: Re: Unitialized dynamic reference
Date: 7 Nov 1992 17:29:59 GMT
Organization: University of California, Santa Cruz (CE/CIS Boards)
NNTP-Posting-Host: oak.ucsc.edu

In article <1992Nov7.160634.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
>In article <1dessbINNn1b@darkstar.UCSC.EDU>, daniel@cse.ucsc.edu (Daniel R. Edelson) writes:
>> ... is the following illegal?
>> 
>> 	new (int&)
>Yes the type of this expression is `int&*'. There is no such type!
>(Because if you try to take the address of reference what you get is the
>address of the thing referred to.)

This could conceivably be interpreted as returning the
address of the referent (just like taking the address
of a reference), though I don't think that's a
correct interpretation. My point is if this is clearly
illegal, some explicit mention should perhaps be made 
in the draft standard.

Daniel Edelson
Newsgroups: comp.std.c++,comp.lang.c++
From: kanze@us-es.sel.de (James Kanze)
Subject: Re: Operator -> cannot return non-class types?
Organization: SEL
Date: 13 Nov 92 19:16:17

In article <1992Nov11.092316.306@aut.abb.se>, dlarsson@aut.abb.se
(Daniel Larsson) writes:

|> > To my surprise, I noticed that operator -> can only return the following
|> > three types:
|> >    - a pointer to a class,
|> >    - a class, or
|> >    - a reference to a class.
|> > 
|> > This means I cannot do simple things like:
|> > 
|> >   template< class T >
|> >   class OffsetPtr 
|> >     {
|> >     public:
|> >       OffsetPtr();
|> >       OffsetPtr( T* );
|> >       ...
|> >       T* operator ->();
|> >       ...
|> >     };
|> > 
|> >   OffsetPtr<char> ptrToString;
|> > 
|> > What is the rationale behind this restriction? I couldn't find anything in
|> > C++PL 2nd ed. that mentions this restriction, although I didn't look too hard.

|> a->b
|>   ...where a is of a class type is interpreted as...
|> (a.operator->())->b
|>   ...which in turn may expand to...
|> ((a.operator->()).operator->())->b
|>   ...and so on.

|> but in all cases the thing on the rhs of the -> is a class member.
|> Since types other that structs and classes do not have members it
|> would be useless for operator->() to return anything other than a
|> pointer to a class or a class for which operator->() is also defined.

|> Now what you could do is define operator T* (). Unfortuneately if you
|> write `a->b' where a is of a class without an operator->() the
|> compiler does not try compiling it as `(*a).b' so you'll have to write
|> this out in full each time. Likewise you can't write `a[5]' but you
|> can write `*(a+5)'.

|> This has annoyed me in the past and I feel that the language
|> definition should employ user defined type conversions to resolve the
|> lh operand of the -> ->* and [] operators.

IMHO, this should only be a problem in templates.

Basically, I don't offhand see anything in the language definition
that would restrict an operator->() (the function) from returning
whatever it wishes.  On the other hand, there is no way to use this
operator *unless* it returns a pointer to a class.  This is no doubt
why your compiler introduced the restriction.

Normally, of course, you would never want to write a function that
could not be called.  However, in the case of templates, it is
possible that you might, since it could be called for the
instantiations using a class type, and any attempt to use it for the
instantiations using a non-class type would cause a compiler error at
the point of use.

(Actually, you can call the function, even for a non-class type
result, explicitly: "c = operator->( p ) ;", for example.  However, I
don't think that this is really the idea behind operator overloading.)
--
James Kanze			GABI Software, Sarl.
email: kanze@us-es.sel.de	8 rue du Faisan
				67000 Strasbourg
				France
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Array anachronisms
Date: 11 Nov 92 00:40:38 GMT
Organization: Microsoft Corporation

In article <1992Nov6.190320.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk (Brian McCauley) writes:
>Why must be live with the anachonistic restictions on the use of array
>variables?

I agree with your arguments, but some of the counterarguments are:

1) Its very confusing to have an array mean an array in one context,
and have an array mean a ptr in another context [note however, that
C++ *already* makes this distinction when passing an array by reference
to array]

2) What you ask is already achievable with a slight change of syntax
using templates:

	doBlah(array<int,5>)
	{
		....
	}

Since non-C-braindead-flavors of arrays can easily be implemented using
templates, why invent a new slightly-less-braindead implementation of 
arrays built-in to C++?  Instead, lobby the C++ libraries committee to
put the arrays features you like into their proposed array class template.
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: on "use", and the lvalue-ness of string literals
Date: 5 Nov 92 14:37:37 GMT

In article <18106@ksr.com>, jfw@ksr.com (John F. Woods) writes:
> Remember that a strictly conforming program cannot use "volatile"; it is not
> a guarantee of portability, it is a "portable" way to beg for mercy :-).

What leads you to that conclusion?  There are a few standard uses for
volatile as well as the implementation-defined ones: you must declare
local auto variables as volatile if you want their values preserved by
longjmp calls, and you must declare a variable that is accessed by both
the main-line code and an asynchronous signal handler as volatile to
avoid undefined behavior.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
Ever notice how tense grown-ups get when they're recreating? -- Calvin
From: mcsbc2gw@dct.ac.uk
Newsgroups: comp.std.c
Subject: C query
Date: 5 Nov 92 10:51:43 GMT
Organization: Dundee Institute of Technology

Another query.........

Does anyone know about a C - PASCAL converter or a database wich allows a C
user to lookup equivalent commands in PASCAL(Booo Hisss, I hear you cry, A
turncoat!!!!) I have to learn PASCAL due to the backward nature of the
lecturing at this college(Dundee Institute of Technology
Bell Street , Dundee).

Grateful for any assistance

The 'C' man.\
MCSBC2GW

p.s. 

Don't let your %s become %c's or we'll all be in trouble!!!!

C was developed from B

Was Dos developed from Tos ?
From: behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens)
Newsgroups: comp.std.c
Subject: Re: is fflush(stdin) conformant???
Date: 5 Nov 92 07:10:17 GMT
Distribution: comp
Organization: Technische Universitaet Muenchen, Germany

mgk@sql.sybase.com (Michael Keirnan aka Joe Cool) writes:

>I am not actually comtemplating using this construct. A coworker is
>enrolled in a course where the instructor has advised flushing stdin
>(yes, stdin) in conjunction with using scanf() to "flush the unwanted
>newline." This seemed rather odd to me, but hey, what do I know?
>So what sayeth the gospel on the subject?

It says: The behaviour of fflush() is only defined for output (i.e.
write) streams.
So, any given implementation might work the way your friend uses it,
not work that way, or play the Yankee Doodle :)

>The reason I'm interested is that someone teaching a course is
>advocating this usage, and IFF they are incorrect I'd like to set the
>record straight before legions of C-programmers adopt this method.

Good idea indeed :) This is somewhat in the same league (sp?) as assuming
the size of any given type, although less annoying :)

Soenke
-- 
===========================================================================
More than silver, more than gold, I need   !    behrenss@informatik.
electricity. I need it for my dreams.      !    tu-muenchen.de
(RACTER)                                   !  FIDO: 2:246/13 Soenke Behrens