HDTenEightyP/NetNews huggingface dataset:
From: jeffw@cs.tamu.edu (Jeffrey A Waller)
Newsgroups: comp.lang.c++
Subject: Re: Help: using GDB to debug G++-compiled programs
Date: 12 Jan 1993 23:54:20 GMT
Organization: Computer Science Dept., Texas A&M University
Distribution: world
NNTP-Posting-Host: sparc47.cs.tamu.edu

In article <1993Jan12.014848.14135@nuscc.nus.sg>, suresh@papaya.iss.nus.sg (Suresh Thennarangam - Research Scholar) writes:
|> Note that even then you may not be able to access inline methods
|> unless you move their declaration outside the class definition.


This may have been true of older versions, but I think -g switch causes
gcc 2.2.2 to move otherwise inlined functions out of line (from the man
page).

     -finline

          Pay attention the inline keyword.  Normally  the  nega-
          tion  of  this option `-fno-inline' is used to keep the
          compiler from expanding any functions inline.  However,
          the  opposite  effect  may  be desirable when compiling
          with `-g', since `-g' normally  turns  off  all  inline
          function expansion.

and if -g does not turn off inlining in some case -fno-inline will.
So instead of moving around you code use if necessary.

g++ -ggdb -fno-inline myC++.C -o myOut
 

						-Jeff
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Standard library functions and macros
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 8 Jan 1993 02:40:03 GMT

jimad@microsoft.com (Jim Adcock) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>|I would be surprised if the changes did not require "real" external functions
>|"shadowing" the inline definitions just as ANSI C required real functions
>|to shadow macro definitions. 
>
>It wouldn't be a conforming implementation if it provided both inline
>and out-of-line implementation of a function.  That would violate
>the one-definition rule.

This is not correct for several reasons. First, the implementation is
*allowed* to violate the one-definition rule. (That rule constrains
conforming programs, not conforming implementations.)
Second, the inline definitions have internal linkage (which causes the silent
change that you pointed out earlier) and thus are actually different functions
to the out-of-line version in the library.

[Attribution lost - I think this is Steve Clamage:]
>|>|If Jim is saying that in a particular implementation the #undef has
>|>|this effect and believes that effect should be preserved, then nothing
>|>|stops an implementation from giving the #undef the same effect in C++,
>|>|although I suspect he will have to lobby his vendors very hard to
>|>|convince them to implement such a feature.
[and this is Jim Adcock replying:]
>|>If this is possible, then show me how to do it, because the solution
>|>is not obvious to me.

[My suggestion omitted]

>Your "solution" does not implement the semantics called out in the ANSI-C
>spec. [...]

Yes. I was just showing how to preserve the effect of #undef, not all the
other features. I don't see any major difficulty preserving virtually all
the rest of the semantics, even down to (putchar)('x') being
out-of-line, but as Steve Clamage stated, I suspect you will have to
lobby your vendors very hard to convince them to implement such
features.

-- 
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.lang.c++
From: reichrt@rtsg.mot.com (Charles H. Reichert)
Subject: Forsale - Borland's C++ 3.0, IslandSystem's ObjMenu
Organization: Motorola, Radio Telephone Systems Group
Distribution: local, usa
Date: Tue, 5 Jan 1993 18:56:59 GMT

I have for Sale Borland's C, C++ 3.0 Development system with all Manuals.

Also Island System's Graphical Development system ObjMenu 1.5 designed
to work with Borland's 3.x and MS C++ 7.1.
Dazzling screens, menus, icons, buttons, data entry, HyperText Help, Mail system
Window Manager, Event Manager,OSF/Motif look and feel, customize sizes, colors, styles
, and more
.  With all Manuals.

Will transfer registrations to new user.

New Prices around $265 for ObjMenu, Borland's 3.0 around $320

Will let both go for $300....or each separately for $175




-- 
     ====================================================================
     | Charles H. Reichert  708-632-6669 Work - MOTOROLA, INC  Cellular |
     | KD9JQ                708-358-3827 HOME - after 8PM CST  weekdays |
     |                      955 Concord Ln.  Hoffman Ests., IL. 60195   |
     ====================================================================
    
 
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Callbacks in C++
Organization: Rational
Date: Mon, 11 Jan 1993 23:17:12 GMT

hlf@nic.cerf.net (Howard Ferguson) writes:


