HDTenEightyP/NetNews huggingface dataset:
From: osoelgaultier+@CMU.EDU (Stefan Monnier)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: The concept of templates considered ill designed
Date: 4 Oct 92 14:41:00 GMT
	<23796@alice.att.com>
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.lang.c++: 4-Oct-92 Re: The concept of
template.. Andrew Koenig@alice.att. (466)

> In article <BvM0DE.EA7@watcgl.uwaterloo.ca> pfbertra@watcgl.uwaterloo.ca
> (Philippe F. Bertrand) writes:

> > Also for code hiding, compilers should generate intermediate files for
> > templated code so that user's of a template class do not need to have access
> > to the source.

> This is primarily an implementation issue, not alnaugae issue.
> If enough people want compilers that behave that way, someone will
> create one.
> -- 
> 				--Andrew Koenig
> 				  ark@europa.att.com


I'm not so sure it is only an implementation issue.
But the suggested 'templates with type constraint' would
permit to change it into an implementation issue. (it the 
way chosen for Eiffel)

	Stefan

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
Newsgroups: comp.std.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Exception Specifications
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Wed, 30 Sep 92 20:56:56 GMT


First a little history.

When exceptions were accepted by
X3J16 there were some of us (including myself) who though (like Scott)
that exception specifications were useless.  However, there were
also many who felt they were essential to good programming.
The later included the only people (a medical software group at HP)
with experience using exceptions in C++. I asked them whether "out
of memory" had to always be included on their lists and they said
they didn't treat "out of memory" as an exception.

The people who liked failure clauses would have prefered that
the default condition be the same as an empty failure list.
That is if you don't say that a function can throw an exception
then it can't.  The result was a compromise, failure clasues are allowed,
but the default is to allow functions without them to throw any
exception.

-----
Now my opinion.

My impression is that if you design your system from scratch
(including all libraries) with failure clauses on all function
declarations and your compiler checks them for consistency
you gain some useful compile time type checking.  But in 
other circumstances there is little gained.

At the moment X3J16 is considering the implications of exceptions
for stream classes.  Some think that streams should only
be able to throw a particular kind of exception (tentatively
named ios::failure). Others (including myself) feel that a stream
should be able to throw an arbitrary exception. Remember, users
can define their own kinds of streambufs, so X3J16 can't know in advance
what kinds of conditions they might want to report.  

My intuition (not based on experience I confess) is that in
general it is more important to get specific information about
the conditions that caused an exception than it it to know that
it in occured in some stream operation. That is, it is better to
know that there was an "out of memory" or "database corruption" problem
than it is to know that there was a problem while doing a stream
operation.  This leads me to the conclusion that the iostream library
should not use failure clauses.
 
  -- Jerry Schwarz

Please. No followups about how throwing exceptions by streams
will break existing programs.  We're aware of that.  By default
streams will throw (almost) no exceptions and will catch any thrown
by a streambuf.
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: Exception Specifications
Date: 2 Oct 92 19:02:13 GMT
Article-I.D.: alice.23785
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Oct2.125244.14614@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:

> The handler has no way to know when it has to delete the exception object,
> short of there being a quasi-Boolean field 'delete_me' in Exception.
> Thus:

> struct Exception { int delete_me; };
> throw new Exception (1);
> Exception ex (0);
> throw ex;

These problems do not occur if you throw objects (rather than pointers)
and catch references.  In that case, the implementation takes care of
deleting things at the proper time.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.std.c++,comp.lang.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: The concept of templates considered ill designed
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Tue, 6 Oct 92 00:38:21 GMT

In article <TMB.92Oct3050715@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M.  
Breuel) writes:
> In article <1992Oct2.144959.18480@cadsun.corp.mot.com> shang@corp.mot.com  
(David (Lujun) Shang) writes:
> 
>    In article <1992Oct1.140643.9775@cadsun.corp.mot.com> shang@corp.mot.com I  
>    wrote:
>    Template is not a self-enclosed type-safe language feature, i.e. it cannot  
be  
>    compiled separately to ensure type-error free. All type errors about the 
>    class parameters are checked when the template is used.
> 
> Yes. However, the reason for this is not intrinsic in the template
> concept, but in the way templates were "integrated" with overloading
> in C++.
> 
> 					Thomas.

