HDTenEightyP/NetNews huggingface dataset:
From: amf@amfent.Gwinnett.COM (Andy Feibus)
Newsgroups: comp.std.c++,comp.std.c
Subject: Re: Question about sizeof in C/C++.
Date: 17 Dec 92 14:10:55 GMT

jamesc@swapsdev.state.state.COM.AU (James Cribb) writes:
> Given
> 
>     struct Something*  ps;
>     unsigned  k;
> 
> do the C or C++ standards guarantee that
> 
>     &ps[k] == ((char*) ps) + k * sizeof(struct Something)
> 
> I'm asking because I have C++ code that relies on this.
> It works on Suns but is it portable?
Assuming that you [cm]alloc enough memory for ps to support accessing the
k'th element of it, the answer is... no.  Different compilers see &ps[k]
differently; use parentheses to clarify: &(ps[k]).

-- Andy.
andyfe@utoday.com
Newsgroups: comp.std.c++
From: dasdipa@zeus.franklin.edu (Dipankar)
Subject: c++ book
Organization: Franklin University
Date: Fri, 18 Dec 1992 02:09:18 GMT

I know c on unix system. I am trying to learn c++ by my own. Anybody can
suggest me a good(easily understandable) book on c++ on unix system.

thanks

e-mail: dasdipa@zeus.franklin.edu

Xref: sparky comp.std.c++:1837 comp.std.c:3231
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c++,comp.std.c
Subject: Re: Question about sizeof in C/C++.
Date: 17 Dec 92 22:30:23 GMT
Followup-To: comp.std.c++

In article <wwJXVB3w164w@amfent.Gwinnett.COM>, amf@amfent.Gwinnett.COM (Andy Feibus) writes:
> Different compilers see &ps[k]
> differently; use parentheses to clarify: &(ps[k]).

Anything that sees &ps[k] as being different than &(ps[k]) is
*NOT* a C compiler.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
I think we need to change the rules. -- Calvin
From: teuben@lynx.astro.umd.edu (Peter Teuben)
Newsgroups: comp.std.c++
Subject: Template names
Date: 16 Dec 92 21:23:05 GMT
Distribution: comp
Organization: University of Maryland, Astronomy Department


If one defines a template as e.g.

  template <class T> class star {
	...
  };

and also define a real class with that same 'template' name, i.e.

  class star {
        ...
  };

the Borland C++ compiler (3.0) complains. Can anybody confirm if this 
is a Borland bug?

	Peter
--
Peter J. Teuben         |  INTERNET  : teuben@astro.umd.edu
Astronomy Department    |  FAX:        (301) 314-9067
University of Maryland  |  MA-BELL   : (301) 405-1540 (office)
College Park, MD 20742  |              (301) 405-1502 (secr.)
From: larsn@Autodesk.COM (Lars Nyman)
Newsgroups: comp.std.c++
Subject: Re: Must derived class reserve space for an empty base class?
Date: 18 Dec 92 18:47:33 GMT
Organization: Autodesk Inc., Sausalito CA, USA

jimad@microsoft.com (Jim Adcock) writes:
|class A {};
|
|class B : public A
|{
|public:
|	A a;
|};
|
|main()
|{
|	B b;
|	A* p1; 
|	A* p2;
|
|	p1 = &b;
|	p2 = &(b.a);
|
|	if (p1 == p2)
|		printf("equal %lX %lX\n", (long)p1, (long)p2);
|	else
|		printf("unequal %lX %LX\n", (long)p1, (long)p2);
|
|	return 0;
|}

ARM p74:  "Two pointers to the same object compare equal".
ARM p163: "An object of a class consists of a (possibly empty) sequence of 
	   members".

I don't know if ARM defines what "same object" means.
But, it seems to me a member is a different (i.e. not the same) object than
the "enclosing object".  

E.g. using the example above, 'b' is not the same object as 'b.a'.

Therefore, according to ARM p74-75, the pointer comparison in the example
above 'p1 == p2' (in effect '((A*) &b) == &b.a') is implementation dependent.

