Departments

We Have Mail

Letters to the editor may be sent via email to cujed@mfi.com, or via the postal service to Letters to the Editor, C/C++ Users Journal, 1601 W. 23rd St., Ste 200, Lawrence, KS 66046-2700.

Editor,

Saw the response re shells etc. in 10/97, and thought I'd belatedly add my 2 cents regarding Windows and command lines. What may not be obvious is that Windows 95 was a huge improvement over Windows 3.1 for developers — because it has a working command line. Specifically, you can run Windows programs from the command line in a DOS window. It may sound ridiculous, but you couldn't do that in Windows 3. So I can use batch files and various other advanced techniques.

Developing Windows or any other program in Windows 3.1 was just stupid, and actually I don't think it happened much. But now, I'd say developing Windows programs — including Windows 3 programs — in any environment other than Windows 95 is not smart. (Of course you've got to test the program in the target environment; Windows 3.1 programs run fine in Windows 95, but unfortunately some times too fine; test under Windows 3.1 to bring out their crotchets.)

J.G. Owen
71121.625@compuserve.com

Dear P.J.,

I am a rookie programmer. My total experience in data processing, including school, amounts to about 2 years. I have been employed as a C programmer for less than six months. I won't even pretend to understand your qualifications and think it is safe to state that you have forgotten more about programming than I will learn in the next few years.

Even in view of the foregoing, your August Editor's Forum in CUJ has earned you the honor of being the first person to warrant a good flaming from me since I learned to change directories.

Let's start from the top.

Issue: "modern operating systems rust." Response: Win 95 and NT are not terribly modern and rust is a very mild term. These are systems designed to bring the fastest CPU to its knees. Ease of use. That's it, no more and no less. The only reason for a developer to have either one is to develop software for that platform.

Issue: "spoiled by years of running Unix." Response: Who said you had to stop? More on this point later.

Issue: "Microsoft's Internet Explorer." Response: Friends don't let friends do Windows. If you must, do yourself a favor and ride on over to your local Egghead (Maybe CompUSA for you) and round up a copy of Netscape. If you want compatibility testing it's awfully hard to beat the Lynx browser.

Issue: "Windows 95." Response: This is the system that I installed on my parents' machine. It is not what I use or endorse. I do keep a 95 License on a DOS partition at home for the odd utility that doesn't like NT. NT 4.0 is a whole new breed o' cat. Check it out.

Issue: "scary experience ... work is held prisoner." Response: a) Mr. Backup is your buddy. b) A trusty DOS boot disk will get you to that forbidden fortress of incarcerated data.

Issue: "Elaborate and perilous series of maneuvers." Response: P.J., it's time for us to have a little chat and introduce you to some rad kewell warez. System Commander. Trust the new guy on this one — the best seventy bucks you will ever spend. On my boxes (all three of them) you will find IBM's Excellent PC-DOS and LINUX in addition to the graphic intensive GUI/OOUI OS du jour. The reason is painfully simple to divine. When "Bill's BetaWare" or "O/S Trash-o-matic" fails (and they will), we can boot to DOS and get our stuff. If it gets really ugly and the boot partition is having cigars and brandy with Elvis, a Linux boot floppy and a simple yet elegant ftp session will create the escape from Alcatraz. After saving all of our stuff, we are ready for the Rookie Ritual. Repartitioning, Reformatting, Reinstalling and Really Cursing all those weenises who can actually operate the registry editor.

A Linux partition that holds some editing tools and the TCP/IP suite can be relatively compact. Get wiggy and throw in the GNU C/C++ thingy. Having Perl around doesn't exactly bite either (way to go Larry!!). I also like to keep a DOS port of vi and PCC12C on disk and nearby at all times. These two tools on a boot floppy can be extra bonus.

Issue: "I don't want to count the hours I spent on this exercise." Response: If you had consulted with me from the get-go you would never have gone down that road. (A year and a half ago I was running MS-DOS, Linux, and Win3.1 on an aging 386 with a 105 MB Quantum) I recently experienced a similar tragedy with 95 on my Packard Bell. First the registry gave ominous warning messages and then the poor thing invoked the autocrash feature, cheerfully displaying the "blue screen o' death" on boot.

Although our problems were similar, my response was remarkably different. I booted into Linux, sent my code over the coax to the aging 386 (now sporting a huge 630 MB Seagate), and laid down the cash for NT.

In closing, let me emphatically state that I am not one of those anti-Microsoft renegades. Microsoft has revolutionized the way we work and opened up unlimited horizons for all us geeks. We just have to learn to live with the shortcomings. I personally dig playing with different systems. I really enjoy CUJ, although most of it is like C++ and therefore whacky to me. Please keep up the good work.

If you need any help setting up your laptop, e-mail me for our planetary location and we will hook you up gratis. I sincerely hope that you have enjoyed my high-school-dropout spelling and structure as much as I enjoyed your Editor's Forum.

Best Regards,

Doug Beatty

I've long observed that the passion behind a technical judgement is often inversely proportional to the experience on which the judgement is based. I do in fact use Unix, Windows NT 4.0, backups, boot disks, etc. on a regular basis. I use Windows 95 and Internet Explorer for sound business and technical reasons, not just because they are allegedly user friendly. The problems I have had with Windows 95 I have also had, in spades, with Unix, NT, and other systems. My point was that the complexity of our tools can sometimes be a time eater. I appreciate the advice on how to avoid such problems in the future, but I also have to observe that I've been there and done that. — pjp

Dear Editor,

