Title: Members' Experiences

I've been using C++ Builder for several months now, since we decided that only a few of our customers were still using Windows 3.xx, and therefore we could afford to move to 32-bit Windows. In that time I've ported one application, with enhancements, and nearly completed two other ports - all from Delphi 1. I've also knocked up a few quick utilities from scratch.

Being able to move to a C++ based Windows development system was something of a relief for me. Since I was writing the server code to run under Unix in C++ and the client end in Delphi (a Pascal derivative), the nearly, but not quite, similarity of the syntax was driving me spare!

Don't get me wrong - I have nothing against Delphi. Quite to the contrary. When I started using it a couple of years ago it cut the time to write Windows applications from months down to weeks. It was the most productivity enhancing tool I had ever used. However, given that C++ is my language of choice, I would have preferred to use it throughout. I was very happy when C++ Builder 1 was announced, but much less happy when it turned up and proved to be 32-bit only.

Borland, like many other companies at that time had fallen for the Microsoft Windows 95 hype and had produced tools that only gave 32-bit code on the assumption that 'everyone' would immediately upgrade. Many people didn't upgrade, of course, and that left those who'd committed to 32-bit only with egg on their faces.

If you are a Delphi programmer, then it is unlikely you will have many problems with C++ Builder, since you will already be aware of the differences between the way Delphi works and the way in which C++ works. If you don't have any familiarity with Delphi then you could have some problems using C++ Builder.

Borland have chosen to use the Delphi Visual Component Library (VCL) with C++ Builder, rather than re-write it from scratch. I've seen lots of reasons given for this by Delphi apologists - including such gems as 'Using the extant Delphi VCL means that C++ Builder users will always have an up-to-date version of the library.'! I suspect the real reason was one of the sheer cost and time of re-writing the VCL in C++.

Frankly, I think if Borland are going to continue with C++ Builder then sooner or later - probably sooner - they are going to have to bite the bullet and do the conversion. The use of the Delphi VCL not only causes problems for non-Delphi programmers, and makes people wonder just how deep Borland's commitment to Builder is, but it makes the whole development system feel like a complete bodge.

This feeling of Borland not being fully committed is exacerbated by their cavalier treatment of the STL. Although Builder comes with Rouge Wave's excellent implementation of the STL, there is no integrated help for it, and the documentation is not installed by the program installer - you have to copy it manually! And I keep finding bits of the help where the function definition is still in Pascal rather than C++.

So... do I think, then, that Borland C++ Builder is a dead loss?

No, not at all. It has a lot of potential if Borland can get its act together and have this mess sorted out by their C/C++ compiler group. Even as it is, the tool is well worth using provided a few elementary precautions are taken - all of which are good programming practice anyway.

The key to using C++ Builder effectively is to separate the data you are manipulating from its representation on the screen. Use the VCL to handle screen display - its ability to do that sort of thing easily is pure magic - and use C++ data structures to handle and manipulate the data.

Doing it this way has many advantages. In the unlikely event of Borland going bust or dropping the product it will make porting it to another system much easier. It avoids mixing C++ style data and functions with VCL Delphi style structures. And best of all it makes for much easier maintenance and upgrade programming. Keeping data and its screen representation separate is one of the axioms of good programming anyway, even though all too few programmers do so.

You can easily - all too easily - add your data into the VCL's classes, but if you do so you will sooner or later be bitten by the subtle differences between Delphi classes and VCL classes. Borland have done their best to paper over the cracks, but really all they have done is to push the differences down a level where they are more difficult to spot, and the resulting bugs are more subtle.

From the point of view of a C++ programmer the Delphi language has a number of defects. The main ones are in the fields of class constructors/destructors, containers, and data hiding. There are other niggling irritations, class properties don't return references so you can't use constructs of the forms 'a = b = c = d = 0', the language is case insensitive, virtual functions have unexpected differences and static variables are called typed constants! But really these are only language differences, and are not a legitimate reason to quibble^[1].

In Delphi, base class constructors have to be explicitly called from within the class constructor, and those destructors are not automatically called when a class instance goes out of scope. This is very different from C++ where such matters are handled by the compiler. This is an area where the Borland folks have tried to make the VCL more C++ compliant with automatic constructors and destructors, but I have to say that I still feel a bit queasy about it.