Could you explain your argument in more detail? As far as I can see, 
the reason for this is the intrinsic in the template concept: class 
parameters are not constrained. Are there any conflicts between the 
concept of constrained parameterized class and the concept of C++ 
overloading?

David Shang


Newsgroups: comp.std.c++
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: Exception Specifications
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Wed, 30 Sep 1992 17:11:43 GMT

In article <1992Sep29.201603.19289@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
>The more I think about it, the more I'm convinced that the uses for
>exception specifications are astonishingly restricted.  As I see it, you
>can't reliably put an exception specification on a function f if any of the
>following are true:
>
>    1.  A call to f might directly or indirectly lead to a call to g where
>        g lacks an exception specification.  A special case of this is
>        where g is a function written in another language, e.g., anything
>        in the standard C library.  Recall that functions without exception
>        specifications may throw anything.
>
>    2.  f is a template function.  In this case, f must be instantiated
>        using some unknown type T, and it is highly likey that f will
>        invoke some T-specific function (e.g. member function of class T).
>        However, there is no way to know what the exception specifications
>        are on the T-specific functions.
>
>    3.  f is a virtual function, because f may be redefined in a subclass
>        by some function f' that contains an incompatible exception
>        specification.  Recall that an exception specification is not part
>        of a function's type.
>
>The ARM refers to an exception specification as a "promise" (ARM 15.6.2c),
>but the above points make clear that this promise can't be given very
>often, or at least can't be relied upon very often.  Similarly, the
>discussion of why exception specifications are so lax is discussed in ARM
>15.5c.  The ARM also implies that special-purpose static analyzers would be
>required to do much of anything with exception specifications, especially
>in the presence of separate compilation.  (For example, if f contains an
>exception specification and calls virtual function g which also contains an
>exception specification, no warning can be issued if g is redefined by an
>incompatible g' in a derived class that is contained in a separate
>compilation unit.)
>
>All of which leads me to believe that exception specifications are not
>really designed for the "general use" suggested in the last paragraph of
>commentary in ARM 15.5c.  That being the case, I'm tempted to suggest they
>be removed from the language.  For the specialized applications that can
>make use of them, an Anna-like annotation language seems more appropriate
>than actual language support within C++.
>
>Comments?
>
>Scott
>

	I agree that these situations are conceptually difficult.  Take a look
at section 15.6.2, though: the unexpected() function is called when a function
with an exception-specification throws an exception that is not listed in the
exception-specification.  Presumably, the runtime support for exceptions is
supposed to handle checking that the exception thrown is one that does not
violate the exception-specification.  I don't have any experience with
exceptions, so I'm not in a position to comment on the usefulness of this
construct.
From: pds@lemming.webo.dg.com (Paul D. Smith)
Newsgroups: comp.std.c
Subject: timezone info left out of time.h?
Date: 1 Oct 92 23:32:22 GMT
Organization: NSDD/ONSD, Data General Corp., Westboro, MA

From the Rationale and examining the available functions the standard
allows an implementation to either be aware of timezone info or not
(by setting tm_isdst to a negative value and returning NULL from
gmtime()).

Given that, does anyone have any opinions on why some method of
determining the local timezone displacement from UTC was not included
in the standard?  It could easily be made to return some invalid value
in the event timezone info is not available, just as gmtime() etc.

Without such functionality as far as I can see it is impossible to
determine the timezone offset in a standard way.  This also means that
given a struct tm filled with UTC time you cannot standardly (new
word :) convert it into a time_t.
--

                                                                paul
-----
 ------------------------------------------------------------------
| Paul D. Smith                          |    paul_smith@dg.com    |
| Data General Corp.                     | pds@lemming.webo.dg.com |
| Network Systems Development Division   |                         |
| Open Network Systems Development       |   "Pretty Damn S..."    |
 ------------------------------------------------------------------
