HDTenEightyP/NetNews huggingface dataset:
From: brennan@hal.com (Dave Brennan)
Newsgroups: comp.std.c++
Subject: Re: Which delete operator should be called?
Date: 3 Sep 92 15:53:03 GMT
Organization: HaL Computer Systems, Austin, TX
NNTP-Posting-Host: yosemite.hal.com
In-reply-to: brennan@hal.com's message of 03 Sep 92 07:08:54 GMT

I didn't have my copy of ARM handy when I posted, and I see that it also
says is 12.4 (p. 278) "When invoked by the delete operator, memory is freed
by the destructor for the most derived class of the object using an
operator delete ()."

What it doesn't say is which operator delete.  This tends to imply that the
operator delete of the most derived class should be used, but as my
previous post showed it is only used when the class being deleted has a
virtual destructor.  This quote implies that the operator delete of the
most derived class will be called when any object is deleted?

Cany anyone clarify this?

--
Dave Brennan                                      HaL Computer Systems
brennan@hal.com                                         (512) 794-2855

Visit the Emacs Lisp Archive: archive.cis.ohio-state.edu:pub/gnu/emacs
From: brennan@hal.com (Dave Brennan)
Newsgroups: comp.std.c++
Subject: Which delete operator should be called?
Date: 3 Sep 92 07:08:54 GMT
Organization: HaL Computer Systems, Austin, TX
NNTP-Posting-Host: yosemite.hal.com

It's not clear to me which delete operator should be called in the
following example program.  The ARM says that the delete operator is
inherited, but is not virtual (which certainly makes since, because it
must be static).

All compilers that I testest this on indicated that the derived delete
operator is called when the destructor is virtual.  If the destructor is
non-virtual the base class delete operator is called.  So at least in some
compilers the delete operator IS virtual if the destructor is.  This may be
reasonable behavior but seems contrary to what the ARM says.

Somewhat related to this, I need to be able to call the virtual destructor
of an object without deleting it.  I can't get any compilers to accept any
destructor calling syntax other than "class::~class()" (where "class" is a
class name).  In cfront this syntax DOES call the virtual destructor (ie:
if I call "base::~base()" from a base method, the derived destructor is
called).  Lucid CC it only called the base class destructor, which seems
like the correct behavior.  g++ 2.2.2 wouldn't accept any kind of explicit
calls to a destructor.  Can anyone tell me how to call a virtual destructor
in a way that least cfront 2.1 will accept and is correct C++?

extern "C" void puts (char *);

class base
{
public:
  virtual ~base ()
    { puts ("destruct base"); }
  void operator delete (void *)
    { puts ("delete base"); }
  void destruct ()
    { base::~base (); }
};

class derived : public base
{
public:
  ~derived ()
    { puts ("destruct derived"); }
  void operator delete (void *)
    { puts ("delete derived"); }
};

int
main ()
{
  base *b = new derived;

  delete b;
}
--
Dave Brennan                                      HaL Computer Systems
brennan@hal.com                                         (512) 794-2855

Visit the Emacs Lisp Archive: archive.cis.ohio-state.edu:pub/gnu/emacs
From: JORTIZ@vmtecqro.qro.itesm.mx (Jose Luis Ivan Ortiz Lopez)
Newsgroups: comp.std.c++
Subject: drawing a point without using BIOS......
Date: 2 Sep 92 01:59:54 GMT
Organization: Instituto Tecnologico de Monterrey, Campus Queretaro

Hey, I need ideas ASAP about drawing a point without using BIOS
for a IBM PS/2 55 SX with a 386, using TC ++ 2.0.. You may replay me
to my account if you like...
Thanks in advance.
Ivan Ortiz
jortiz@vmtecqro.qro.itesm.mx
From: pabloh@hpwala.wal.hp.com (Pablo Halpern )
Date: Wed, 26 Aug 1992 18:25:08 GMT
Subject: Re: Expanding enumerators in inheriting classes
Organization: Hewlett-Packard Company
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: What does "::" really mean?
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Fri, 4 Sep 92 00:14:05 GMT


Basically, operator:: does not mean to qualify an identifier. It only 
suggests the path to search for the identifier. For example, in expression:

   anObject.aClass::aMember

anObject is the qualifier, and aClass suggests that aMember is defined in  
aClass or in one of its bases.

A nested class should be a property of its enclosed class, not the property 
of its object, therefore we should use expression

   aEnclosingClass.aNestedClass

