|
Be Newsletter
Issue 72, May 7, 1997
Table of Contents
BE ENGINEERING INSIGHTS: An Obscure Pitfall of C++
By Mani Varadarajan
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.
In Pursuit of Support
By Ed Romson
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.
News from the Front
By William Adams
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:
A) Stepping up to the altar
B) Taking final exams in your Freshman year
C) Preparing for your first date
D) Making your last-minute changes for DR9
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.
Nerves
By Jean-Louis Gassée
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.
|
