HDTenEightyP/NetNews huggingface dataset:
From: melby@dove.yk.fujitsu.co.jp (John B. Melby)
Newsgroups: comp.std.internat
Subject: Re: Cleanicode
Date: 21 Jan 93 14:20:28 GMT
	<2179@blue.cis.pitt.edu>
Organization: Open Systems Group, Fujitsu Limited, Yokohama
In-reply-to: djbpitt+@pitt.edu's message of 20 Jan 93 12:32:19 GMT

>In summation, it is clear to me that LGC should not be unified, but I
>would feel more comfortable if I could articulate what it means to be
>an autonomous script. Suggestions welcome, as always.

This is essentially the same message that I posted in a Japanese newsgroup
this morning, but anyway...

Latin, Greek and Cyrillic typefaces have traditionally been developed
separately, and ("TeX" notwithstanding) they are generally not combined
with each other to form words.  When a Greek or Russian word appears
in English text using an entirely different font from the Latin font,
it does not necessarily look out of place.

When a Chinese place name appears inside Japanese text using a Chinese
typeface (ignoring for the moment differences in official simplified
characters), it is legible but looks slightly out of place.  Whether
this means that Chinese and Japanese characters may be treated as a
single script, or that Japanese usage involves the "translation" of
Chinese place names from the Chinese script to the Japanese script,
depends on one's political bias.

-----
John B. Melby
Fujitsu Limited, Yokohama
melby@yk.fujitsu.co.jp
Newsgroups: comp.std.c++
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Compiler should generate virtual destructors
Organization: University of Illinois at Urbana-Champaign
Date: Fri, 22 Jan 1993 12:13:53 GMT

In <harvey.727664973@regina> harvey@opl.com (Harvey Reed) writes:

>db@argon.Eng.Sun.COM (David Brownell) writes:

>>...
>>So, a pair of proposals that I'd be happier to see accepted:

>>   (1)	It is an error for a class to have virtual functions and a
>>	nonvirtual destructor.

	A warning, perhaps.

>>   (2a) C++ compilers don't automagically generate ANYTHING for classes
>>	any more:  constructors, destructors, assignment and address-of
>>	operators, etc.  If such routines are used but not declared and
>>	defined, that is an error.

	Would break a large part of th the world (like all struct declarations
	for starters; see below).

>I think I would feel a lot better about my C++ compiler if I didn't
>have to make a copy-ctor private/unimplemented (as a safegaurd) just
>because I was afraid that I *might* be accidentally copying an object.
>It would be much better if the compiler simply said it was an error
>to copy without a copy-ctor (or whatever), then the programmer can:

>1) remove the need to copy
>2) install the proper method to do the copy

>This goes for all the other automagic stuff too! I cringe when I 
>think about automagically adding virtual destructors, even though
>they are most times needed...

	Another case for protecting programmers from themselves.  For:

		struct Point {
			int x, y;
		};

	I don't want to have to write a ctor and assign-op. especially
	when the generated ones would work perfectly.

	Whenerver one writes a class, one *has* to ask onesself: Do I
	need a ctor?  An assign-op?  One should have to ask onesself
	this regardless of whether the compiler did the default ones
	for one or not.  If one doesn't, then one is just careless.

	The default stuff is for convenience.  In my experience, and I
	would venture others', it's rare to have to forbid copy/assign
	anyway.  Unless you have a good reason to forbid them, who cares?
	Let users copy them.
-- 
	- Paul J. Lucas
	  AT&T Bell Laboratories
	  Naperville, IL
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.std.c++
Subject: Re: RESULTS: C++ file extension survey
Date: 24 Jan 93 05:32:37 GMT
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle

In article <1993Jan12.153045.15612@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
/In article <1569@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
/| Zortech C++ will recognize .cpp, .cxx, .cc and .c++ all as valid C++
/| filename extensions, though our examples all use .cpp.
/I have never been able to fathom why any compiler *cares* what file
/extension is used.

Because the driver program recognizes ASM, OBJ, C, C++, EXE, COM, LIB,
DEF files, etc., and tries to do the obvious thing with it. For instance,
if a .EXE file name is given, the driver assumes that is the name of the
output file wanted.

Also, the driver tries on various extensions if the user didn't type in
one. This can be a nice convenience.

