HDTenEightyP/NetNews huggingface dataset:
From: pjl@cs.uiuc.edu (Paul Lucas)
Subject: Re: Equivalent of realloc().
Organization: University of Illinois at Urbana-Champaign
Date: Wed, 27 Jan 1993 15:48:03 GMT

In <CICCI.93Jan26135919@hpcnnn.cern.ch> cicci@hpcnnn.cern.ch (Claudio Condini) writes:

>I am implementing a class (in fact, a template) Vector which contains a member
>function resize(int).  This should really be implemented with a realloc(). 
>Any constructor for the Element class of Vector should be called for all and
>only the new elements.  That is, if I have a vector with 20 elements of class
>X and resize it to 30, then the X::X() constructor should be called only for
>the 10 extra elements, and the original 20 elements should not be touched.  Is
>there a way to do this?  I have tried playing with operator new(size_t, void*)
>but did not get very far. 

	There's no equivalent to realloc().

	See: Tom Cargill, "A Dynamic Vector Is Harder Than It Looks,"
		C++ Report.  It was one of the issues during summer '92
		(I can't remember which).
-- 
	- Paul J. Lucas
	  AT&T Bell Laboratories
	  Naperville, IL
From: pkr@media03.UUCP (Peter Kriens)
Newsgroups: comp.lang.c++
Subject: Re: C++ develpment environments
Date: 21 Jan 93 09:26:15 GMT
Organization: Mediasystemen, Netherlands
X-Newsreader: Tin 1.1 PL4

>  Besides, CenterLine's prices are "average" when it comes to workstation development
>  environments (not to excuse those prices...in my opinion, neither CenterLine nor any
>  of the other development environments provide thousands of dollars more capability
>  when compared to a PC product such as Borland C++...until CenterLine releases the
>  new version of ObjectCenter, Borland C++, at $100, even provides something those
>  workstation environments don't: compiled headers...If anyone has any benchmarks, I'd
>  be interested in seeing how well Borland's compile/link cycle stacks up to workstation
>  products :-)

I dont think this is a problem of Centerline. It is a basic high end low end 
difference. It is a very funny effect that high end workstations cost
much more and offer much less functionality on the USER level. But dont forget
that there is a difference. The multiprocessing facilities (well supported
by centerline) and the capability to load 20 Mb object code is something ]
dramatically missing in the PC world.

Many times I have faced the dreadfull choice between the low cost
environment of the PC where the software contains the many user 
functionality but where you have to fight the memory mess, the config.sys
confusion, the crashes (control-alt-delete or Unrecoverable Application error). 
Almost no functionality in the OS, communications standards missing etc.

Or the workstation world which cost a lot more, but where size is
practically unlimited, many processes run at the same time, good
integrated communications and virtually crash free.

And dont forget that in many applications development tools prices
are not that important. A product
that is twice as expensive as another doesnt have to be twice as good. Notice
that the benefit of the product pays for it. If an expensive product costs
twice as much but is only 5% better, it could still give you the edge
if the thing you are doing is 10 times more expensive than the product.

And please note, some things which can be done relatively easy on Unix
can be prihibitevly complex on a PC.

This doesnt mean that I do not object to these prices. I would like them to lower
them, but believe me if you need them, they are worth the price.

	Peter Kriens
Xref: sparky comp.lang.c++:20052 comp.lang.c:20329
From: acctpu@vaxa.hofstra.edu
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Pointers to Functions
Date: 27 Jan 93 13:38:10 EST

	I was wondering.  If I define a pointer to a function

void (*fp)()

       How would I get the pointer to *point* to a function, and how would I
*execute* the function the pointer is pointing to.

Thanks in advance,

Gary Graffagnino
ACCGSG@VAXC.HOFSTRA.EDU
From: sundvall@perrier.embnet.se (Mats Sundvall)
Newsgroups: comp.lang.c++
Subject: Re: Maximum reusability, was: C++ ..tree Inheritance ..
Date: 21 Jan 1993 09:45:45 GMT
Organization: EMBNet Project Sweden
Distribution: world
Reply-To: sundvall@perrier.embnet.se
NNTP-Posting-Host: perrier.embnet.se


In article 1689@ucc.su.OZ.AU, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>It is best in modular design to MINIMISE inheritance. It is 
>in general not a good thing. Although it supports reusability,
>it does so with strong coupling (BAD) and without
>explicit interfaces (BAD).
>
>Huge single inheritance heirarchies are the worst kind.
>
>Try using mixins. Lots of small independent abstracts,
>some common syntheses of these abstractions,
>and some common implementations of these abstractions.
>
>Also supply routines operating on the abstractions.
>These will work what ever the implementation chosen
>is, whether it be from the library or supplied
>by the user.
>



