I've been at Be for close to a year now, and like some of you, my first exposure to C++ was when I started messing around on the BeOS. C++ is without question quite a confusing monstrosity of a language; sometimes I wonder what good ol' Bjarne and his friends in New Jersey were thinking when they included some of the more arcane aspects of the programming language discipline in C++. At any rate, it can't be repeated too often that programmers are well- advised to be very careful when using some of the more unusual features of the language. This is all the more true in a multithreaded environment, where what appears to be a safe way of doing things actually isn't.

Since I'm responsible for maintaining the core libraries for the BeOS, I've gone through quite a bit of C++ code over the past several months. Never has reading code been as daunting a task as when I had to pore through the implementation of the Standard Template Library that was at our disposal. It was even more daunting when I had to narrow down some obscure bugs. Based on this experience, I'd like to discourage a practice that seems somewhat common in the C++ community.

Rule: Don't declare member variables of classes static, if the member variable is of a nonfundamental type.

This lesson may be hard to understand to those who don't violate it, so let me present the following situation. Sometimes you need a flag or counter that is common to all instantiations for a particular class; for example, a flag to indicate that some common initialization for all objects of this class has occurred. Often this flag is also a nonfundamental type, because it has some sort of mutual exclusion built into it, or some such thing.

I've noticed that many programmers are tempted to declare these flags and counters as static, private members of the class, so that only one such object is instantiated for all instantiations of this class itself:

class B {
public:
  B();
  ~B();
}

class A {
public:
  A();
  ~A();
...

private:
  static B flag;
}

static A::flag = 0;

A obj1, obj2;

A::A()
{
  if (A::flag == 0) {
    do blah;
  }

  A::flag++;

  ...
}

Now this is a perfectly fine idea, except that it opens one up to all sorts of nasty race conditions.

What tends to happen is that A::flag will generally be used in the constructor for A itself; after all, the purpose of the flag is to let A's constructor know whether it needs to do any other initialization.

However, notice the circular dependency—the constructor for A depends on B. However, the C++ standard doesn't define an order in which global objects are constructed. A therefore depends on an object that may not yet have been constructed—that is, B—and then all hell breaks loose. The value of the flag is unpredictable; it may or may not be correct at any given time. An identical problem occurs if there's a dependency between destructors.

This wouldn't occur if object B was of a fundamental type, such as int or char, since fundamental types aren't constructed in the canonical C++ sense.

In this type of situation, it's likely that this flag is used in the constructor for the class of which it is a member. Recall that the flag was declared static, meaning that it's actually a global object in its own right.

The solution? Declare the object static and local to the constructor:

class B {
public:
  B();
  ~B();
}

class A {
public:
  A();
  ~A();
...

}

A obj1, obj2;

A::A()
{
  static B flag = 0;

  if (flag == 0) {
    do blah;
  }

  flag++;

  ...
}

Now everything's fine. And as a side benefit, the code's even easier to understand.

To start off, please allow me to introduce myself. I'm Ed Romson and I'm the new (three months) Director of Customer Support here at Be. My bio is on the Web site, so I'll forego any repetition of that except to say that I'm a recent escapee from Apple (after twelve and a half years) and have been the support business for about fifteen years.

I'd like to do two things in this short missive. First, I'd like to give you an update on those things that have been keeping us busy on the nonengineering side of the company. And second, I'd like guide you on the path to Support Enlightenment.

The status report first. With the Preview Release looming (no announcements in MY column), we're working to have all of the operational aspects of the business in place for that magic day when Mel yells "Ship it!!" To do this, we've worked through bidding processes for technical support (Net and phone), printing, disk duplication, order taking (Net and phone), and distribution. We've picked the vendors who will supply us with all of these aspects of Customer Support here in the US. We're also working with Jean Calmon and the Be Europe office to settle the details on that side of the pond. My commitment at the weekly Be Office Gathering has been "We'll be ready when you are." We're on track to do just that.