|If I derive from the ButtonCallback (supplied by the class library)
|then I presume I will have to overwrite the ButtonHasBeenClicked() 
|function which is a member of the ButtonCallback to do something like 
|this 

|UserButtonCallback::ButtonHasBeenClicked(Buttonvoid *userInfo)
|{
|	switch (userInfo) {
|	case SAVE : display->save_screen();
|			break;

|	case ZOOM : display->zoom_screen();
|			break;
|}

|I can see where your suggestion of deriving from a pure virtual would
|be very useful in the situation where the number and types of 
|callbacks are restricted -- but does it provide any easy way of getting
|the functionality required for the example just given ???????

I am not quite clear on what you mean here.  Let me reinterpret your
statement and then give you an answer to what I think your question
is.

You have two buttons in a user window.  Clicking on one saves the
screen.  Clicking on the other zooms the screen.  Both of them have
been created with "Callback" objects which are both instances of the
class UserButtonCallback.  You have derived this calss from (say) the
base class "ButtonCallback" which implements the pure virtual
"ButtonHasBeenClicked" Method.

In the code above, you appear to be passing in "userInfo" which seems
to be the identity of the button that was clicked.  Then you switch on
this ID to decide what to do.

=-=-=-=-=-=-=-=-=-=-=-=-

A better solution is to derive two different classes from
"ButtonCallback"  SaveButtonCallback and ZoomButtonCallback.  The Save
button is created with the SaveButtonCallback instance.  The Zoom
button is created with the ZoomButtonCallback instance.  In each, the
"ButtonHasBeenClicked" met;hod is overriden to do the appropriate
thing.


class ZoomButtonCallback: public ButtonCallback
{
  public:
    void ButtonHasBeenClicked() {display->ZoomScreen();}
};


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: erc@netcom.com (Eric Smith)
Subject: Re: oopslooking for PerClass/SizeFreeList, oops
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Thu, 7 Jan 1993 06:15:33 GMT

In article <1993Jan7.000515.11405@umr.edu> S103408@UMRVMB.umr.edu writes:
>Ok, BC++3.1 isn't working due to > 64K code segment.
>
>Anybody out there have any experience with:
>MetaWare High C++
>Zortech C++
>Watcom 9.0 C++
>
>that can tell me if these can do 32bit flat memory model coding
>with dos and a dos-extender?  Can I malloc() objects > 64K ?

I have used Zortech version 3.04, and yes, it can malloc megabytes.

>Are there outrageous liscensing restrictions on the generated code?

None that I know of.

>Can I link in the extender or does it have to be already running?

Zortech links it in automatically if you use their X memory model.

>They all cost a fortune, so some info would be welcome.

Zortech v3.04 cost me $99 as an upgrade to an earlier version, but the
present full price for the multiplatform version is something like
$1497, and the present upgrade prices are something like $129 to $499,
depending on which version you upgrade to, regardless of which version
you had before.

Beware that Zortech has a reputation for releasing compilers with lots
of bugs.  I don't even want to upgrade my version 3.04 to 3.1 unless
they first publish a bug list showing which bugs have been fixed.  Some
of the bugs in 3.04 were very bad, such that I often had to reboot in
the middle of a compile.  Also, there were some quirks in their
interpretation of the C++ language, which wouldn't cause major problems
for beginning C++ programmers, but which made it hard to port big
programs to and from their compiler.

If cost is a factor, you should consider the Gnu version.  I think it
is or soon will be available on NT, and is already available on OS/2
and there is a DOS-extender version called DJGPP.  But I'm not sure
whether the Gnu version is better than Zortech 3.1, and I don't know
anyone who uses both, so they are hard to compare.  When I started
using Zortech 3.04, it was because I wanted a DOS-extender C++ that
didn't do swapping to disk, and back then the only version of DJGPP I
could find would use half of memory as a disk cache for swapping, which
made it more likely to swap more often.  Zortech 3.04 didn't do any
swapping at all, which was what I wanted.

The Gnu versions, including DJGPP, are free, course, so if it turns out
to not suit you, you can just abandon it without feeling like you have
wasted your money.  Also the source code is free, which gives you a
chance to fix any bugs that bother you.
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Subject: Re: Is it possible to use 'delete this' ?
Organization: Rational
Date: Sun, 10 Jan 1993 14:12:48 GMT

robertd@kauri.vuw.ac.nz (Robert Davies) writes:

|The problem I had with Bob's first reply was that he didn't answer the
|question: is "delete this" legal.

To my knowledge, the syntax is legal.  (Steve Clamage:  Can you
comment on legality?)

|Then it would be appropriate to give a warning. Incidentally, is the warning
|about is causing difficulty to some compilers just a "gut feeling" or are
|there specific examples?

No specific examples.  I give the warning because I have seen no words
in the ARM to the effect that the code generated by the compiler must
assume that the object may not exist during a member function call.

|Bob's warning about "delete this" seems to apply to any use of "delete" by
|an entity that didn't do the corresponding "new". Otherwise there is always
|the risk that the "delete" will be applied to something not created by
|"new". Is this another safe programming rule?

No.  And my warning is only about the dangers of "delete this".
"delete this" can only be appropriate for objects that are "always"
allocated from the heap.  Unfortunately, there is no way for an object
to insure this. 


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: ventura!tim@UCSD.EDU (Tim Dierks)
Newsgroups: comp.lang.c++
Subject: Need Help on Debugging Objects
Keywords: object, debug, constructor
Date: 8 Jan 93 00:27:56 GMT
Reply-To: ventura!tim@UCSD.EDU
Organization: Ventura Software, Inc., A XEROX Company

I am looking for ideas on how to track the creation/deletion of objects for
debugging purposes in an application I am writing.  For the PC, The Microsoft
Foundation Class offers a TRACE macro that lets you display a message, but I'd like
more functionality, and I don't plan on use the MFC.  I'd like to be able to do
things like those listed below:

- Display a message each time an object is created/deleted, identifying what type of
  object it is, and some unique identifier for the object.
- Identify the creator of each object when created.
- Be able to dump the data members of any object currently in existence.
- Be able to list all the objects currently in existence at any time.

Has anyone had any experience with this?  Are there already existing class
libraries or tools that do this sort of thing?  I'd appreciate any ideas.

--
Tim Dierks                             internet -- ventura!tim@ucsd.edu
Ventura Software, Inc.                 uunet    -- ucsd!ventura!tim
Newsgroups: comp.lang.c++
From: pauljo@microsoft.com (Paul Johns)
Subject: Re: Passing 2-d arrys to functions
Date: 11 Jan 93 23:57:54 GMT
Organization: Microsoft Corp., Redmond, Washington, USA
Distribution: usa

In article <1993Jan11.030238.6688@nuscc.nus.sg> suresh@argon.iss.nus.sg wrote:

> Yes, I think this program will work always .. since you have passed in 
> a double ** pointer which is a vector of double*, the least dimension
> of the array is not required to correctly index the values.
> Although the same syntax can be used to access 2-d arrays (no flames
> please .. I mean statically allocated as in double arr[2][2] ) and
> variables of type pointer to pointer ( double **), the underlying memory 
> layout need not be the same. However, the algorithm used to index either
> one is the same.. pointer arithmetic. 

The algorithm is different.  Check out the assembly code generated to
see how.

> I believe( correct me if I am wrong) most or all C/C++ compilers always
> use the same pointer arithmetic no matter whether the array passed 
> is declared as  double arr[][least_dim]  or  double **. 

This is absolutely not true.  The two pointers are of different types.
The type for the array case is "double (*arr)[least_dim];".  The type
in the pointer case is "double **arr;".  The addressing they use isn't
the same.  (Show the result of arr++ in the two cases, or the type
of *arr--to see this.)

To do "arr[3][4]" you need to do entirely different operations depending
on the type of arr:

In the array case, you multiply the column number (3) by the row size 
(least_dim) and add the row number (4), finally multiplying by the 
element size (8) to find the offset of the element from the beginning
of the two-dimensional array's block of contiguous memory.

In the pointer case, you index into the pointer array (using 3), 
then use the address found there to index (using 4) into the one-
dimensional array of doubles pointed to by the pointer in the
pointer array.

> This explains
> how we can successfully mix pointer arithmetic and array-indexing. 
> The last dimension is required merely for setting up storage.

No.  This explains why you can't mix pointer operations.  Many have
tried, and many have failed.

It **IS** ok to mix []'s and pointer arithmetic **IFF** the underlying
pointer types are the same:

	Array type		Underlying pointer type

	char a[3];		char *a;
	char a[3][5];		char (*a)[5];
	char *a[4];		char **a;

The rule is to drop the leftmost subscript and bind the * operator
tightly to the identifier.

// Paul
From: alane@wozzle.linet.org (J. Alan Eldridge)
Newsgroups: comp.lang.c++
Subject: Re: oopslooking for PerClass/SizeFreeList, oops
Date: 12 Jan 93 01:59:40 GMT
Organization: Disorganization

erc@netcom.com (Eric Smith) writes:

> Beware that Zortech has a reputation for releasing compilers with lots
> of bugs.  I don't even want to upgrade my version 3.04 to 3.1 unless
> they first publish a bug list showing which bugs have been fixed.  Some

Yes, this is true. I beta test for them... their QA dept is seriously
understaffed, unfortunately.

> If cost is a factor, you should consider the Gnu version.  I think it
> is or soon will be available on NT, and is already available on OS/2
> and there is a DOS-extender version called DJGPP.  But I'm not sure
> whether the Gnu version is better than Zortech 3.1, and I don't know
> anyone who uses both, so they are hard to compare.  When I started

They're good for different things. I wrote a number of the DJGPP
libraries, so I have experience with both compilers. Zortech is a
bit flakier in the compiler dept and more stable in the extender dept.
(uses the non-VM version of FlashTek's X32-VM).

Zortech has no protected mode debugging -- DJ has an asm level
debugger.

To get debugging for 32 bit code with Zortech, you have to buy X32-VM
and Flash-View from FlashTek -- both excellent products, btw.

> using Zortech 3.04, it was because I wanted a DOS-extender C++ that
> didn't do swapping to disk, and back then the only version of DJGPP I
> could find would use half of memory as a disk cache for swapping, which

Huh?? I don't really think so ... I know the extender for DJGPP fairly
well, and it doesn't do anything of the sort.

> made it more likely to swap more often.  Zortech 3.04 didn't do any
> swapping at all, which was what I wanted.

So you didn't want virtual memory --- that's really it. I rather like
having VM. To each his own.

> wasted your money.  Also the source code is free, which gives you a
> chance to fix any bugs that bother you.

Ever read the source to cc1plus? or even the gcc driver? <giggle>


alane@wozzle.linet.org (J. Alan Eldridge)
Fido: The University of Walamaloo 1:272/38.473
Newsgroups: comp.lang.c++
From: kcc056@tijc02.uucp (Karen Bench)
Subject: Re: TResourceFile Memory Los
Organization: Siemens Industrial Automation, Johnson City TN
Date: Thu, 7 Jan 93 04:35:23 GMT

From article <726147569.0@ttlg.ttlg.UUCP>, by Neal.Sanche@ttlg.UUCP (Neal Sanche):
> Hi All, 
>  
> I am using Borland C++ 3.1 and Turbo Vision and am having a 
> memory loss of 32 bytes every time I instantiate a TResourceFile 
> and then destroy it. I have looked through the documentation and 
> my usage of this object is correct. Here is the Code: 
>  
>    ... 
>    fpstream *ifps; 
>  
>    ifps = new fpstream("FILE.NAM", ios::out | ios::binary); 
>    if (ifps->good()) 
>    { 
>      TResourceFile *res; 
>      res = new TResourceFile(ifps); 
>      destroy(res); 
>    } 
>    else delete(ifps); 
>    ... 
>  
> This code creates a TResourceFile and destroys it immediately. There 
> should be no loss of memory, but 32 bytes escape... Where is this 
> memory loss occuring? I am afraid that some kind of dangling pointer 
> will come back to haunt me and my clients! :) 
>  
> Thanks for any help you can give me. 
>  
> -Neal 
>  
> ... OFFLINE 1.41 
> 
>  * Origin: Paradigm BBS: A programmer's paradise. (42:100/11)
I had the same problem and (I think) traced it to the constructor
in tresfile.cpp (line 50 in my source file) the variable header
is being created but not freed so I put a delete header at the bottom
of the constructor and this seems to fix it.
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Subject: Re: Is calling a function to assign a value to a static global legal?
Reply-To: nikki@trmphrst.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.30 $
Organization: Trumphurst Ltd.
Date: Tue, 5 Jan 1993 18:15:50 +0000

In article <34726@sales.GBA.NYU.EDU> wlee@sales.GBA.NYU.EDU (Wai-Shing Lee) writes:
>    I want to initialize a static global at run-time but I don't want to
> have to have a programmer using my modules to have to call some init() funciton
> at the begining of thier main().
> 
> I can get this to compile under Borland C++ 3.1, but only if it is compiled as
> C++, it doesn't like it if it is compiled as plain Borland C.

It is legal to do this in C++, but not in C. 

> extern "C"
> {
> #include <alloc.h>
> }
> 
> static int *pointer ;
> static int initialized=findvideomemory() ;

Not legal C++, because findvideomemory is not defined in alloc.h, or in 
your program so far. I assume this is because you have just left out the 
declaration in your posting. 

Not legal C (unless findvideomemory() is a macro whose value can be 
determined at compile time).

> static int makepointer(void)
> {
> 	pointer=(int*)calloc(10, sizeof(char)) ;

You should return a value from this function, as it is declared to return 
an integer.

> }

I don't see the relevence of this function - it is not accessed anywhere 
else in your example.

> The variable "initialized" is junk, but I could just as easily return a value
> from makepointer(), but I have more stuff going on in makepointer() than
> appears here.
> 
> I've traced it and sure enough makepointer() is called and pointer is assigned
> a value before main() even starts.  Is the portable, legal.  I didn't look
> to hard in my C++ book, but there weren't any obvious answers.  Is this
> C++, C or something I should stay away from?

I don't understand why makepointer is called - I can't see any calls to it
anywhere in the example given.

I don't suppose "findvideopointer" is a type for "makepointer" is it ?

-- 
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.
Newsgroups: comp.lang.c++
From: dave@news.ccutah.edu (dave martin)
Subject: Re: Serious problem with BC++ 3.0
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Thu, 7 Jan 93 17:11:12 GMT

tpenttin@majakka.uku.fi (Tommi Penttinen) writes:
: When I try to compile one of my c++ files, BC (IDE version) halts the
: compilation with an error message at some point and I have no idea what's
: causing it. The error looks something like this:
: 	EXCEPTION 13:general protection fault at 0A7F:03C0 error code 1768
: 	...
: According to the above message segments ds, cs and ss point to BC.EXE (or
: some part of it..)
: Has anyone seen this error and/or does anyone know what's wrong here?
: I have Windows 3.1 and I am using its himem.sys and emm386.exe; could that
: be causing the problem?
: Please, help me!
: 
: Any replies appreciated.
: 
: ++Tommi
:       +---------------------------------------------+-----------------------+

I am having this same problem,  it occurs at random times, usually it compiles
fine, but sometimes (generaaly while trying to link but also when compiling)
it has that blasted exception.  It decreased in frequency when I switched to
the huge memory model for code generation, but it still happens occasionally.

Also the standalone debugger seems to love to hang the machine.  The integrated
one does sometimes but much less often.  This is very annonying, I hope it
gets fixed.

dave@csulx.weber.edu (ignore the header, its probably the wrong address)
From: davidm@consilium.com (David S. Masterson)
Newsgroups: comp.lang.c++
Subject: Re: Callbacks in C++
Date: 11 Jan 93 06:54:24 GMT
	<1iqqipINN11b@news.cerf.net>
Distribution: comp
Organization: Consilium Inc., Mountain View, California
In-reply-to: hlf@nic.cerf.net's message of 11 Jan 93 03:46:33 GMT
X-Posting-Software: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]