I am not arguing about mixins but a problem I often encounter is when you need the
same functionality in most or all of your classes. One example would be object I/O
like in OODB's or if you want to stream objects to a file or across the net.


The methods you need will end up in the mixin Object or PersBase or whatever you
call it and voila, you have a huge tree.


Please prove that I am wrong, I don't like it either!


Mats Sundvall

Uppsala University
Sweden

Newsgroups: comp.lang.c++
From: pbender@qualcomm.com (Paul Bender)
Subject: Address of Member Functions
Followup-To: comp.lang.c++
Organization: QUALCOMM, Incorporated
Date: Mon, 25 Jan 1993 20:47:04 GMT

Is there a reason why this will not valid?

class X {
private:
  void g1(void);
  void (*g)(void);
public:
  X(void);
  void f(void);
};

void X::f(void)
{
  g = &g1;                // line 12
}

main(void)
{
  X x;
}

When I compile it using g++, I get the following error message:
test.C:14: assignment between incompatible pointer types

------------------------------------------------------------------------------
Paul E. Bender                 |  The opinions are my own and should not be
pbender@qualcomm.com           |  unfavorably attributed to anyone else.
------------------------------------------------------------------------------
From: bab@se39.wg2.waii.com (Brian Button)
Newsgroups: comp.lang.c++
Subject: Re: Is this C++ advice from an OO book true? (beginner question)
Date: 24 Jan 93 15:08:15 GMT
Organization: Western Geophysical Exploration Products
NNTP-Posting-Host: se39.wg2.waii.com
In-reply-to: dak@tabaqui.informatik.rwth-aachen.de's message of 24 Jan 93 10:11:42 GMT


-->"David" == David Kastrup <dak@tabaqui.informatik.rwth-aachen.de> writes:

sherman@unx.sas.com (Chris Sherman) writes:

>I don't understand one of the book's recommendations:

>  11.  Call virtual class constructors in dervied class constructors.

>     I pity the poor fools who have to spend nights and weekends
>     searching for the reason that a class variable occasionally
>     takes on strange, unexpected values .  .  .  only to find
>     through their bleary eyes that they forgot to allocate space for
>     a virtual base (super) class, so that storage is allocated for
>     the base class's members.  Even if the class has no members,
>     declare it--you never know what future changes will come back to
>     haunt you (or the person who inherits your mine field)!


>Or if this is very good advice, could someone give an example showing
>why it is true?

>This is a beginner question obviously--thanx for any help!

David> And the above book writes a beginner's answer. Constructors cannot be
David> virtual and I pity the poor fools who have to spend nights and weekends
David> only to find out that in C++ the type system is static, and so every
David> object's type is fixed from the beginning and types are managed by
David> the compiler. If the runtime had anything to do with the type system in
David> C++, maybe there would be such a thing as a virtual constructor.

I don' think the question was why to call a virtual constructor for a
base class, but why to call a constructor for a virtual base class.

These constructors need to be called to ensure that the data members
of any parent classes are properly initialized. For instance:

class VirtBase
{
  private:
    int     a;

  protected:
    int     myA( ) const            { return a; }
    int     myA( const int anA )    { return a = anA; }

  public:
    VirtBase( const int anA ) : a( anA ) { }
};

class DerivedClass : virtual public VirtBase
{
  public:
    DerivedClass( const int anA ) : VirtBase( anA ) { }
};

If VirtBase weren't initialized in the constructor for DerivedClass,
VirtBase::a would never be initialized. This is one reason why you
should always explicitly call the constructor for any base classes in
a derived classes constructor.

bab
--
|-----------------------|----------------------------------------------------|
| Brian Button          | email : button@wg2.waii.com                        |
| Design Engineer       |         71023.276@compuserve.com                   |
| Western Geophysical   | voice : (713)964-6221                              |
| 3600 Briarpark        |----------------------------------------------------|
| Houston, Texas  77042 | OS/2 - Used at only the BEST Pool Halls ;)         |
|-----------------------|----------------------------------------------------|
Newsgroups: comp.lang.c++
From: pete@arl.wustl.edu (Peter Flugstad,,,)
Subject: inline and varargs clash???
Reply-To: pete@arl.wustl.edu
Organization: Applied Research Lab, Washington University in St. Louis
Date: Thu, 28 Jan 1993 01:46:54 GMT

