We have a love/hate relationship with reviews. While we all like reading or seeing movie reviews, we hate doing book reviews. And while code reviews are valuable, we are ambivalent about them because it might be our code that's reviewed and few of us like to be criticized. At the moment, the ACCU can't offer you movies, but we can offer you books and software to review. We can even offer guidelines on doing these reviews. What you need to do is add the active ingredient to this mix - your time and effort. And what do you get for doing this? I am glad you asked.
· You get to see your name both in print and on the Web
· You get national and international exposure.
· You get to develop a reputation as an expert on what you reviewed.
· You get to keep, for free, what you review. If you where interested in the subject anyway, this is a painless way of getting it. (Remember, these books usually cost $30-$70 each and software often costs $50-$1,000.)
· Active involvement in the ACCU will give you more leverage in getting: your next job, peer approval, and access to people, places and things.
And, of course, you get the proverbial pat on the back for bettering your fellow members and the programming world.
What's in it for the ACCU and Open Source Software movement? Your involvement makes us one the most active organizations in the world of computing. We will become a source and beacon for all professionals and those aspiring to improve their programming technical skills. Other organizations will want to work with us. We will be fulfilling our purpose with a vengeance.So, review this opportunity and contact me. We have the books and software available. Our web site will list those by the time you see this issue of our newsletter.
To quote Shakespeare, we are hoping that "A rose is still a rose by any other name". While ACCU'SiVe had a derivation (ACCU of Silicon Valley) and was pronounceable, it has no pizzazz nor is it meaningful to the uninitiated. Thus, we are looking for a catchier name. Current favorites include ACCUte, ACCUrate, and ACC++ent. Let us know which you prefer, or if you have a better name. There is a terrific prize worth what I paid for it to the winner, plus an honorable or dishonorable mention, as desired. And remember, your name will appear forever at the top of our newsletter - talk about immortality!
To facilitate printing in one color, some changes have been made to the printed layout.
Besides providing ACCU with meeting space, Computer Literacy is also sponsoring the printing of ACCU’SiVe. Thanks Computer Literacy – you’re great!
Last month we talked about the demand for various programming languages. This month’s column shows the current demands in Figures #1 and #2, but I have also included the change in demand by language.
Figure #1: Seven Month Demand Trend - Languages
The normalized demand for languages in Figure #2 shows that the demand for Java now slightly outstrips the demand for both C and C++.
Figure #2: Normalized Demand by Languages
Figure #3 shows the demand for C++, Java, and Perl has continued to accelerate while the demand for HTML and VB has declined in the last month.
Figure #3: Change in Demand by Languages in Last 30 Days
Silicon Valley still maintains its uniqueness with respect to employment.
The percentage of software engineering jobs increased from 25% to 37% of the 180,000+ technical jobs listed. Of these software-engineering openings, 66% are in Silicon Valley. Again, this has not changed from last month and continues to show that Silicon Valley firms use the net by a 2:1 margin over the rest of the country.
In the last month or so, I have noticed a lot of books on programming the Linux operating system. Unlike those for programming Windows, all the source code is available and documented. One interesting example is “Open Source Linux Web Programming” by Jones and Batchelor. Done by M&T books. Its ISBN is 0-7645-4619-8.
by Reg. Charney
Given two classes, A and B where there is a conversion constructor from class A
to class B, then:
A a;
B b(a); //explicit convert
In this case, there’s only one instance of both A and B with b using a’s value.
A a;
B b=a; //implicit convert
This format will not work if explicit was specified on the conversion constructor
for B. Also an implicit conversion is treated as if the copy constructor is
called, although it is usually optimized away. An error occurs here if the copy
constructor is private.
Again, we are using the book The Standard C++ Library by Nicolai M. Josuttis, Addison Wesley, ISBN 0-201-37926-0 as our source for this column on smart pointers. The smart pointer implementation in the STL is worth discussing because of its semantics.
First, STL’s auto_ptr are used to prevent resource leaks. Using a normal pointer:
struct X{std::string s;};
void g(string s);
void f(bool b) {
X* p=new X;
if (b) return;
g(p->s);
delete px;
}
This badly written example shows a common resource leak: px is not freed when the argument, b, is false or if g() throws an exception. Using the STL’s auto_ptr type solves this problem:
struct X{std::string s;};
void g(string s);
void f(bool b) {
std::auto_ptr<X>p(new X);
if (b) return;
g(p->s);
}
Also, note that there is no delete since all automatic instances of the class auto_ptr have their destructor called when the process goes out of scope. In turn, this invokes X’s own destructor to free resources allocated to the new instance of X. Thus, even this poorly written code works using auto_ptr. STL’s auto_ptr implements the idea of ownership: only one instance of an object can be owned by an auto_ptr at a time. To accomplish this, certain limitations are imposed – eliminating many possible error sources like pointer arithmetic, auto_ptrs arrays, and initializing with ordinary pointers. This latter limitation forces you to initialize auto_ptr instances with values, not pointers. Thus:
auto_ptr<X> p(new X);// OK
auto_ptr<X> q=new X; // err
When assigning one auto_ptr to an-other, you are really passing ownership from the old to the new auto_ptr. Thus,
X x1, x2;
auto_ptr<X> p1(x1), p2(x2);
p1 = p2; // OK
First, p1’s instance x1 is freed and then p1 is set to p2’s value. Next, p2 gets set to null. This implies that the right hand side in auto_ptr assignment is changed. No copying is done when transferring ownership. Nico’s book also discusses transferring ownership to and from functions. It is interesting and fun reading.