to access the nested class. Mircosoft C/C++7.0 choses to use

   aEnclosingClass::aNestedClass

This brings ambiguity. If I have an expression:

   C1::C2::C3:: ... ::X

what is the relationship of Ci and Ci-1? The base-derive relationship or 
the enclosing-nested relationship? How about when the nested class happened 
to be the same name of one of the base classes of its enclosing class?  
(consider the fact that the name of a class member can be the same name of 
its class or the base class.)

Its rather controversial to argue whether we should use "." or "::" to 
access a static member. It depends whether the static member is belong 
to the property of the class or the property of the object. To makes 
things clear, I would rather to treat static member as the property of 
the class, so we should use "." to accress a static member.

If we want to access the class property through an object, we should use

    typeof(anObject).aClassProperty

David Shang
From: glenn@ready.com (Glenn Kasten)
Newsgroups: comp.std.c
Subject: <limits.h> and MB_LEN_MAX
Date: 27 Aug 92 16:50:44 GMT
Reply-To: glenn@ready.com (Glenn Kasten)
Organization: Ready Systems


I apologize in advance if this a FAQ, but I'm new to the group and
haven't seen this question asked yet nor seen the FAQ location.

<limits.h> is supposed to define MB_LEN_MAX.  Is it permissible for a
conforming implementation to define MB_LEN_MAX in terms of another
type, where that other type is not declared in <limits.h>?  In other
words, do header files have to be complete in themselves, or can they
require other header files to also be included, in order to be
usable?

A colleague and I are disagreeing over this and so I wanted to request
an outside opinion.

Thanks,
Glenn
-- 
-- 
Glenn Kasten
Ready Systems 470 Potrero Ave. Sunnyvale CA 94086 
glenn@ready.com (408) 522-7357
From: sprave@gonzo.informatik.uni-dortmund.de (Joachim Sprave)
Newsgroups: comp.std.c
Subject: int const * p;
Date: 1 Sep 1992 15:12:08 GMT
Organization: CS Department, Dortmund University, Germany
Distribution: world
NNTP-Posting-Host: gonzo

Could anybody look in the standard, if

	int const * p;

is allowed ?

GCC treats it as 

	const int * p;

SUN's acc gives an error.

         //////\\
        /        \
       _|  _   _ |_
      |.|-(.)-(.)+.|
       \|    J   |/
        \   ---  /
         \      /
          "####"
		Joachim
From: linden@positive.Eng.Sun.COM (Peter van der Linden)
Newsgroups: comp.std.c
Subject: Re: int const * p;
Date: 2 Sep 92 17:34:15 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: positive

John omitted only the reference to the manual, namely 
section 3.5.3 "Type Qualifiers".   It's not clear why a
meaningful construct, like a constant pointer to a constant value
is precluded.  

However Joachim, I believe your appearance, if not your const problems,
could be improved by parting your hair on the other side, switching to 
contact lenses and smiling.  You would then look like this:

         //\\\\\\ 
        /        \
       _|  _   _ |_
      |.|  o   o | }
       \|    \   |/
        \   \ /  /
         \   ~  /
          "####"
                Joachim V2.0

--
linden@eng.sun.com|| P. van der Linden and his uncustomary theories.
Go Giants!! Don't || When solving a "panic" you must first ask yourself what you
stop at Florida...|| were doing that could possibly frighten an operating system
From: diamond@jit081.enet.dec.com (01-Sep-1992 1245)
Newsgroups: comp.std.c
Subject: Re: ANSI description for signal handling
Date: 1 Sep 92 03:45:58 GMT

In article <9208311827.AA10025@ucbvax.Berkeley.EDU> JENNIFER@TOROLAB6.VNET.IBM.COM ("Jennifer Hamilton") writes:
>( ... also posted to comp.lang.c)

In order to do that, you should edit the "Newsgroups:" line in the header
to say "Newsgroups: comp.std.c,comp.lang.c" instead of posting two
separate articles.

>In the ANSI standard under the description of the signal function,
>(section 4.7.1.1) it states the following:
>   "The function func may terminate by executing a return statement or
>   by calling the abort, exit, or longjmp functions.  If func executes a
>   return statement and the value of sig was SIGFPE or any other
>   implementation-defined value corresponding to a computational
>   exception, the behaviour is undefined.  Otherwise, the program will
>   resume execution at the point it was interrupted.  If the signal
>   occurs other than as the result of calling the abort or raise
>   function, the behaviour is undefined if the signal handler calls any
>   function in the standard library other than the signal function
>   itself ..."
>The last sentence implies that you can't call any library functions
>(such as longjmp, abort or exit) from within the signal handler unless
>the signal was explicitly raised through raise or abort.