Atleast according to my reading of the ARM as it stands today...
Newsgroups: comp.std.c++
From: spuler@coral.cs.jcu.edu.au (David Spuler)
Subject: exceptions, unexpected() and muddle_on()
Organization: James Cook University
Date: 14 Dec 92 20:06:44 GMT


On page 320, Stroustrup, 2nd edition, declares the function

void muddle_on() { cerr << "muddling on\n";  }

and installs it so as to be called by unexpected().

My question is: what happens if a function installed by set_unexpected returns?
Stroustrup says

"This will cause a normal return from a function detecting an unexpected
exception. .... "

I don't see how this can happen. 
Does the throw expression return and execution continue from there??
(Seems not since this could be way down deep in the stack.)
Or does the function which raised the unexpected exception just return with a
garbage return value?

The ARM seems to have nothing to say about set_unexpected functions returning.

Any insight appreciated,
David Spuler
Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Pointer comparisons
Organization: TauMetric Corporation
Date: Fri, 18 Dec 1992 18:10:29 GMT

sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:

>In article <BzDs2x.wA@frumious.uucp> uunet.ca!frumious!pat writes:
>>
>>   Two pointers to the same object compare equal.  If two pointers

>...but nowhere do I see a statement that (p == q) ==> p and q point
>to the same object, even if p and q are the same type.

Right.  In the C Standard, it is stated explicitly that two pointers
of the same type which compare equal point to the same object or
function.  There is no such statment for C++ in the ARM or in the
current C++ Committee working draft.

I believe this issue needs to be resolved.  (Obviously, we need
to exclude pointer-to-member from such a requirement.)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.std.c++
From: dag@bellman.control.lth.se (Dag Bruck)
Subject: Re: Pointer comparisons and templates
Organization: Department of Automatic Control, Lund, Sweden
Date: Tue, 15 Dec 1992 22:29:52 GMT

In <comp.std.c++> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>	You could always write the progam in terms of cmp(T,T),
>not <. The it would work for pointers too, you would just
>have to define cmp(T,T) for each type, including pointers,

I think that would be a serious effort, considering how many different
types of pointers you have in an application.

>	template<class T> int cmp(T a1, T a2){return a1<a2;}
>	int cmp(void* a1, void* a2){return ptrcmp(a1,a2)<0;}

I don't think this one flies.  For example,

	int* p;
	int* q;
	cmp(p, q);

probably causes a template overloading ambiguity.  You have to
explicitly define a cmp() for every type of pointer you have, I think.

>	The real problem cannot be solved at all, namely, for
>a user define < or cmp, ensuring it is a total order.

That is true, of course, for many applications.

I would also like to point out a few errors in the code for class Tree
in an earlier posting.  The specializations for void* in a few places
says "const void*&" which should be "void* const&".  Another error is
that Insert() returns a T&, which should be a const T&.

The first error I made, and the fact that nobody found it, is a strong
indication that specialization of templates is a real complication.


				-- Dag
Newsgroups: comp.std.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: Zero-length structures and pointer comparisons
Date: Wed, 16 Dec 1992 08:42:55 GMT
Organization: None

dag@seldon.control.lth.se (Dag Bruck) writes:
| Suggested semantics: for any pointers p and q:
|
|       p == q   <=>   ptrcmp(p,q) == 0
|
|       p != q   <=>   ptrcmp(p,q) != 0
|
|       ptrcmp(p,q) < 0   <=>   ptrcmp(q,p) > 0


And transitivity:

   ptrcmp(p,q) <= 0 && ptrcmp(q,r) <= 0   =>   ptrcmp(p,r) <= 0
   ptrcmp(p,q) <= 0 && ptrcmp(q,r) <  0   =>   ptrcmp(p,r) <  0
   ptrcmp(p,q) <  0 && ptrcmp(q,r) <= 0   =>   ptrcmp(p,r) <  0