Newsgroups: comp.std.c
From: eyal@echo.canberra.edu.au (Eyal Lebedinsky)
Subject: should abs() be 'uint'?
Summary: there is a problem with 0x8000...
Keywords: abs
Organization: Info Sci & Eng, University of Canberra, AUSTRALIA
Date: 27 Sep 92 00:02:14 GMT

I did not see discussion or find it in the usual books but I did have
programs fail due to the fact that (with 16 bit ints) abs(0x8000) is
0x8000 which is still negative.

If the function was 'unsigned int' then the result would ALWAYS fit into
the return type. Of course, 'a < abs(x)' may force the compare to be
done in a wider type on 16bit implementations.

Newsgroups: comp.std.c
From: "jane griscti" <jane.griscti@canrem.com>
Subject: circles and b-trees
Reply-To: "jane griscti" <jane.griscti@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 29 Sep 92 16:45:40 EST

TO:paul@ais.org    
  
   
PV >   Newsgroup: comp.std.c
PV >  Message-ID: <Bv1snB.284@ais.org>
PV >     Subject: Circles and B-trees
PV >
PV > Please resond via email since I don't subscribe here.
PV >
PV > Does anyone have an algorithm for deletion of a node in a
PV > B-tree?  If so could you mail it to me. Thanks

       Hi Paul ... You may want to check out the September '92 issue
       of 'The C Users Journal'.  There's an article on page 103 called
       Data Structures: Part 16: Trees III which includes code for
       removing a node in a B-tree.

       Hope this helps... Jane

       P.S. If you can't locate the magazine and don't get code from
       anyone else let me know and I'll e-mail the info.



---
  JABBER v1.1 #120  The only thing that makes life possible is permanent uncertainty
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.std.c
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Subject: Re: Change to time() fn?
Organization: Technical University Vienna, Dept. for Realtime Systems, AUSTRIA
Date: Fri, 2 Oct 1992 17:27:40 GMT

alpha@waggen.twuug.com (Joe Wright) writes:

>Please remember that floats (and doubles) are approximates.
>The value of time_t must be precise.  We don't like a value
>which says 'it's almost 5 o'clock'.  Precision requires
>time_t to be an integer.