If all else fails, the driver assumes it is a C++ or C program, depending
on if the -cpp is used or not.

As to whether a #include file is .h or .hpp or whatever, makes absolutely
*no* difference to the driver.
Xref: sparky comp.std.c++:2143 comp.lang.c++:20089
From: rvloon@cv.ruu.nl (Ronald van Loon)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Pointer to functions and const-ness
Date: 27 Jan 93 14:31:02 GMT
Organization: University of Utrecht, 3D Computer Vision Research Group
Originator: rvloon@triton.cv.ruu.nl

A question to all C++ gurus out there:

Consider the following class definition:

class test
{
  private:
    int iPrivateInteger;

  public:
    virtual void f(void (*)(int&));
    virtual void f(void (*)(const int&)) const;

    virtual void g();
    virtual void h() const;
};

The purpose of the two definitions of f (note the placing of const) is to pass
the integer 'iPrivateInteger' to the function that is passed as an argument.

Obviously, when a const object of this class is used, one does not want the
internal integer to change, hence the definition of the prototype is different
as well. 

Say I have two functions:

void non_const_function(int&)
{
}

void const_function(const int&)
{
}

The first one matches the prototype of the first 'f', the second one of the
second 'f'. So, if I pass 'const_function' to an object of this class, the
second 'f' should be called, and conversely if I pass 'non_const_function' the
first 'f' should be called.

The question is: is that correct ? Intuitively I would say yes, but maybe
function-parameters do not take 'const' into account. (in effect :

void (*)(int&) is equivalent to void (*)(const int&)); another possibility is
that void(*)(const int&) can be implicitly converted to void (*)(int&).

Any opinions ?
-- 
Ronald van Loon     | Consider this: In the United States, an automobile is
(rvloon@cv.ruu.nl)  | stolen EVERY 14.7 SECONDS. 
3DCV Group, Utrecht |   If that statistic scares you, think how we felt when we 
The Netherlands     | made it up. - Dave Barry, "CHRISTMAS BUYERS GUIDE"
Newsgroups: comp.std.c++
From: indukuri@eagle.sangamon.edu (Padmaja Indukuri)
Subject: need source code to create windows in TURBO C++
X-Newsreader: TIN [version 1.1 PL6]
Organization: Sangamon State University
Date: Sun, 24 Jan 1993 23:47:09 GMT

		Hi netters,
				I need source code for creating windows in
				TURBO C++. I have source code for creating 
				windows in ZORTECH C++. But it is missing a 
				header file  <disp.h>
				Can I get that header file from publishers?
				Can anybody send me source code or information
				regarding creating windows in TURBO C++ ?
				please send me email to 
				indukuri@eagle.sangamon.edu

				Thanks in advance
				Padmaja Indukuri
Newsgroups: comp.std.c++
From: dcb@slsveit (David Binderman (SWP))
Subject: Re: Compiler should generate virtual destructors
Organization: SEL-Alcatel LTS Dept. US/ES
X-Newsreader: TIN [version 1.1 PL8]
Date: Thu, 28 Jan 93 09:50:59 GMT

David Brownell (db@argon.Eng.Sun.COM) wrote:
: On the other hand, one of the things I'd really like to see changed is
: how much stuff a C++ compiler does "for me" automagically.  It's a rare

Agreed. What the C++ compiler does is a constant source of bugs.

: So, a pair of proposals that I'd be happier to see accepted:

:    (1)	It is an error for a class to have virtual functions and a
: 	nonvirtual destructor.

I'd vote for it being a warning. Then compilers can be graded on their
user friendliness.

: 	
:    (2a)	C++ compilers don't automagically generate ANYTHING for classes
: 	any more:  constructors, destructors, assignment and address-of
: 	operators, etc.  If such routines are used but not declared and
: 	defined, that is an error.

Agree 100%. Also, any compiler that implements a warning for a class which
only declares one or two of the (ctor, dtor, copy ctor) set would get my vote.

The C++ FAQ has other suggestions for a C++ lint to do.

Also, drop all this "struct is a class with different visibility". Our
programmers here have spent years learning what a C struct is. Don't change
it. Just make the restriction that any struct which defines a method
must be converted into a class. It makes life simple: a C++ struct can
only define data, and the moment it declares a method, then it
must be a class.

I'd also vote for any compiler which produced a warning for an inline method
definition