That is correct.  (However, even when the standard explicitly leaves the
behavior undefined, an implementation is still allowed to define an
extension if it wishes, and a non-strictly conforming program is allowed
to take advantage of the extension, though it won't be portable.)

>But the first three sentences imply that you can.

Well, yes and no.  It does seem worded to raise false hopes before quashing
them.  However, it doesn't exactly say that func may call abort, exit, or
longjmp under all circumstances.  The only "standard" circumstance under
which a signal may be received is due to calling abort or raise, and under
this circumstance, there are four defined methods of exiting.  If a signal
is received due to implementation extensions, then the standard says that
the implementation still has to allow an ordinary return statement, but
doesn't have to allow other means of exit from the handler.

Now, one might wonder if SIGPFE, SIGILL, SIGINT, SIGSEGV, or SIGTERM might
also be "standard" circumstances for signals to be received.  Well, the
standard says "An implementation need not generate any of these signals,
except as a result of explicit calls to the raise function."  So even though
these macros exist, they do not have "standard" defined meanings.
--
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: jes@grendel.demon.co.uk (Jim Segrave)
Distribution: world
Subject: How is struct assignment defined (idle query)?
X-Mailer: cppnews $Revision: 1.14 $
Organization: None
Date: Thu, 3 Sep 1992 12:13:26 +0000


I don't have access to a copy of the ANSI spec, hence my query:

Does ANSI say that structure assignment is done by member-wise copy or
by bit-wise copying?
The reason I ask is that if it is a bit-wise copy, then any padding in
a struct would have to have some (presumably inplementation defined)
value written to it so that the padding bytes could be copied.
I realise that most implementations will not suffer any ill effects
from the notional conversion of the following assignment:

struct a {...} a_one = { ...};
int some_func ()
{
  struct a a_two = a_one;


to:
  memcpy ((void *) &a_two, (void *) &a_one, sizeof (struct a));

but I wondered if this conveys the actual ANSI definition of struct
assignment.


--
Jim Segrave
From: JENNIFER@TOROLAB6.VNET.IBM.COM ("Jennifer Hamilton")
Newsgroups: comp.std.c
Subject: ANSI description for signal handling
Date: 31 Aug 92 18:25:43 GMT

( ... also posted to comp.lang.c)

In the ANSI standard under the description of the signal function,
(section 4.7.1.1) it states the following:

   "The function func may terminate by executing a return statement or
   by calling the abort, exit, or longjmp functions.  If func executes a
   return statement and the value of sig was SIGFPE or any other
   implementation-defined value corresponding to a computational
   exception, the behaviour is undefined.  Otherwise, the program will
   resume execution at the point it was interrupted.  If the signal
   occurs other than as the result of calling the abort or raise
   function, the behaviour is undefined if the signal handler calls any
   function in the standard library other than the signal function
   itself ..."

The last sentence implies that you can't call any library functions
(such as longjmp, abort or exit) from within the signal handler unless
the signal was explicitly raised through raise or abort.  But the first
three sentences imply that you can.  Can anyone explain this apparent
contradiction?

Jennifer Hamilton
IBM Toronto Lab
jennifer@torolab6.vnet.ibm.com
From: laribi@uapu.imag.fr (Youcef Laribi)
Newsgroups: comp.std.c
Subject: FAQ for this group
Date: 26 Aug 92 09:49:06 GMT
Reply-To: laribi@uapu.imag.fr (Youcef Laribi)
Organization: IMAG



I am a new reader of this newsgroup and i wonder if there are  any FAQ's. If yes, where can i find them. Thanks.

youcef.
--
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.std.c
Subject: Re: int const * p;
Date: 2 Sep 92 12:02:53 EDT

sprave@gonzo.informatik.uni-dortmund.de (Joachim Sprave) writes:
>I apologize to SUN, Jutta you're right. The fact is, in my test
>program I jumped to the wrong line. So
>	       int const * p;
>is accepted by acc and gcc. The error message occured in the line
>		const int const *q;
>which IMO is incorrect, or at least useless.

"Constraints
   The same type qualifier shall not appear more than once in the same
specifier list or qualifier list, either directly or via one or more
typedefs."

Your opinion is fact, it is incorrect.
From: bharat@ccvax.ucd.ie
Newsgroups: comp.std.c
Subject: compare socket based and RPC based...
Date: 25 Aug 92 14:00:38 GMT
Organization: University College Dublin

Hi Net Gurus,
 
could any one tell me the advantages of "Socket Based interprocess
communication" over "Remote Procedure Call based interprocess communication"?

My application program runs on the top of the packet layer. It communicates 
with a X.25 switch. The communication between switch and application programm
is based on 'BSD Socket based communication'.

I summarize it in the following steps- 

1. I open a socket in X.25 domain (i am using SunNet X.25 software).

2. Pass the address of remote switch to the socket.

3. send some data (e.g. 'stat' command for the switch which gives all the 
statstical information from the switch). 

4. receive the output (e.g. output of 'stat' command which is parameter values 
from the switch).

             ----------------------------------------------------------

My questions are: 

1.why and when the socket based communication is used?

2.Why always RPC based communication is prefered over socket based 
communication is prefered?

3. Is it possible to implement a 'Client-Server' model using  sockets? if yes,
can i call 'My-application-program=X.25-switch' (as given in steps 1-4) as
a 'cleint=server' model?


Any pointers/hints..? Thanks very much for reading this. I will welcome any
concern information.

Please ..send your answers by email to me.

- Bharat

(bharat@ccvax.ucd.ie)
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: int const * p;
Date: 1 Sep 92 19:35:29 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

In article <180188INNmtc@fbi-news.Informatik.Uni-Dortmund.DE> sprave@gonzo.informatik.uni-dortmund.de (Joachim Sprave) writes:
>Could anybody look in the standard, if   int const * p;   is allowed?
>SUN's acc gives an error.

Yes, it is legal.  A compiler that rejects it is not Standard-conforming.
Newsgroups: comp.std.c
From: karl@ima.isc.com (Karl Heuer)
Subject: Re: Small Language Wanted
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Tue, 01 Sep 1992 19:52:32 GMT

[I have removed comp.lang.fortran from the newsgroup list]

In article <1992Sep1.130600.25488@siia.mv.com> drd@siia.mv.com (David Dick) writes:
>In article <9224317.28165@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>Note that it makes sense to prevent users from redefining standard
>>library functions, because doing so could have all sorts of undesireable
>>side-effects.  [Example deleted]
>
>The fact that programmers who know what they're doing could no longer
>replace pieces of the libraries for debugging or *performance* reasons,
>was apparently of no consequence.
>
>IMHO, the "safety" provided by this reservation is far outweighed by
>the crippling of standard programming practice.

The Standardization of C had absolutely no effect on this aspect of the
language.

In Classic C, if you override a library function by a user-written function
of the same name, you get the expected results if you're "lucky", or if you
know enough about the implementation details to understand that it's safe.
The resulting program is not portable to an environment where the
implementation details are different.

In ANSI C, if you override a library function by a user-written function of
the same name, you have violated a constraint; hence you get the expected
results if you're "lucky", or if you know enough about the implementation
details to understand that it's safe.  The resulting program is not portable
to an environment where the implementation details are different.

The difference is that ANSI C explicitly documented something where Classic C
programmers had to rely on common sense.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
From: diamond@jit081.enet.dec.com (03-Sep-1992 1314)
Newsgroups: comp.std.c
Subject: Re: declaration of main
Date: 3 Sep 92 04:15:42 GMT

In article <spuler.715480577@coral.cs.jcu.edu.au> spuler@coral.cs.jcu.edu.au (David Spuler) writes:
>5.1.2.2.1 "Program startup" [...] main can be declared as:
>  int main(void) { ... }
>  int main(int argc, char *argv[]) { ... }
>Are the following also legal, although not explicitly mentioned?
>  int main()  { /* non-proto declaration */ }

That one automatically gets a prototype of int main(void).  No problem.

>  main()  { /* non-proto declaration */ }

The default return type for C functions has been int since 1970, and was not
changed by the standard.  It gets the same prototype as above.  No problem.

>  main(void) { /* implicit int */ ... }

The default return type hasn't changed during the last three seconds  :-)

>  int main(int argc, char **argv) { /* char **argv;  not char *argv[] ... }

In int main(int argc, char *argv[]), the type of the second parameter is
automatically adjusted (by the standard) to yield exactly what you have
typed here.  I think you're allowed to save that step  :-)
--
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."
From: diamond@jit081.enet.dec.com (02-Sep-1992 0949)
Newsgroups: comp.std.c
Subject: Re: int const * p;
Date: 2 Sep 92 00:50:05 GMT

In article <180188INNmtc@fbi-news.Informatik.Uni-Dortmund.DE> sprave@gonzo.informatik.uni-dortmund.de (Joachim Sprave) writes:
>Could anybody look in the standard, if    int const * p;   is allowed ?

Yes, it would be very easy for you to look that up :-)
(Some parts of the standard are obscure, but not this one.)

>GCC treats it as   const int * p;

That is correct.

>[Other compiler] gives an error.

If the vendor claims that that compiler is ANSI or ISO conforming, and if
you paid money for it, then get a refund.  [Personal opinion only.]
--
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: spuler@coral.cs.jcu.edu.au (David Spuler)
Subject: declaration of main
Organization: James Cook University
Date:  3 Sep 92 00:36:17 GMT


A discussion of declaring main as returning void in comp.lang.c lead me
to read 5.1.2.2.1 "Program startup" in my ISO standard.  According to this
section, main can be declared as:

int main(void) { ... }
int main(int argc, char *argv[]) { ... }

Are the following also legal, although not explicitly mentioned?

int main()  { /* non-proto declaration */ }
main()  { /* non-proto declaration */ }
main(void) { /* implicit int */ ... }
int main(int argc, char **argv) { /* char **argv;  not char *argv[] ... }

Yes, I realize this sounds like a dumb question, but the standard doesn't
seem very precise. It implies that only the first 2 are legal.

Regards,
David Spuler
--
David Spuler, James Cook University of North Queensland, Australia
Author of "Comprehensive C", Prentice-Hall, 1992, pp416, ISBN  0-13-156514-1
INTRO TOPICS: types, operators, structures, strings, fns, ptrs, files etc etc
ADVANCED TOPICS: efficiency, debugging, style, portability, large programs
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.std.c
Subject: Re: space optimization involving enum
Date: 25 Aug 92 18:55:31 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Aug25.153909.17977@email.tuwien.ac.at> hp@vmars.tuwien.ac.at (Peter Holzer) writes:
>When the callee is compiled, the compiler cannot know if there is a
>prototype in scope of the caller.

Actually, doesn't the standard require that function
declarations/prototypes and definitions be consistent with each other?  If
the function is defined with an ANSI parameter list, the caller must have a
prototype in scope.  If the function is defined with a K&R1 parameter list,
the caller can use an old-style declaration (or no declaration at all,
letting it default, if the function returns int).

In particular, with K&R declarations, chars are always widened to ints when
calling a function, while with ANSI prototypes they're passed as chars.
This is very similar to the enum conversion that you were talking about.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.std.c
From: usgtemx@gsusgi2.gsu.edu (Tracy Monteith)
Subject: Retrieving database information using C and the Paradox Engine
Keywords: Paradox and C
Organization: Georgia State University
Date: Tue, 25 Aug 1992 18:05:11 GMT

I am looking for some type of function or functions that will allow
me to retrieve specific columns in a database without knowing there
location. The problem is that our database structure changes constantly
and I don't want to change my program everytime someone wants to add a 
field.

Thanks in advance.

Newsgroups: comp.std.c
From: dat@thinkage.on.ca (David Adrien Tanguay)
Subject: struct hack, was Re: strcpy implementation question
Organization: Thinkage, Ltd.
Date: Fri, 4 Sep 1992 01:53:35 GMT

diamond@jit081.enet.dec.com (03-Sep-1992 1325) writes:
>In article <PINKAS.92Sep2173635@skywalker.intel.com> pinkas@skywalker.intel.com (Israel Pinkas) writes:
>>The variable length struct is a hack.  There is nothing in the language
>>that prevents the compiler from performing bounds checking on accesses to
>>name.
>
>Uh, nothing except the standard's definitions of [], unary *, and binary +
>operators.  :-R rhetoric.
>Bounds checking is not allowed to affect output of a valid but ugly program.

Could you flesh this argument out? I had the impression that the last time
it came up here the conclusion was that this trick was not sanctioned
(i.e., a bounds checker could fail). After all, 3.3.6 "Additive Operators"
says that you aren't guaranteed to go past the end of an array object,
so if you start with the trailing array (in the struct) you can't go past
its end. (You could if you used a different "handle" for the malloc return
value.)
-- 
David Tanguay       dat@Thinkage.on.ca  dat@Thinkage.com  uunet!thinkage!dat
Thinkage, Ltd.           Kitchener, Ontario, Canada          [43.40N 80.47W]
Newsgroups: comp.std.c