jss@lucid.com (Jerry Schwarz) writes:
|And
|
|       if p < q is defined,  ptrcmp(p,q) < 0   <=>  p < q


This strikes me as nice to have, but not essential.
Many applications of ptrcmp wouldn't need this property at all
(eg. using ptrcmp to navigate through a binary tree, with no
additional requirement on the ordering other than that it be
an ordering).

On the other hand, this might be fairly cheap, given that
we're already insisting on

   p == q   =>   ptrcmp(p,q) == 0

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Date: 11 Dec 92 23:05:34 GMT
Organization: Microsoft Corporation

In article <1992Dec10.121935.19315@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|	The answer to this particular question is YES, they must
|compare equal according to the ARM. And I think this is a problem
|for OS design for the 386, for example, where the memory management
|kernel will just have to ignore the ARM.

No more nor less than any other virtual memory OS that allows
multiply mapped pages.  Since there is no functionality in the
language requiring such multiply mapped pages, you only get in
this situation by invoking some system dependency, in which case
you are making use of implementation dependencies.  If you will,
a common C/C++ implementation defined extension to the language
is to allow the use of OS calls in order to map various regions
of memory to the same underlying page, allowing the same object
to be accessed via differing addresses.  Implementation defined,
no more nor less.

Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Zero-length structures and pointer comparisons
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 18 Dec 1992 19:07:55 GMT

In article <BzG1Jx.JH@frumious.uucp> uunet.ca!frumious!pat writes:
>|
>|> So the question is really whether the requirement that pointers to
>|> the same object compare equal should be left implementation defined.
>
>Here I would disagree.  I think the question is whether, if the C++
>standard adopts the same notions of conformity as the C standard,
>pointers to the same object should be required to compare equal
>in a conforming program.
>
>And the answer is _no_.  

	Well, either way, this is not what the ARM says.