>>>>> On 11 Jan 93 03:46:33 GMT, hlf@nic.cerf.net (Howard Ferguson) said:

> If I derive from the ButtonCallback (supplied by the class library) then I
> presume I will have to overwrite the ButtonHasBeenClicked() function which
> is a member of the ButtonCallback to do something like this

> UserButtonCallback::ButtonHasBeenClicked(Buttonvoid *userInfo)
> {
> 	switch (userInfo) {
> 	case SAVE : display->save_screen();
> 			break;
> 	case ZOOM : display->zoom_screen();
> 			break;
> }

> I can see where your suggestion of deriving from a pure virtual would be
> very useful in the situation where the number and types of callbacks are
> restricted -- but does it provide any easy way of getting the functionality
> required for the example just given ???????

Your code assumes that there is one button on the display and, therefore, one
callback that is invoked for that button.  In reality, the SAVE and ZOOM
button are two different buttons and they should, therefore, have their own
callbacks that do specifically what they want.  When each button is
constructed on the display, it should tell the system what its callback is.
That callback is specific to that button.
--
====================================================================
David Masterson					Consilium, Inc.
(415) 691-6311					640 Clyde Ct.
davidm@consilium.com				Mtn. View, CA  94043
====================================================================
"Is not the whole world a vast house of assignation to which the filing system
 has been lost?"
-- Quentin Crisp
Newsgroups: comp.lang.c++