Hi, I'm trying to get the following code to compile on a Sun SPARC
(Sun OS 4.1.3, Sun C++ 3.0.1, SC 2.0.1, cfront version 3.0.1).

#include <stdio.h>
#include <stdarg.h>

#ifdef _ERR_DEBUG
inline void Debug_Sys_Print (char *format, ...)
{
  va_list args;
  va_start (args, format);
  vprintf (format, args);
  va_end (args);
}
#else  _ERR_DEBUG
inline void Debug_Sys_Print (char *format, ...)
{
}
#endif _ERR_DEBUG

main ()
{
  Debug_Sys_Print ("Hello, %s\n", "World");
  printf ("done...\n");
}

The idea is that I want Debug_Sys_Print to be completely compiled out if 
_ERR_DEBUG is not defined...  This is for performance reasons.  

(I know that wrapping an #ifdef-endif around the actual function call
also works to remove the call, but this is a lot cleaner and easier to read)

The problem I am having is that when I  compile this normally  with the
 _ERR_DEBUG defined I get a linker error:

pete> CC -D_ERR_DEFINE -o print print.C
ld: Undefined symbol 
   __builtin_va_alist 

But when I compile with a +d (do not expand inlines), it works fine:

pete> CC -D_ERR_DEFINE +d -o print print.C
pete> ./print
Hello, World
done...

This symbol "__builtin_va_alist" is from the <stdarg.h> file, here's the 
relavent portions of that file...

#ifdef sparc
#   define va_alist __builtin_va_alist
#endif
...
#ifdef sparc
extern char __builtin_va_alist;
#define va_start(ap, parmN) ap = (char *)( &__builtin_va_alist )
#else
...

I have looked at the command line passed to ld, (via the -V command)
and it's identical in both cases.  If I look at the code cfront generates, 
of course has the function inlined in the first, and not in the second. 
(Despite this I could never find a reference to "__builtin_va_alist"
in any of the libraries using nm).

I guess the puzzling thing about this is why is ld complaining???   The only
difference is that in one case Debug_Sys_Print is inline, and in the other,
it's not.  In both cases, __builtin_va_alist is defined as extern char (I 
looked at the code from cpp and cfront).

I realize that for my purposes, adding the +d to the compile still does what 
I want.  If ERR_DEFINE is not defined, (and also no +d) then the 
Debug_Sys_Print is empty,  and cfront realizes that the inline function
has no code, and so generates no code for it.  

I just guess it is a puzzle???

Please e-mail me if you know why this is happening, as I don't generally read 
this news group. I'll summarize if there is enough interest.

Thanx

---
Pete Flugstad				| Internet: pete@arl.wustl.edu
Applied Research Laboratory		| Tel: (314) 935-6110
Department of Computer Science		| "To err is Human, to really 
Washington University in St. Louis	|  foul up requires a computer"
From: pcm@cs.brown.edu (Peter C. McCluskey)
Subject: Re: Virtual function call within constructors
Organization: Brown Computer Science Dept.
Date: Thu, 28 Jan 1993 22:46:26 GMT

In article <rmartin.728088421@stripe>, rmartin@stripe.Rational.COM (Bob Martin) writes:
|> >gschwarz@dcc.uchile.cl (Guillermo Schwarz Utrup) writes:
|> >>I have found that virtual functions are not handled as one could expect
|> >>when called from a constructor.

|> So be very careful in your constructors and destructors.  Since
|> virtual functions don't deploy, they should not be called.  If calling
|> them is necessary then use the scope operator to call them directly:
|> (e.g. MyClass::MyVirtualFunction()).  Never call a pure virtual
|> function from a constructor or a destructor.....

 I would expect that any decent compiler would give a warning when
the scope operator is ommitted on a virtual function call in a constructor
or destructor. However, I have tested this on 2 well-known compilers and
seen no diagnostics. Would any compiler writers care to justify this
apparent oversight?
-- 
----------------------------------------------------------------------
  >> Peter McCluskey >> pcm@cs.brown.edu >>   Reunite Gondwanaland!
----------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: ianhogg@milli.cs.umn.edu (Ian J. Hogg)
Subject: Re: FREE C++ development environments?
Organization: University of Minnesota, Minneapolis, CSci dept.
Date: Wed, 27 Jan 1993 16:30:36 GMT

In article <1k5kthINNibk@rs2.hrz.th-darmstadt.de> eggert@rbg.informatik.th-darmstadt.de (lars eggert) writes:
>
>We were using HP SoftBench, since this is the only one currently installed
>at our site, but it doesn't run on SUNs and gets quite slow when it's being
>used by three or more persons at the same time. But something similar
>(or better!) would be fine.
>
HP does sell Softbench for Sun's.