class K {
	void f() { // no !
	};
..
};

And another warning the compiler implementers out there might consider
is that if a constructor calls new, and the matching destructor does
not, then I want to see a warning for that destructor.

But hey, all this talk of improving the details of the compiler
implementation fails to address the real problem: The ARM has been
publically available for nearly three years now, and I have yet to see
a compiler which implements the ARM ( less Exceptions and Templates
obviously). Ok I will be able to use the full functionality of the ARM
when (if ?) the moment it arrives, but I can't even get a compiler
for a reasonable language subset.

I'm sure the reason for this is the complexity of the language. 
Me, I'd vote for Typesafe ANSI C with Objects thrown in. 
No inheritance, no virtual functions, no polymorphism. The rest is hard
for the compilers to implement, hard for the programmers to understand,
and hard to build reliable systems that work using those features.

Regards
--
David C Binderman     Dept US/ESI, Bau 60, SEL-Alcatel AG, Lorenz Strasse 10,
D-7000 Stuttgart 40, Germany      dcb@us-es.sel.de   Tel: +49 711 821 3841
From: slzvq@cc.usu.edu
Newsgroups: comp.std.c++
Subject: the difference between C and C++
Date: 26 Jan 93 14:24:20 MDT
Organization: Utah State University

I am  familiar with C language. But now C++ is getting popular. I want to know 
the difference between C and C++.
Waiting for an answer.
From: b91926@fnalng.fnal.gov
Newsgroups: comp.std.c++
Subject: structs that define nothing
Date: 25 Jan 93 17:12:22 -0600
Organization: Fermi National Accelerator Lab
NNTP-Posting-Host: fnalng.fnal.gov

Does the c++ standard have anything to say about the legality of a
construct like the following:

...
struct
{
  int a;
  int b;
};

...

Such an example appeared in a recent issue of "C++ Report". The
problem with this code is that it defines absolutely nothing.
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.std.c++
Subject: Re: Compiler should generate virtual destructors
Date: 26 Jan 93 22:54:09 GMT
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

In article <1993Jan23.081616.29910@us-es.sel.de> reindorf@us-es.sel.de (Charles Reindorf) writes:
>|> Actually, you could "new" them.  Just allocate the functions on the
>|> "heap", and free them when you are done.  Or, we could take a flying
>|> leap at the slippery slope and add garbage collection.
>
>Again, as you say, you have to free them "when you are done", but in 
>this situation, there is no natural idea of "when you are done". In 
>fact, whereas the natural lifetime of a nested function is until the 
>containing function completes, the natural lifetime of a bound function 
>is until the destruction of the object to which it is bound. How do you 
>ensure that whenever an object dies, that bound function trampolenes 
>which *might* have been generated for it are deleted? 

	The compiler doesn't bother to try. Leave it up to the programmer.
Nothing new here :-) After all, just killing the trampoline doesn't stop 
you calling it through the pointer you still have lying around.

>I can see no way that the solution can be implemented in a way that 
>doen't impact the normal performance of the system. 

	Just leave deletion of the trampoline up to the programmer
like all other dynamically created objects.

>
>None of this detracts from the fact that *nested* functions *can* be 
>implemented without impacting on the normal performance of the system, 
>and without requiring any special new constructs in the language (more 
>a relaxation of a rule). What's more, they are extremely valid for 
>situations where iterators are used for many general call-back 
>mechanisms which are considerably more awkward (or unsafe) when done 
>using one of the manual alternatives.

	Yes, callbacks are a compelling argument. Must
remember this for the proposal.
>
>Moreover, if nested functions are implemented, they imply an easy 
>manual solution to many cases where bound member functions might have 
>been required. Other cases where bound member functions might be 
>required can surely be solved through abstract base classes and in some 
>cases MI.

	But the bound members can be had easily
IF we have trampolines for the nested functions, without
any more loss of safety than you get with ordinary pointers.
(Although the effects of executing non-existant code,
or existant code for non-existant objects will be nasty,
if you dont like it --- dont use it)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------
Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: sprintf return value
Organization: TauMetric Corporation
Date: Thu, 28 Jan 1993 19:07:59 GMT

mharriso@digi.lonestar.org (Mark Harrison) writes:

>Will the C++ standard specify the return type of sprintf()?