I would expect that pointers should compare equal after assignment
or initialisation (assuming they're the same type). And other
operations we could list.

	However, if raw pointers were supplied by an external source
such as the OS, I would prefer the answer be 'implementation defined'.
I dont know if this is workable, but the current status seems overly
restrictive.
-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Date: 11 Dec 92 23:37:48 GMT
Organization: Microsoft Corporation

In article <KANZE.92Dec10174617@slsvdnt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
|	int	cmp = memcmp( &ptr1 , &ptr2 , sizeof( void* ) ) ;
|
|This works on all implementations I can think of.  Is it guaranteed?

Also, Cray uses very different pointer implementations for char* verses
other types of pointers, since the natural address granularity on the Cray
is too large to make a good char*.  Thus sizeof(char*) != sizeof(int*) 
for example. [I don't know what sizeof(void*) would compare to -- char*
or int*]

Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Pointer comparisons and templates
Date: 16 Dec 92 20:20:54 GMT
Organization: Microsoft Corporation

In article <1992Dec15.164854.13070@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|	I'm not sure we've all agreed on the relationship, if any,
|between < and ptrcmp, but I think we agree that
|
|	"there will be a library function ptrcmp(void*,void*)
|	which defines a total order"
|
|unless you can convince us the < is worth more  than
|making assumptions about all future machine architectures.

This is silly.  "We all agree unless you prove otherwise" ????

Agreement is agreement.  If people agree, then they agree.  If
they don't agree, they don't agree.  No proof is involved.  Standards
arise around areas of general agreement.  Things that people can't
or won't agree upon don't get standardized.  Frequently compromise
is involved in reaching agreement, such that people at both extremes
of some position give up something in order to reach a statement that
all can agree to.


I suggest that OODBMS writers need to be consulted on this matter,
since in practice I think they are the most likely to be heavily
affected.

Again, you do not improve portability by making conforming C++
implementations unavailable on some systems.  You do not improve
portability by insisting on functionality that cannot be efficiently
implemented on some systems.  You get portabilitiy by writing
your code in a manner that can be affordably implemented on all
systems that you are interested in porting to.

I believe OODBMSs, lisp machine, OOArchitectures, etc, should be
systems we are interested in porting C++ code to.
From: chou@riscee.pko.dec.com (Jesse Chou WSG/SECG)
Newsgroups: comp.std.c++
Subject: need help compiling (linking) Borland C++ programs using templates
Date: 17 Dec 92 23:14:11 GMT
Organization: Digital Equipment Corporation, Maynard MA


This may be a very basic and silly question to ask but I am new to Borland
c++.  It is greatly appreciated that someone could enlighten me or give me
pointer to a FAQ.


I am writing a list class using template and got link error:

Error: Undefined symbol slist_base::append(slink near*) in module tpc.cpp


I had a similar error using other c++ compiler and found that I have to use
a command line switch with the compiler.  I suppose that someone could
easily point to me what I should do in my makefile.  Or maybe there is
other problems that I am not aware of.  In any rate, thanks in advance.



Jesse



-- 
Jesse Chou	-- chou@riscee.enet.dec.com

These words are entered into net by the keyboard.
I am not responsible for them; neither is my employer.


-- 
Jesse Chou	-- chou@riscee.enet.dec.com

These words are entered into net by the keyboard.
I am not responsible for them; neither is my employer.
Newsgroups: comp.std.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Ambiguity in member pointer declaration
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Tue, 15 Dec 92 01:13:59 GMT

|> 
|> Assuming X, Y and Z are class names, how should
|> 
|> 	X::Y::Z::*foo;
|> 
|> be interpreted?
|> 
|> 1. foo is a pointer to member of class ::Y::Z of type X.
|>    ('X' is a decl-specifier and '::Y::Z::*foo' is a declarator)
|> 
|> 2. foo is a pointer to member of class ::Z of type X::Y.
|>    ('X::Y' is a decl-specifier and '::Z::*foo' is a declarator)
|> 
|> 3. X::Y::Z is a decl-specifier and ::*mptr is an error.
|> 

The is a simpler potential ambiguity lurking in the use of "::" in declarations.

	X::f() { ... } 

Is the a declaration of "X::f" (implicitly returning int), or of "::f"
(returning X).  To avoid this ambiguity there is a rule that a declarator
may not begin with "::".  Actually there isn't a rule per se. The grammar
doesn't contain any rules that derive a declarator starting with "::".
And that omission is deliberate.

So answer to the question is that non of the above interpretations
is possible.  X::Y::Z::*foo, is a declartor and since no explicit
typespec is present int is assumed.  This means that you declaring
"foo" as a pointer to int member of X::Y::Z.  

    -- Jerry Schwarz.  



Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Pointer comparisons and templates
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 17 Dec 1992 21:41:38 GMT

In article <1992Dec15.222952.17059@lth.se> dag@bellman.control.lth.se (Dag Bruck) writes:
>
>The first error I made, and the fact that nobody found it, is a strong
>indication that specialization of templates is a real complication.
>

	Partly because the type system is not so hot either.
When you instantiate a template

	int i;
	f(i);

what get generated? f(int)? f(const int)? f(int&)? f(const int&)?
(and 4 more cases involving volatile)

IMHO all 8 of these functions should be considered redefintions:

	f(int);
	f(int&); // error, redefinition
	f( .. ) // as above for all the 6 other cases


-- 
;----------------------------------------------------------------------
        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: steve@taumet.com (Steve Clamage)
Subject: Re: "long long" and C++
Organization: TauMetric Corporation
Date: Tue, 15 Dec 1992 18:22:28 GMT

gjb@fig.citib.com (Greg Brail) writes:

>The most recent Sun ANSI C compiler (Sparc Works 2.0.1) supports a 64-bit
>integer type called "long long". Since this type is only available with
>the compiler in "strict ANSI" mode, I suppose it is part of the proposed
>ANSI C standard. Is this true?

There is an official ANSI C Standard, and has been since 1989.

The locution "long long" violates a constraint in section 3.5.2 of the
ANSI Standard, and must be diagnosed as an error by a conforming
implementation.  If the "long long" extension is available only in
"strict ANSI" mode, they got it backwards.  I would expect such an
extension to be available only when "strict" mode is disabled.

>But more importantly, are there any existing proposals to add "long long"
>to the C++ standard? Such a data type would be quite useful. Are there
>any existing C++ compilers that support, or plan to support this type?

The next C standard will probably support an integer type longer than
type long.  The C++ Committee has no proposals that I know of for
adding such a type.  When it is added to C, it will certainly be
added to C++.  If the ANSI C numerical extensions group decides on a
longer integer type and it looks likely to be included in C, I would
expect the C++ Committee to adopt it.  It is thus possible that C++
will have it officially before C, if only due to timing.

Whether the longer type will be called "long long" or something else is
anyone's guess.

In the mean time, a number of compilers support this type, such as
Sun C, as you noted.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Pointer comparisons and templates
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 15 Dec 1992 08:50:09 GMT

dag@bellman.control.lth.se (Dag Bruck) writes:

>In the recent discussion on pointer comparisons, Fergus Hendersson
>suggested adding a standard library function ptrcmp() instead of
>extending the definitions of "<" and ">" for pointers.  I think we
>also agreed on a reasonable relationship between ptrcmp() and the
>relational operators.
>
>While I think ptrcmp() is better than nothing, I still think extending
>the definition of the relational operators is far better.
[...]
>3.  The programmer using class Tree must remember to use a different
>class for pointers.  There is no type checking that prevents the user
>from using Tree<Foo*> -- it will compile fine but produce the wrong
>results on some machines.
[...]
>I regard (3) is biggest problem, in particular as there is no way (as
>far as I know) to diagnose the problem.   It may work fine on some
>machines, and then break when you port the code to a new machine or a
>new memory model on the same machine.

The problem is that there are two different sorts of "ordering" operations
that are useful in different circumstances. The first is comparing
pointers to objects in the same array, the second is comparing arbitrary
pointers. On some architectures, the former is much faster than the latter.

Extending the definition of the relational operators would make many programs
considerably less efficient, break some conformant but not strictly conformant
programs, and would create more problems than it would solve, IMHO.

Although ptrcmp() is not a perfect solution as far as template data-structures
go, the alternative would also have difficulties -- what if I want a Tree
of pointers all of which _are_ in the same array, and efficiency is
very important? In that case, Tree<Foo*> is exactly what I want.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.std.c++
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: Zero-length structures and pointer comparisons
Organization: Liant Software Corporation
Date: Thu, 17 Dec 1992 15:09:14 GMT

In article <1992Dec15.162202.11231@ucc.su.OZ.AU> John (Max) Skaller writes:
> In article <1992Dec11.230534.10499@microsoft.com> Jim Adcock writes:
> >No more nor less than any other virtual memory OS that allows
> >multiply mapped pages.  Since there is no functionality in the
> >language requiring such multiply mapped pages, you only get in
> >this situation by invoking some system dependency, in which case
> >you are making use of implementation dependencies.

> But Jim, it is not implementation defined, it is required that 
> pointers to the same object compare equal.

> It is therefore not
> allowed to do this sort of memory mapping in C++ behind the scenes,
> which is what I'm concerned with...we actually want to.

It makes me uneasy, but I think Jim Adcock is correct: an implementation
can define an extension, such as memory mapping, which overrides the usual
execution time rules of C/C++, including the rule that pointers to the same
object compare equal.  The rule that 1+1==2 would likewise be subject to
"extension".

Nevertheless, the C standard implies that the onus is on the invoker of memory 
mapping to be aware of libraries and other code which may rely on the usual
execution time rules of C/C++, such as the rule that pointers to the same
object compare equal.  If we don't want libraries to make that assumption,
then John (Max) Skaller is also correct to say

> So the question is really whether the requirement that pointers to
> the same object compare equal should be left implementation defined.
--
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
Newsgroups: comp.std.c++