--
===============================================================================
Ian Hogg						ianhogg@cs.umn.edu
                                                        (612) 424-6332
Newsgroups: comp.lang.c++
From: dgg@bnr.ca (Gordon Grimes)
Subject: Re: Objects in Shared Memory
Date: Wed, 27 Jan 1993 00:47:35 GMT
Organization: BNR

In article <1993Jan25.105459.4799@hellgate.utah.edu>, clark%asylum.cs.utah.edu@cs.utah.edu (Charles Clark) writes:
|> In article <19930125.084616.825@almaden.ibm.com> jimi@vnet.ibm.com (Jim Meyers) writes:
|> >>
|> >>The first of these approaches is not complete in that it does not
|> >>address the problem of intra-object references.  Thus, virtual base classes
|> >>can not be used in the inheritance hierarchy of the shared objects.
|> >
|> >This is not all clear to me... Can you elaborate on why you believe that
|> >Jordan's method does not support intra-object references?
|> 
|> After reviewing Jordan's paper, I see that intra-object references will
|> resolve correctly (Jim, thanks for pointing this out).  His method 
|> requires that, not only the location of the vtable be coordinated, but 
|> also the location of the shared memory segment be coordinated.  This means 
|> that each process which accesses the shared memory segment must attach 
|> that memory segment at the same virtual memory address.  With the memory 
|> segment at the same vm address, the intra-object references will resolve 
|> correctly.  
|> 
|> Straying from the orignal subject a little, how can the location of the 
|> shared memory segments be coordinated?  The vtable location is fixed at 
|> link edit time, thus one would know then whether there is a conflict. 
|> Since the creation and attachment of the shared memory segment is at run-
|> time, how can one ensure that the vm address of each of the cooperating
|> processes will be available?
|> 
|> 	--Charles
|> 

Some operating systems (HPUX-8.0, for instance) reserve specific virual
addresses for shared memory segments.  As I recall, the manual implies
that each shmem area has its *own* predetermined segment.  This would
suggest that attaching the same shmem area in two processes gaurentees
their identical mapping.

I could understand the reasons for an OS to go halfway: start allocating
virtual addresses from, say, 0xc0000000 upward for attached segments, but
not promise that shmem area "A" will map to the exact same virtual address
in two process.  If one is working on such an OS the workaround is to
programmatically ensure that both processes attach the areas in the same
order.

Gordon Grimes
Bell Northern Research
Newsgroups: comp.lang.c++
From: djb@geovision.gvc.com (Darren Burns)
Subject: C++ maintenance
Organization: Not officially GeoVision Systems Inc., Ottawa, Ontario, Canada
Distribution: na
Date: Sat, 23 Jan 1993 19:25:44 GMT


I recently had the pleasure (not) of trying to track down a bug in
some C++ code.  The author(s) of the code were not that experienced
in C++, but I don't think that matters here.

I just wanted to get some comments about the following.  Suppose I'm
looking at a C++ program.  I have a pretty good understanding of what
it does, but I'm not terribly familiar with the code.  In a member
function I see:

int the_class::do_something ( )
{
...
    foo->xxx();
...
}

Now, I'm browsing through this code and I'm thinking maybe the bug I'm
looking for is in xxx().  I want to take a look at it.  In order to know
which xxx to look at (since there may be many classes that have xxx), I
need to know what class foo is.  But foo could be a global variable,
a member of the_class, or a variable local to the function.  I have to
hunt all over the place just to find out where to look for xxx.

I find this a real pain.  I'm not experienced with C++, so maybe it's
something you get used to.  I think that it's a general problem with
OOP, although the syntax of the language can make it better or worse.
It seems that C++ is great if you know the program very well (i.e. if
you designed/wrote it), but is difficult to maintain.

Are there others who find the same thing?  Is there some way of setting
things up to avoid this sort of problem?

Thanks.

(I never did find that bug, by the way :-))

Darren Burns
From: drkerns@sony7.sdrc.com (sean kerns)
Newsgroups: comp.lang.c++
Subject: Help. DOS from TCWIN??
Date: 27 Jan 93 13:40:54 GMT
Organization: SDRC


 Can anybody tell me if I can compile a program that will run from DOS using
Turbo C++ ? I can't believe that you can only make Windows programs with the
Windows version. Do I need a separate compiler for DOS, or am I missing something.
As you can probably tell, I haven't done much of this, so I appreciate any help.
Thanks

SRK