Yes.  The C++ Standard will incorporate the library portion of the
ANSI/ISO C standard (with some minor modifications):

	int sprintf(char* buf, const char* fmt, ...);

It returns the number of characters stored in buf, like the rest of
the printf family.

Some C libraries have sprintf return buf (a char*), for reasons I
have never understood.  This is neither standard C nor standard C++.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: Use of nested functions
Date: 28 Jan 93 18:30:42 GMT
Article-I.D.: alice.24738
Reply-To: ark@alice.UUCP ()
Distribution: world
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <dak.728225605@cip-s03> dak@cip-s03.informatik.rwth-aachen.de (David Kastrup) writes:
> One problem with trampolines and self-modifying code is that there
> is no longer a separate, read only code space.

Sure there is; is just doesn't contain the trampolines.  Moreover, I don't
think anyone is talking about self-modifying code -- we're talking
about code that generates other code and then later executes it.
Once generated, the code is never modified.

My main problem with the technique, though, is that sometimes the
read-only code space is the *only* code space, especially in
secure applications.
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: harvey@opl.com (Harvey Reed)
Newsgroups: comp.std.c++
Subject: Re: Compiler should generate virtual destructors
Date: 25 Jan 93 16:21:54 GMT

ark@alice.att.com (Andrew Koenig) writes:

>In article <harvey.727664973@regina> harvey@opl.com (Harvey Reed) writes:

>> I like this! Compilers could have "compatibility" switches, but for 
>> those of us who would rather do it ourselves, we could use the
>> full strength version.

>The trouble with compatibility switches is that they force people
>who care about portability to write in the intersection of the language
>accepted in the two modes.

Would this apply if the "compatibility mode" was phased out over time?
In a similar manner to how C vendors gradually migrated to ANSI C?



-- 
++harvey
===========================================================================
internet:       harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
voice/fax:      617-965-0220    /  617-965-7599
Newsgroups: comp.std.c++
From: insinga@cyteen.zko.dec.com (Aron K Insinga)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: RESULTS: C++ file extension survey
Date: 27 Jan 93 19:25:12 GMT
Article-I.D.: nntpd.1993Jan27.192512.1571
Reply-To: insinga@cyteen.zko.dec.com (Aron K Insinga)
Organization: Digital Equipment Corporation


In article <1993Jan14.164336.23286@taumet.com>, steve@taumet.com (Steve
Clamage) writes:
|> This presupposes the common model of separate text files which are
|> processed by an identifiable compiler program, and that the text
|> files are kept in a file system using names files containing a
|> user-definable extension.
|> 
|> Absolutely none of this is required by the C++ language, so you
|> can't
|> put the required file extension in the C++ language standard.
|> -- 
|> 
|> Steve Clamage, TauMetric Corp, steve@taumet.com

If I may divert discussion from the name of a compilation unit to a header...

I disagree; the C standard supports the characters ".h" on the end of stuff
between angle brackets in #include preprocessor directives; do you think that
the C standard "presupposes the common model of separate text files"?

Of course, the alternate solution to this favored by the C++ committee(s)
(the last I heard; apologies if this solution has already been discussed here)
is to not require such characters on the end of the standard headers' names,
e.g. #include <iostream> (and if the implementation keeps these in files with
some particular file extension, it can supply the extension).

- Aron Insinga, insinga@tle.enet.dec.com
Newsgroups: comp.std.c++
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: Question about temporaries
Organization: Liant Software Corporation
Date: Mon, 25 Jan 1993 16:31:50 GMT

In article <C1DtoB.FJ3@fiu.edu>, feathers@serss0 (Michael Feathers) writes:
> 
> Has the ANSI committee done any more work of the lifetime of temporaries?
> I'm very curious about this aspect of the emerging standard.

At the Boston meeting last November, some straw votes were taken to get
the sense of the committee of the whole.  IMO there was a clear leader
among the possibilities which seemed viable at the time.  Unfortunately
no prize was awarded. :-)  38 voted that the following was acceptable,
and none voted that it was unacceptable.

     Temporaries are normally destroyed at the end of the statement
     in which they are created.  The exception is that temporaries
     created within a branch of a conditional (?:) operator are destroyed
     when that branch is completed (and analogously for && and ||).