Delphi really only has one container - a generic container called TList. There is no documentation about the performance characteristics of TList so only trial and error will tell if it is fast enough for your application. Even worse TList only accepts generic pointers to class TObject. (In Delphi all classes are derived from a single base class called TObject) This means that when you retrieve an object from a TList you have to cast it back to the original. Not really very type-safe. An additional complication is that nowhere in the documentation could I find out whether when you put an object into a TList you continue to own it, or whether the TList now owns it and is responsible for object destruction...

As an aside, I would like to comment that the quality of Borland documentation has gone from excellent to completely abysmal in the last five years. The only thing that can be said is that few other companies in the field have done any better.

The final major problem from my point of view is that every time you create a new form (a Windows window) Delphi puts an instance of it into the global namespace! Having made the form available everywhere within the program, it then goes on to make all the components of the form - list boxes, buttons etc. - public data members of the form, so that anyone can play with the bits.

I almost think this warrants a new term for strewing your data all over the global namespace - data disclosing, perhaps. There isn't much you can do about this problem, it's there, and you just have to work with it.

These problems tend to bleed over into C++ Builder because of the non-native nature of the VCL, but, as I mentioned earlier you can minimise them by a regime of strict separation of data and display.

In particular...

Don't put your data variables into VCL derived classes - set up a matching C++ class and keep them there. When you want to display a value tell the VCL what to display.

Do manipulate your data in your C++ class, not in the VCL class that you are using to display it.

Don't use the seductively simple looking TList VCL class, it's an ill-documented minefield. Use the STL which is type-safe and will keep proper information about what it is storing.

Do use the VCL for what it is brilliant at - simply and efficiently handling the intricacies of Windows screen management and manipulation.

If you keep to these simple rules you will be able to get the maximum utility out of C++ Builder and a sizeable productivity boost. You will also get a lot more enjoyment out of your programming, because you can concentrate on the essentials rather than how you get your data onto the screen.

The choice of an editor is an immensely personal thing, but that is not a reason to avoid discussing them or experiences with them. So, prompted by Silas's comments in the last CVu regarding Software Experiences...

I too used Programmer's File Editor (PFE) for a while for two main reasons:

Eventually I came across an editor called UltraEdit32, it was shareware ($30 - an excellent and affordable price!) written by Ian Mead of IDM with his own web site (http://www.ultraedit.com/). In short I was sufficiently impressed with this editor following a shareware evaluation period that I bought it. The sort of functionality that it gives includes:

Of course there are lots of other features such as a function list, using F8 I can get a list of function headers and then quickly navigate to that point. Tags - don't know :-) I haven't used them yet. Compare two files, conversion functions, formatting functions, support for the concept of a Workspace (project) and related files and favourite files for frequently used ones. Hex editing, word-wrapping, bookmarks, spell checking, word count... and the list goes on.

If you are thinking of changing your editor, or want to try out some of those that are available, add this to your shortlist of candidates, I am very happy with this editor - happy enough to pay personal money for it.

Members who develop on remote Unix machines are probably too familiar with the problems of bad telnet clients. I used Windows NT's built-in client for some time, putting up with its limitations - having to remember to press Delete instead of Backspace, and put up with the screen not updating properly in programs like 'emacs' and 'man' on some servers - because every other downloadable client I could find (Easyterm, Netterm etc) did not allow me to change the fonts and colours enough. Many scaled the font to the window size, which is too bad if you want the window bigger than the screen. I am mentioning this because fully sighted readers may run into similar problems if they are trying to display larger-than-usual text on a laptop, sub-notebook, or whatever.

Recently someone here needed a Japanese-capable telnet client, and by searching the Web I found TeraTerm by T. Te-ra-ni-shi (http://www.vector.co.jp/authors/VA002416/ and I suppose the pun means you pronounce it "telaterm"), which is completely free and is very recent. After going through all the set-up options (which is necessary), I liked it so much that I switched to it myself (using the English mode - it also supports Russian if you want). It supports even the most modern VTxxx terminal types, lets you do what you like with the fonts (and it supports ANSI colour sequences), and you don't have to remember not to use the backspace in emacs. The logging, copy/paste and scroll-back functionality of the default client is still there, and features like macros have been added to it (the scripting language is quite powerful).

There are some simple but good ideas, like automatically opening new windows for new connections and closing when you log out. It can also be used as a serial comms program with various protocols, although there is a little catch that can prevent you from using some of them unless you read the whole help file. The source code is also available for download, and there's an SSL layer but I couldn't get it to work (although this could have been the servers' fault; I don't think SSH and SSL is the same thing, which would explain it).

Remote Unix development is also likely to encounter X windows. This is a standard that allows an application running on one machine to display a GUI interface on another, and is OS-independent, but is most often found in the Unix world. The first counter-intuitive thing to realise is that the "X server" is the machine you sit at, that displays the GUI, and "X clients" are programs that run remotely and use the server to draw their graphics. Failure to realise this at an early stage (because as a user you're used to being a client and logging in to a server) can lead to much confusion. A server can offer multiple displays (although this is rare), and clients from more than one machine can connect to the same server.

One very nice thing about X windows is that the window manager is completely replaceable (you can load any window manager you want) and usually very customisable. Even if you are not disabled, you may find yourself wishing that your GUI worked in a different way (like allowing you to move a window without needing to find its title bar and thus allowing them to be pushed partly off the top of the screen), and such things are no problem with X windows (if you know how to configure it or know someone who does). Perhaps the first thing you'd want to do is get rid of the awful headache-making chequered background that so many X servers have as the default. The default window manager behaviour of focusing any window that is under the mouse (but not raising it) can be very useful once you are used to it.

The free versions of Unix running on PCs (Linux, FreeBSD etc) come with a free X server called XFree86 (www.xfree86.org). This can run in a low-resolution mode and use spare video memory for a "virtual desktop" that can be dragged around with the mouse (I haven't yet worked out a way of getting it to follow the text cursor too, like screen magnification software does), and it is fast, smooth and responsive - none of the other servers I tried were anywhere near as nice. There is a DOS port of XFree86 (lost the URL and can't find on a search, sorry), but I couldn't get this to work under 32-bit Windows. But if you have a free Unix, you don't need a very fast PC to give you that "everything you do happens instantly" feel that seems so absent in the products of a well-known software company. (As with 32-bit Windows, though, you do need at least a 386. I have not yet had success in compiling the Embeddable Linux Kernel Subset for a 286 at home.)

The said software company recently made a donation to the university I am in, and this resulted in most of the Linux-capable machines being replaced by Windows NT machines, with the few remaining ones on their way out (Does anyone else find this deeply disturbing? Francis). Running Windows NT in a university network requires strong security measures (in particular, preventing access to the registry), which prevents people like me from doing much customisation. Because of this, the computing service has set up one machine in a lower resolution screen mode for the occasions when I need to use a lab machine (although I'm too shy to throw people off if it's in use). Unfortunately the X server that the university has, Hummingbird Exceed 6, somehow fails to load on that configuration. Otherwise it is a reasonable server with many configurable features, supporting either a virtual screen (although crucially I couldn't get the panning to work) or native windows, XDMCP host menus (so you don't have to make a separate telnet connection to a machine to launch client programs), lots of security features, the ability to print the X clipboard and copy between Windows and X clipboards, and so on.

MI/X is a completely free X server for 32-bit Windows and Macintosh, although the Windows version follows the old X11R5 standard rather than X11R6 (so some programs might not be able to run on it). I tried it and found it to be inadequate for most purposes. Frankly, it is too slow. Screen redraws take ages so if you have to scroll a lot then you can forget it. In addition, there is a known bug that, when you move the mouse over items in a menu, they disappear. Also on the annoyance list is the repositioning of the mouse pointer during the loading process (just when I'm in the middle of launching the telnet client the cursor disappears and I have to find where it went), and the taskbar clock not updating while the server window is active (I was late for a lecture because of this). More importantly, there is no support for a virtual desktop larger than the screen, there is no emulation of a third button on two-button mice (you can of course configure the window manager to only use two buttons, but some applications still require three), and there is no interaction between the X clipboard and the Windows clipboard, so you have to re-type everything to transfer data from one to the other (and at my size that means switch to one window, memorise as much as you can, and switch to the other - X-like focusing without raising would be better). Also of concern to some is there is no security - anybody on the Internet can open a window on your machine without your permission.

MI/X was written to run Microimages' products and therefore any feature that those products do not use is given a very low priority. It doesn't seem to be maintained anymore anyway. It comes with a local window manager but you'd probably want to run a better window manager remotely. It is available at http://www.microimages.com/freestuff/mix/. Another failure I tried was a 30-day trial of WinTED. It gives you multiple desktops (by minimising windows and hiding them from the taskbar) and navigation keys, and is also supposed to act as an X server and even run Unix binaries locally. However, these latter two components are not included in the trial version, so how people are supposed to evaluate it I have no idea.

The evaluation version of StarNet Micros' X-Win32 server (http://www.starnet.com/) lets you have only two hours at a time, but more limiting is the fact that it scans the network at regular intervals and closes if it finds anybody else using the evaluation version. It just so happened that somebody in this university was doing so rather a lot so I eventually did my evaluation at 5am. It uses Windows to do the window managing (so they look native) and has full clipboard interaction, along with some interesting extras such as sound (although I didn't try this). But an annoyance (besides the thing about scanning the network) is it insists that you have a US keyboard, so quotes and @ are swapped for example, but more to the point the vertical bar (almost essential in Unix) is unavailable, including if you press Alt Gr and the key to the left of the 1. There seems to be no way around this.

Finally, I tried AstecX, http://www.astec.co.jp/ENGLISH/ASTECX/ (and they have a Japanese-capable version too). It can either use the window manager you load or use Windows to do the managing, and you can double-click an icon in the tray to toggle the desktop between the X desktop (called the "root window") and Windows' desktop. All windows are visible from both desktops, although the X windows do not show up in the taskbar or the Alt-tab list when your own window manager is running (but there is a "Bring all to front" option on the tray icon's menu). The X windows integrate quite seamlessly with your native windows, and still behave as they are managed by the remote window manager of your choice. There is also a full screen mode and a virtual screen mode, with fairly reasonable panning (although not too good - I have been spoilt by XFree86). There are many features (including security options and the ability to use TrueType fonts - very nice) and full interaction with the Windows clipboard. Unfortunately the evaluation version runs out on 31st December 1998, and that is hard-coded into the program; the commercial version is ridiculously expensive unless you're a company. Perhaps they will release another evaluation version in the new year.

The names of things can be very important because they create expectations. I think this particular product is unfortunately named because it creates (at least for me) expectations that it has no intention of meeting.

Fundamentally this package provides an excellent set of profiling tools. What it does not do is to analyse any other aspects of you executable, nor any aspect of your source code.

Profiling is very important because it gives the programmer information about the bottlenecks where time can be profitably spent in tweaking code or considering alternative data-structures and algorithms.

Inserting extra code by hand can help but that code distorts the running of the executable. This product provides tools that will instrument your source code and then run the instrumented result without, Metrowerks claims, changing the running of your code.

While the above claim is substantially carried out, experienced programmers will quickly realise that you would have a miracle product if such a claim were met fully. As soon as you have optimisers inlining code together with virtual memory and different levels of caching the instrumentation is going to change some of the performance behaviour of the code.

It is very difficult (probably impossible) to measure the degree to which instrumentation changes code behaviour. Certainly this package measures the performance of your code rather than the combined performance of your code and the instrumentation but I am far from sure about the subtler performance changes. Perhaps these do not matter very often, because you are looking for bottlenecks and the behaviour of critical performance sections. Certainly CodeWarrior Analysis Tools will be of great assistance in such a search.

In practice, there are other aspects of my executable that I would prefer to have tools to check. In most cases I would spend my money on tools to track resource leakage, one beyond the end errors etc. before being worried about in depth profiling in multi-tasking environments. If the latter is what you are looking for, then this product will meet your needs, but just that and no more.

In conclusion, this product is a well designed and very smooth set of tools for active profiling of code (including DLLs from third parties) running in modern multi-tasking environments.

Another instalment turned up in my mail box

1st January 2000: They must have had some unforeseen Y2K glitch in the power distribution network, and although the phones are supposed to be up (at least for national calls) my system won't let me communicate without mains power. Must upgrade to solar or something. I had a break-in and the security system didn't go off; they didn't take anything - didn't seem to be interested in hi-tech electronic stuff. At least we didn't get too much public panic in the run-up to this - that could have been a lot worse, and the economy wouldn't have been good enough for me to get this digital house which would have made me very depressed.

7th January 2000: Still no power. What, haven't they managed to fix it yet? You would have thought they'd know exactly which embedded systems have gone wrong by now. Although they might take a whole month to fix it - oh dear, don't know what to do, haven't even got a solar powered battery charger. My UPS only lasted five minutes. There's been a water shortage for days - you'd have thought the reservoirs would have backup generators, but not in these parts. And they tell you to boil water at the bottom of reservoirs. Like how? I'm 100% electric here. Fortunately the place is well insulated and in the country (no riots etc to worry about).

8th January 1972: I managed to rig up a generator! I got the car engine (fortunately it didn't have any computer control with glitches) and idled it, then got my screwdriver out and started tinkering with the PSU of the computer to get it to run on low voltage. Pity I can't run all the appliances though. The computer itself turned out to be compliant, but the home control software wasn't. You'd have thought they'd have got it right by now. So I had to set all the clocks back and age the data. Now I must remember to add and subtract the right number of years. Not sure what happens when I log on to the Internet - s'pose I'd better program a patch or two.

9th January 2000: Ran out of petrol. Have been drinking filtered rainwater. Just as well the weather's wet. I must find another power source for that engine - it could be weeks before the power's back up. I heard locally that the water people have nearly managed to get backup generators but have distribution problems. Shouldn't be too long. Meanwhile I'm so desperate I think I'll run a cable over and steal some of their electricity. I hope it doesn't impair everyone's water too much. And I'm feeling rather hungry - food ran out ages ago and I can't get anywhere. Just as well it didn't run out with public panic in 1999.

14th January 1972: They managed to get the power back on! It's not on 24 hours a day, though. There isn't enough power for the whole country so they're rotating region by region. I hope not too many people were in intensive care through that fortnight. So time to log on. It looks like most of the world is reachable through the Internet somehow, though it's not nearly so fast. Pity I can't get through to wherever I want to go. I thought the Internet was slow before but now... And my packets keep being returned with "TTL expired" on them. I don't know how to set the TTL (the maximum number of hops a packet can travel before being returned) to more than 30, and because the Internet is in such a mess at the moment, most places, although they may be reachable, aren't reachable because of the TTL expiry. [Any readers like to comment on this?]

17th January 1972: Still really hungry. At least I was well fed before and am still going. The Internet should be able to help me, but there's this awful TTL thing. Most of the problem seems to be that power's still down in most of the US, where all the big backbones are - the ones that were supposed to be compliant. And I have some international contacts and I want to know how various countries are doing - but it takes a lot more than 30 hops to get from the UK to Asia-Pacific without going through the US. But I managed to place food orders on some UK sites. Don't know if anything will happen though. They might have distribution problems. At least my bank account seems OK - the bank did have a glitch, but once they knew exactly what was wrong they fixed it and restored a backup. Don't know what the value of money is these days though. At least we're not being invaded by anyone. And at least my ISP was OK. I should have got accounts on several, just in case.

1st February 1972: Distribution now seems to be taking shape, although things are still scarce. Rations are available, but I hope it doesn't stay like this for long.

14th February 1990: Things are now getting more or less back to normal, and I'm managing to get to more places on the Internet easier. Now, where was I? Ah yes, beta testing the new house operating system. Unfortunately it crashed with the year set to 1972 because it can't represent that. So I set it to 1990 (I'll just have to put up with the days of the week being wrong for a while) and re-aged all the data. Took some doing, especially with the day of the week thing. Then I realised it might actually be compliant. I'll try it tomorrow.

15th February 2000: The new OS works fine. I hope the 29th doesn't throw it. I must say it seems remarkably stable for a beta copy. But then, I haven't REALLY started testing it yet....

Contributed by Silas S. Brown <ssb22@cam.ac.uk>