sean.kerns@sdrc.com
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Newsgroups: comp.lang.c++
Subject: Re: Is (p) instead of (p!=NULL) portable?
Date: 27 Jan 93 11:45:28 GMT
Reply-To: nikki@trmphrst.demon.co.uk
Organization: Trumphurst Ltd.
X-Mailer: cppnews $Revision: 1.31 $

In article <1993Jan25.125627.29030@ugle.unit.no> robert@alkymi.unit.no (Robert Schmidt) writes:
> 
> In PC C's, the NULL pointer is defined with a bit pattern of all zero's,
> and the constructs 
>       if (p)
> and
>       if (!p)
> checks for NULL and non-NULL respectively.  Is this portable to *all*
> platforms?

Yes. Even if a NULL pointer does NOT have a bit pattern of all zeroes, the
above is still guaranteed to work.

-- 
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
From: gray@celia.UUCP (Steve Gray)
Newsgroups: comp.lang.c++
Subject: Re: Overloading Operators
Date: 24 Jan 93 00:07:56 GMT
Reply-To: celia!gray@usc.edu (Steve Gray)
Organization: Rhythm & Hues, Inc., Hollywood

> Like Nikki, I can't think of any way in which a const or volatile
> reference differs from a plain reference.  Is there a difference?

A const reference differs in a very important way from a plain reference:
it clearly states that the member function has no side effects.  One of
my (and others at R&H's) primary objections to using references is that
it means member functions can have un-obvious side effects on their parameters. 
i.e. they can change the contents of a variable which was passed by value (as 
far as the caller's syntax is concerned) and therefor should not be changed by 
the member function.

We have basically outlawed non-const references as being too dangerous.  I
personally would have preferred that they not even be allowed in the language,
but I can understand why (given the syntax of the language) they are allowed.
Newsgroups: comp.lang.c++,comp.object
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Dynamic Linking and Sun Sparcs, do they mix?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 27 Jan 1993 19:21:31 GMT

In article <1993Jan25.084030.5548@cbfsb.cb.att.com> nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:
>From article <1993Jan23.043030.5358@aee.aee.com>, by gene@aee.aee.com (Gene Kochanowsky):
>> Greetings,
>> 
>> 	I have a multi-platform project I am working on that requires the
>> use of DDLs. I know there are many fine products on the PC that support such
>> things. Does anyone know if there are any developement products that support
>> DDLs on the Sun, and what version of the SunOS is needed. User preferences 
>> are welcome.
>> 
>
>I can't think of anyting that would actualy require dynamic libraries but
>assuming that you have a real need you might like to know that they are
>the norm on most UNIX systems and have been for long before they became
>trendy on PCs.

	Applications that require DLLS are those that do
RUN-TIME linkage and not just LOAD-TIME linkage. Load-time
linkage is just a convenience --- actually, sometimes an
inconvenience.

	RUN-TIME linkage is different. Consider drawing
program. It has a class 'drawable'. Standard drawables
are Square and Circle and Line.

	Bored with these? Fine. Write your own DLL
classes for Oval, EiffelTower, Polygon, Fish. Put the
names of these in a text file and run the drawing
program.

	Presto: user defined shapes. Cant be
done without either RUN-TIME linkage or some sort
of interpreter.

	Can Unix's do this? If not, they cant really
do dynamic linkage at all, just code sharing. 
Code sharing is certainly nice, but it is not functionally
equivalent to real dynamic linkage.

-- 
;----------------------------------------------------------------------
        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.lang.c++,comp.object
From: ssh@cray.com (Steven Hein)
Subject: Clashes between <stdarg.h> and <varargs.h>
Keywords: stdarg vararg
Reply-To: ssh@cray.com
Organization: Cray Research, Inc.
Date: 27 Jan 93 08:59:07 CST

I am writing a user interface in C++ using the XView toolkit.  But, I'm having a
problem using stdarg.h and varargs in the same source file (XView uses varargs and I
need to include some XView header files in this source).  Can anyone tell me:

	a) how to make stdarg and varargs cooperate in the same C++ source file

				OR

	b) how to use varargs to implement a C++ member function declared like this:

			void xxx::output(char* fmt, ...);

I don't need to parse the argument list--I just need to pass it to vsprintf() or
to vfprintf().

Any help would be appreciated--I'm at my wit's end with this one...Also, I'm a newbie
with this 'news' thing, so please email me any suggestions so I'm sure to get them!

Thanks!

----
Steve Hein
Cray Research, Inc.
tel.    (715) 726-5525
email:  ssh@cray.com

Newsgroups: comp.lang.c++