I just read "Member Functions as Callbacks in Win32," by Tim Duggan in the August 1997 issue of C/C++ Users Journal. The solution proposed by Tim in his article is effective, but suffers from a couple of drawbacks: a global function for creating the callback (MyTimerCallback), and only one callback per class.

A better solution is to use a template class to take care of all the messing around between the C API and your class. With such a template creating a callback becomes simple:

class myobject {
public:
     myobject()
          // constructor
     {//
          // create the timer event
          t1.create(this, timer, 1000, 500);
     }
     
     void timer()
          // handle a timer callback
     {//
          cout << "tick . . ." << endl;
     }
     
private:
     timer_callback<myobject> _t;
};

Of course this level of simplicity is only achieved at the expense of creating the timer_callback template! (See Listing 1 for details.)

Regards,

Cliff Penton

As the above letters shows, you can always improve on any program. We appreciate the feedback. — pjp

Editor,

Here are questions more properly addressed to PowerSoft (formerly Watcom) or Tenberry (formerly Rational Systems). I've had no success getting satisfactory answers from them, so I turn to you.

I write and run C++ codes requiring much memory to store large arrays and requiring much running time. My 200 Mhz Pentium Pro computer has 128 MB of RAM. My problem is that I do not know of a C++ compiler which allows access to 128 MB of (physical, not virtual) RAM, and virtual memory managers slow down the calculations too much.

More specifically, Using Watcom's C++ compilers, the codes run fastest when compiled and run in DOS mode (true DOS, not the DOS prompt from Windows 95). The Tenberry DOS extender and the Watcom C++ compiler are invoked at the DOS command line:

C:\>wcl386/l=dos4g codename /options

to be exact. However, this works only up to 32 MB of RAM, The Tenberry 4GWpro DOS extender does not help.

If the codes are compiled in Windows 95 using the Watcom Integrated Development Environment (ide) with the options:

Target Environment = Win32 [NT/Win95/Win32s]
Image Type = Character Mode Executable [.exe]

then the compiled codes work up to 128 MB of RAM, but virtual, not physical, RAM. Windows 95 invokes the virtual memory manager (VMM). The VMM setting can be found under: start, help, virtual memory, 1. click arrow, 2. click virtual memory. I use the default option and let Windows 95 do VMM. The VMM does its job, but the speed is down by a factor of three, which is awful for codes requiring 100 hours to run.

My questions are:

1. How do I get the speed back?

2. Is there a C++ optimizing compiler which I should be using which allows access to 128 MB of physical RAM? Is there a C++ optimizing compiler running under Unix or OpenNT which I should be using?

3. Are there programmers out there who have had similar experiences and have some advice for me?

Hopefully,

John L. Gammel
gammeljl@slu.edu

My ignorance of such problems is profound, but I can essay a guess or two. First, I suspect you are tangling with limitations intrinsic to the Windows environment. It may be hard to outsmart the VM logic and get fast in-memory execution of large programs. For this reason, a simpler OS such as Linux may well give you the operating environment you desire. Given that you need to save hundreds or thousands of hours of compute time, it can be well worth your while to shift tool sets and cultures to get it. But I do hope more knowledgable readers will also give you more concrete, and more accurate, advice. Good luck. — pjp

Editor,

The article, "A Simple Windows Icon Viewer" on page 63 of the October 1997 issue "outlines a prototype for more elaborate utilities." A much simpler way to view icons is available to Windows NT 4.0 Explorer users. Using Regedit, change the value of the registry key:

HKEY_CLASSES_ROOT\Paint.Picture\
    DefaultIcon

from (Default) to %1 (a percent sign and the number one). (With Regedt32 the value name is <NO NAME>) This tip comes from a Windows Magazine tip last year. You may have to reboot, but then you will be able to see your directory of icons as "icons" when using the Explorer. (This won't work with File Manager.) This should work for Windows 95 Explorer users as well.

Thank you for a super magazine. I have subscribed for almost a decade now. Keep up the good work.

Toby Popenfoose
tpopenfoose@juno.com

Thanks for the tip. The article was aimed at people who want to play with icons from within a C/C++ program. — pjp

Dear Mr. Plauger,

Most of what I know about STL is thanks to you and your series of columns in C/C++ Users Journal. I appreciate that very much and frankly, you can keep talking about it and I'll never get tired of it. STL is great.

I'm a relative newcomer to C++ and I have a basic question. I'm using STL packaged with VC++ 5.0. Since you rewrote the version I'm using I figured you'd be the person to ask. I'm creating object pointers in a loop and sticking them in a list, say for instance a point:

#include <list>
#define MAXPOINTS 10
#typedef list<Point*> POINTLIST;

POINTLIST pointlist;
somefunction( )
{
    for(i=0; i < MAXPOINTS; i++)
    {
        Point * pPt = new Point;
        pointlist.push_back(pPt);
    }
//use pointlist in some way
                
    pointlist.clear( );
    } //end of somefunction

So my question is this: Do the point objects get their destructors called or is this a memory leak? That is, do I need to do something like this:

POINTLIST::iterator iter;

Point pPt; //point pointer
for(iter = pointlist.begin( );
 iter != pointlist.end( );
    iter++)
{   pPt = *iter;
    delete pPt;
}
pointlist.clear( );
}

I remember seeing references in the documentation to destructor calls made within the template definition somewhere. But I really don't get the picture. Could you elaborate for me?

With Much Appreciation,

Dick Dickerson
Epoch Well Logging, Inc.

You have created a container of pointers, not the objects themselves. Destructors do get called when the container dies, but for the pointers, not for the objects. (A pointer destructor does nothing.) So you will have a memory leak unless you destroy the objects yourself. — pjp