But it is the other way round. When your clock says `it is 5 o'clock',
it isn't exactly 5 o'clock, but a little earlier or later (even if the
clock is exact, the information will be outdated by the time it gets to
the CPU). Also, floats and doubles are just as exact as integers---they
have a finite set of values they can represent exactly. If you want to
represent a value which is not in that set you have choose the
nearest representable value or admit it can't be done.

As a side note, the IEEE double has 53 bits of mantissa, so you can
represent the integers -(2**52-1) ... 2**52-1 exactly, which is a much
larger range than long offers on most implementations.

	Peter
-- 
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Dept. for Real-Time Systems           | in action!    |
| __/   | hp@vmars.tuwien.ac.at                 |     Tony Rand |
Newsgroups: comp.std.c
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Subject: Re: Change to time() fn?
Organization: Technical University Vienna, Dept. for Realtime Systems, AUSTRIA
Date: Fri, 2 Oct 1992 17:15:18 GMT

flaps@csri.toronto.edu (Alan J Rosenthal) writes:

>Well, time_t must be a type which can be cast to and from -1.  So there's no
>reason it couldn't be a struct __timeval, with a special case in the compiler,
>right?
[lots of special cases deleted]

Why not just build an arithmetic type of the required precision into
the compiler (if long or double do not have enough digits)? Not much
more work and you can use it for other things, too (like GCC's long
long).

	Peter
-- 
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Dept. for Real-Time Systems           | in action!    |
| __/   | hp@vmars.tuwien.ac.at                 |     Tony Rand |
Newsgroups: comp.std.c
From: pds@lemming.webo.dg.com (Paul D. Smith)
Subject: Re: timezone info left out of time.h?
Date: 05 Oct 92 15:47:25 GMT
	<1992Oct3.042403.1567@nntpd.lkg.dec.com>
Organization: NSDD/ONSD, Data General Corp., Westboro, MA

[] Regarding Re: timezone info left out of time.h?;
[] diamond@jit345.bad.jit.dec.com (Norman Diamond) writes:

    nd> In article <PDS.92Oct1193222@lemming.webo.dg.com>
    nd> pds@lemming.webo.dg.com (Paul D. Smith) writes:

    >the standard allows an implementation to either be aware of
    >timezone info or not (by setting tm_isdst to a negative value and
    >returning NULL from gmtime).  [...] does anyone have any opinions
    >on why some method of determining the local timezone displacement
    >from UTC was not included in the standard?

    nd> Your local timezone displacement (in Massachusetts) now is -4
    nd> hours but next month will be -5 hours.  It is only meaningful
    nd> to compute local time for a particular instant of time.

And your point is? :)

It is quite obvious that this is the case, which is why you usually
see "EDT" or "EST" or some such appended to a time statement--I'm not
sure I get the point but I assume you mean that providing a global
variable or function which returns the local TZ displacement is not
necessarily accurate if used across DST boundaries?

If the standard allows you to calculate local time, then it should
provide a method of determining the offset of that time from UTC.
That seems only reasonable.  In this day and age of multi-national
standards, email, etc. a time statement like "12:43:23" is less than
useless, it's very likely misleading.

I agree that there are problems with a scheme like a global variable,
although I can easily think of at least one way of working around
them; I much prefer an added field to struct tm specifying the
displacement.  I just can't understand why such a thing was omitted,
since there is precedent for allowing "invalid values" for systems
which can't determine this offset.
--

                                                                paul
-----
 ------------------------------------------------------------------
| Paul D. Smith                          |    paul_smith@dg.com    |
| Data General Corp.                     | pds@lemming.webo.dg.com |
| Network Systems Development Division   |                         |
| Open Network Systems Development       |   "Pretty Damn S..."    |
 ------------------------------------------------------------------
Newsgroups: comp.std.c
From: eggert@twinsun.com (Paul Eggert)
Subject: Re: timezone info left out of time.h?
Organization: Twin Sun, Inc
Date: Fri, 2 Oct 1992 22:43:24 GMT

pds@lemming.webo.dg.com (Paul D. Smith) writes:

	as far as I can see it is impossible to determine the timezone
	offset in a standard way.  This also means that given a struct
	tm filled with UTC time you cannot standardly (new word :)
	convert it into a time_t.

It's not trivial, but it's possible: just take the difference between
localtime and gmtime, as shown below.  Once you have this, it's fairly
easy to use mktime to convert a UTC struct tm to time_t -- but watch out
for integer overflow!

/* Figure out which time zone you're in.  */
/* Most of this code will be distributed as part of RCS.  */
/* Copyright 1992 by Paul Eggert */

#include <time.h>

#define TM_YEAR_ORIGIN 1900

static long difftm(struct tm const *, struct tm const *);

/* Set *ZONE to the number of seconds east of GMT.
   Yield 0 if successful, -1 otherwise.  */
int
timezone_offset(long *zone)
{
	time_t now;
	struct tm *t, gmt;

	if (time(&now) == -1 || !(t = gmtime(&now)))
		return -1;
	gmt = *t;
	*zone = difftm(localtime(&now), &gmt);
	return 0;
}

/* Yield A - B, measured in seconds.  */
static long
difftm(struct tm const *a, struct tm const *b)
{
	int ay = a->tm_year + (TM_YEAR_ORIGIN - 1);
	int by = b->tm_year + (TM_YEAR_ORIGIN - 1);
	return
		(
			(
				(
					/* difference in day of year */
					   a->tm_yday - b->tm_yday
					/* + intervening leap days */
					+  ((ay >> 2) - (by >> 2))
					-  (ay/100 - by/100)
					+  ((ay/100 >> 2) - (by/100 >> 2))
					/* + difference in years * 365 */
					+  (long)(ay-by) * 365
				)*24 + (a->tm_hour - b->tm_hour)
			)*60 + (a->tm_min - b->tm_min)
		)*60 + (a->tm_sec - b->tm_sec);
}
Newsgroups: comp.std.c
From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: strtoul on negative numbers
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Thu, 1 Oct 1992 02:38:45 GMT

In article <1992Sep30.175835.7972@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>What is the result of 
>    strtoul("-2", (char**)0, 10)
>The description is clear that the minus sign is allowed.

The description is schizophrenic.  ANSI 4.10.1.6, page 153 line 20:
"a subject sequence resembling an unsigned integer"
(in contrast to strtol, ANSI 4.10.1.5, page 152 lines 23 to 24:
"a subject sequence resembling an integer").
But later, page 153 lines 25 and 28 and 31 allow a plus or minus sign.

Lines 22 to 23:  "Then it attempts to convert the subject sequence to an
unsigned integer, and returns the result" (again in contrast to strtol,
which omits the word "unsigned").  So do negation and an implied cast to
unsigned occur during this conversion?
Lines 40 to 41:  "If the subject sequence begins with a minus sign, the
value resulting from conversion is negated."  So does negation occur
after conversion is finished?  Is there no implied cast to unsigned?

>The relevant sentence describing the result is.
>"If the correct value is outside the range of representable values
>ULONG_MAX is returned ..."

Uh yeah, but which is the "correct" value?
I think that section 4.10.1.6 seems both self-contradictory and ambiguous,
so it is impossible to fully conform, but possible in several ways to
partially conform.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: struct hack
Organization: SoftQuad Inc., Toronto, Canada
Date: Wed, 7 Oct 92 00:14:50 GMT

> I have been following this thread for a while, and since nobody else
> seems to have said it, I will.
> 
> >     struct fred { int i; char s [1]; } *f;
> >     char *s;
> > 
> >     /* ... */
> >     f = malloc (sizeof f + strlen (ss));
> >     f->s[1 /* or 2, or anything other than 0 */] ;
> 
> ... As is pointed out in previous posts, the pointer returned by malloc
> points to an area big enough for the job.  In fact, the following
> should be legal:
> 
>     char *p = malloc( sizeof( struct fred ) + strlen( ss ) ) ;
>     p += offsetof( struct fred , s ) ;
>     p[ 1 /* Or anything up to the end of the malloced memory */ ]
> 
> The problem with the example is that the pointer under consideration
> is *not* the pointer returned from malloc, but rather the results of
> the pointer expression f->s (which has a type of char*).

Correct, but this does not affect the relative legality of the two
expressions.  The standard says in 3.1.2.5 (ANSI, 6.1.2.5 in ISO) that
a value of pointer type "provides a reference to an entity of the
referenced type".  That is, a char * points to ONE char.  Whether that
char happens to be part of a larger object is irrelevant; this fact
cannot be represented in the type.  Suppose the above examples to be
modified so that f and p are initially copies of the same value returned
by a single call to malloc(), with the subsequent operations the same.
The expressions p and f->s point to the same char; therefore they are
wholly identical; assuming that strlen didn't return 0, p[1] is legal;
therefore, under the same assumption, f->s[1] is legal.

The restrictions in 3.3.6 (6.3.6) that allow bounds checking are on
the additive operators (and therefore implicitly on subscripting, of
course).  They are expressed in terms of whether the operand pointer
value and the resulting value point to elements of the same array or
not; there is nothing about HOW the operand value pointing into that
array was obtained in the first place.  In this case the values do
point to elements of the same array, namely the malloc()ed one.  QED.
-- 
Mark Brader		  "Should array indices start at 0 or 1?  My ecumenical
SoftQuad Inc., Toronto	   compromise of 0.5 was rejected without, I thought,
utzoo!sq!msb, msb@sq.com   proper consideration."  -- Stan Kelly-Bootle

This article is in the public domain.
From: prato@qut.edu.au
Newsgroups: comp.std.c
Subject: C routines to print barcodes on HPLJIII
Date: 2 Oct 92 15:54:29 EST
Organization: Queensland University of Technology


Would anybody know where I may obtain a copy of Borland C 
routines that would print barcodes on a HP Laserjet III?

If anybody has experience/knowledge in this area,
please let me know.

Your assistance would be greatly appreciated.

James Prato,
Computer Systems Officer,
MIS Section,
Queelnsland University of Technology,
Brisbane. Qld
Australia.
email:J.PRATO@qut.edu.au