In future Be Newsletter articles and at the Developers Conference (have you updated your information yet?), we'll be sharing some thoughts with you about support and showing you how we've designed our support structure in a way that it can be extended to help developers address some of their customer service and support worries. Stay tuned.

Our support philosophy starts with providing as much information as possible to you via the Web and other electronic means. We'll make this information easy to find and, through the use of the latest technology, help developers and end users be self supporting. We've been investigating case-based reasoning and other tools and technologies to make a Web search quick, easy, and maybe even enjoyable. Watch our site as we evolve and give us feedback.

The place to start for support of any kind is the Be Web site, http://www.be.com. There you'll find a wealth of Frequently Asked Questions (FAQs), sample code, manuals, and updates. We have tutorials, we have code fragments, we have announcements, and we even have support documentation in Japanese!

If the information you require isn't there, you'll also find a BeAssisted form you can use to submit questions to any of the support e-mail addresses. If you hate Web forms, a generic e-mail to any of the support addresses will be welcomed. Please help us help you by giving us as much information about the problem as possible, including the configuration of your system, what you were doing, what happened, what you expected to have happen, why, and anything else about your configuration and problem that you think we should know.

Here is a list of the support addresses and their uses:

• CustSupport@be.com - for questions regarding set up, installation, configuration, and compatibility of the BeOS, BeBox, or other technical questions that are not about programming or coding.

• CustServices@be.com - for assistance obtaining any of our products or for questions about maintenance and warranty of a BeBox.

• DevServices@be.com - available to developers with developer-specific, nontechnical issues including lost developer passwords, changing name or company information in the developer database, moving files in the BeWare section, and the like.

If all of this Web searching and e-mail doesn't do the trick and you'd rather talk to a human, you can call us. We'll be available Monday through Friday, between 6am and 6pm (Pacific time) for people in the Western Hemisphere, and between 8am to 6pm GMT for those of you in the Eastern Hemisphere. Our Customer Technical Support numbers will be activated on June 15 in the US and July 15 in Europe. We'll publish them (you guessed it) on our Web site at http://www.be.com/support/index.html.

Several years ago, Mayor Koch of New York had a habit of walking up to people and asking, "How'm I doing?" Regardless of what you think of the ol' Mayor, he did get information about what was happening in the Big Apple. I'd like to do the same, electronically. I know you're not shy about sharing your thoughts (I read comp.sys.be.misc and BeDevTalk religiously), but how about sharing some thoughts on the state of Be technical support? What companies do think provide the best Web-based support? Are there things in the support arena we could be doing, bits and pieces we could provide, to make your life easier?

How're we doing? It's Romson@be.com.

George Hoffman's back!
I won the Lottery, speaking of which...

Your heart is racing, you can't remember the last time you slept, ate, stood up, or blinked. Your knuckles are white, your hair is graying more by the second. Perspiration is sprinkled on your forehead. Your eyes feel like they've had sandpaper rubbed across them. Did you actually do that, or was it your imagination. Your heart is pounding, and you have a deep feeling of imminent success.

Does this scenario relate to:

Software development is many things to many people. For me, it's always been a passion, never a job. Why would you do something you don't enjoy? And if you enjoy it, why not enjoy it thoroughly. As you read these words, you're in an environment that obviously has a computer. If you're lucky, you're on the beach or another outdoor setting, with a portable computer in your hands. If you're more normal, you're probably in a cubicle, office, or at your desk at home. No matter what your situation, you can only hope to experience the sheer and utter joy of reaching a much anticipated software release with your kidneys, heart, hair, and hands intact. At Be we try to under promise and over deliver. When a release has been as long in coming as DR9, it's often hard to meet expectations, no matter how well we set them. I've recently been porting a lot of code to DR9, as well as creating new apps. If you've ever done much porting work, you know that it can be both frustrating and rewarding. You probably ported something from the Mac OS, Windows, or UNIX to get to the BeOS in the first place. Moving from DR8 to the BeOS Preview Release (what we've been calling "DR9") won't be such a great transition, more of an evolution.

Over the past few months, many of the Be engineers have shared bits and pieces of the coming BeOS Preview Release in this newsletter. You'll soon see the fruits of their labors. And sample apps. As one engineer put it, there's no better documentation than sample code. We have some, and there will be more on the way as soon as the baby's out the door.

One thing to pay attention to with the BeOS release that comes at the Developers Conference is that it's a developer's pre-Preview Release -- in fact, we're calling it the Advanced Access BeOS Preview Release. That is, at the Developers Conference we'll be giving out a release that won't have wide distribution beyond the developer community. You'll have a chance to port or write new code before the BeOS Preview Release goes out to the masses. In that respect you'll have an opportunity to actually have products available when the Preview Release shows up in the hands of the Power Computing and other customers who have been anxiously awaiting it, and your apps.

There are many changes in the Preview Release. As mentioned previously, there's much tighter C++ usage. Our use of the language is making for a much more stable and well-behaved system. There will be subtleties though. We'll try to point them out where they exist, and of course provide as many samples as possible.

Our Developers Conference is this weekend, but I managed to get sick last week, so I won't have that in the way. We even managed to give Yasmin a good birthday party, and take her on a 30-mile bike ride. Not bad for a two-year-old and a sick daddy.

Well, Dr. Nine is upon us. I think you'll enjoy it. See you at the conference.

In normal times—if there is such thing for a start-up such as ours -- we could be expected to be a little nervous before a Developers Conference. Add a major release, our most important so far, to the formula, and you have an event laying outside the usual scale. So we're more than a little agitated. We're presenting ourselves before a jury of our peers, software developers whose judgment will determine the fate of the BeOS, the future of our company. This sounds a little too stiff and, fortunately, the metaphor quickly breaks down. There aren't too many lawyers in the room, the dress code is better, and the jury isn't sequestered. But court metaphor or not, this is an important milestone in our relationship with application developers. We're going to be tested and compared.

The dust has settled on last year's discussions with Apple, so this time we're going to be evaluated on our "unconnected" merits. Inevitably, we're also going to be compared to Apple's upcoming Rhapsody. The situation will feature one (temporary) irony: Apple intends to distribute free OpenStep CDs running only on WinTel platforms at their developers conference, immediately following ours. There will be one more bias in the comparison: We'll be compared to the old OpenStep environment, not to the new composite Apple is developing, blending OpenStep and Mac features. Nonetheless, we expect the comparison to be useful in reaffirming our respective positions in the PowerPC family.

OpenStep developed a following in enterprise applications. We target new-media content developers. See Mark Gonzales' Media OS white paper, which will be unveiled on our Web site this weekend for the conference. Or refer to http://www.be.com/developers/whybedev/index.html, the "Designed for the Next Decade" paper describing our technical and business goals. I don't expect Apple executives to agree wholeheartedly with my characterization of the respective roles the two OSes can play, and I respect the fact that they must promote their emerging blend of OpenStep and Mac as having the broadest of appeals. As stated earlier, developers are the judges—followed by customers. And focusing more creative energy on the PowerPC benefits us all, just as robust Power Mac compatibles from Power Computing, Motorola, UMAX, and others bring new energy to the erstwhile hardware monopoly.

Back to the BeOS itself, we're more nervous than we've ever been. This release brings more change than in any prior release. As a result, we need the feedback of software developers more than ever. Even more important than bug reports, we need feedback on the design of the BeOS in order to transform our weakness, our small size, into a strength, the ability to react quickly to suggestion. As I wrote before, we're myopic. Someone taking a fresh look at our work can make the "tractor suggestion." Of course, there will be embarrassing bugs and humiliating oversights. Still, we're very proud of this release, and we—nervously —look forward to this opportunity to show our work to demanding critics.