I would say that the committee was ready to compromise and decide on this
except for one thing.  Nearly all of the discussion has assumed that we
know what is a "temporary".  When asked directly regarding the formal
argument x in the function
     class C { ...  C (const C&);  ... };
     void f(class C x) {   ... use x ...   }
most people would say x is _not_ a temporary.  On the other hand, a very
popular implementation of C++ gives x the same extended lifetime as a
temporary.  Also, more than one example presented in favor of long-lived 
temporaries has actually needed long-lived formal arguments!  If I recall
correctly, an example was
     String x, y;
     char *z;
     extern char *f(String);
     z = f(x+y);
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
From: b91926@fnalnn.fnal.gov
Newsgroups: comp.std.c++
Subject: Ambiuous constructor ctor?
Date: 28 Jan 93 16:26:11 -0600
Organization: Fermi National Accelerator Lab
NNTP-Posting-Host: fnalnn.fnal.gov

Is it legal for a class to have a member with the same name as one of
its base classes? If it is legal, how can these items be used in
ctor initializers in a constructor?
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.std.c++
Subject: Re: Use of nested functions
Date: 26 Jan 93 22:41:07 GMT
Article-I.D.: ucc.1993Jan26.224107.9187
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

In article <1993Jan22.081555.12027@us-es.sel.de> reindorf@us-es.sel.de (Charles Reindorf) writes:
>On the subject of "trampolenes" in the implementation of nested functions, 
>this >presumably means the following appraoch:
>
>Some people say that they "don't like" trampolenes, but don't seem to give any
>reason for it. 

	Separation of code and data is an important machine
principle for safety. Some machines (all the good ones :-) do not
allow executing things in the data area.

	Trampolines feel a bit like the Cobol ALTER statement:
dangerous hacks.

>The main objection I can see is that on some operating systems
>you are not allowed to do any run-time code generation. 

	Some OS may not grant the user the priviledges required
to generate and execute code on the fly. This is because
it is close to 'self-modifying' code, which is not
generally considerd very safe.

>But there again, in 
>these architectures there do exist other, 
>addmittedly less efficient workarounds
>to this problem, surely.

	Such as? I would LOVE to hear of one that did not require
the standard C/C++ function pointers to double in size.

>
>Other people talk about "bound" functions which presumably means that given an
>object a of class A with member function f, then "a.f" can be regarded as a new
>function (whose pointer can be taken) with a non member-function signature. The 
>only way I can see of using a trampolene appraoch for this situation is to place
>the trampolene for the function a.f into the object a itself. This increases
>the memory overhead for function a. In fact, the compiler would have to do
>this by default for every member function of a, because it won't know in
>advance which will be bound (without ghastly extensions to the language). This
>surely makes member function closures an impracticable and unworkable addition
>to the language?
>

	No, one can just leave it up to the user to delete the
trampoline---as for other dynamically allocated objects. It is not
as 'safe' as puting the trampoline in the object (or a pointer thereto),
but even that isnt safe (the trampoline could still be called
after it was deleted --- very nasty crash following, perhaps sometime
later).


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.std.c++
Subject: Re: Constructors and runtime typing
Date: 26 Jan 93 18:38:57 GMT
Article-I.D.: alice.24711
Organization: AT&T Bell Laboratories, Murray Hill NJ



ellis@parc.xerox.com (John Ellis @ Xerox PARC) writes

 > Regarding Stroustrup's proposal for runtime typing:
 > 
 > Suppose class B is derived from A and A's constructor calls typeof(*this):
 > 
 >     class A    {A() {...typeof(*this)...}; ...};
 >     class B: A {...};
 > 
 > (Excuse any mistakes in notation.)

It is typeid() not typeof().

 > When "new B" is evaluated, will typeof(*this) yield typeof(A) or
 > typeof(B)? 
 > 
 > The recommended implementation technique seems to suggest typeof(A),
 > and that's consistent with the handling of virtual functions within
 > constructors.  

typeid(*this)==typeid(A)

As you point out anything else would be inconsistent with the behavior
of virtual functions.


	Run-Time Type Identification for \*C (Revised). Proc USENIX 1992 C++ Conference

	x3j16/92-0121, WG21/N0198: Run-Time Type Identification for \*C (Revised yet again)

Both by me and Dmitry Lenkov. The latter was revised to reflect discussions at the USENIX conference and
elsewhere.
Newsgroups: comp.std.c++