By Reg. Charney
The following simplified program cost me hours of debugging. What surprised me in solving it out was how common the bugs were. See if you can find the errors quicker than I did. (Note: In these simplified C++ examples, struct was used to eliminate access issues.)
| int g = 1; void f(struct S s, int *pi); struct S { int *pi; char c; }; void f(struct S _s, int *_pi) { _s.c = 'z'; _s.pi = _pi; } int main() { static int a = 2; auto int b = 3; S s(3,'x'); S t = s; s.c = 'a'; s.pi = &g; f(s, &g); f(s, &a); f(s, &b); return 0; } Listing #1 – No member functions |
Listing #1 was a preliminary design. It compiles successfully, but contains a semantic error. In struct S there is a pointer, but no explicit copy constructor or assignment operator. The compiler generated default constructors and assignment operator, all of which did a “shallow” copy or assignment. (A “shallow” copy is one where the pointers are copied, not the values the pointers are addressing.) Also, for simplicity sake, no assignments were used in this example, and thus no assignment operator needed to be defined. Also note that in Listing #1, when initializing t, the copy constructor was used, not the assignment operator.
While this example ran successfully, it was obvious wrong. The call by value of f() created a second instance of struct S. Both instances of S.pi pointed at the same memory. This is not the usual intent when passing by value. To correct for this, I added a copy constructor – and then my real problems began!
| int g = 1; void f(struct S s, int *pi); struct S { int *pi; char c; S() : c(‘\0’), pi(0) { } S(int i,char _c) : c(_c) { pi = new int(i); } S(const S& s) : c(s.c) { pi = new int(*s.pi); } ~S() { delete pi; } }; void f(struct S s, int *pi) { s.c = 'z'; s.pi = pi; } int main() { static int a = 2; auto int b = 3; S s(3,'x'); s.c = 'a'; s.pi = &g; f(s, &g); f(s, &a); f(s, &b); return 0; } Listing #2 – Defined Member functions |
The program in Listing #2 crashed whenever f() was invoked. This article was prompted by the question of why. Can you see it?
In calling f(), the address of static or stack variables (a, b, and g) were passed. These addresses overwrote the values in s.pi. In calling ~S(), an attempt was made to delete the storage pointed at by pi. But, the storage for these variables was not allocated by new. Thus, issuing delete to free the storage was invalid and, depending on the environment, caused strange things to happen.
It might appear that this example is contrived. However, I have found many instances where global and local storage has been mixed and used in a manner similar to this example. The result has been unpredictable behavior and many hours of productive time lost.
by John Merrells, merrells_AT_acm.org
SOAP, the “Simple Object Access Protocol”, is a proposal for how RPC calls can be made over the HTTP protocol using XML as its encoding mechanism. The acronym was chosen more for its amusement value than for its meaning. The “Object” word isn't operative. Just think RPC over a text based protocol.
Corporations require high reliability and massive scalability from the applications that drive their enterprise. Distributing the composite software components across many machines provides these system qualities. But, building distributed systems from scratch is a task best left to rocket scientists. So, there have been a number of distributed computing frameworks developed over the past twenty years. DCE RPC was perhaps the first, and its fundamental concepts became the basis for the distributed object computing platforms: CORBA, DCOM, and Java/RMI. The technology buzzword for this technology is “middleware”.
Each of these middleware technologies has had varying degrees of success within the context of enterprise computing. Since interoperation between the technology islands is troublesome at best, an individual company must decide upon which single technology they will base all their applications.
The explosion in popularity of the public Internet over the past five years was mainly centered around the interaction of Joe User with Mega Corp. and Joe Public with Joe Sixpack, otherwise known by the monikers B2C and C2C. HTML and HTTP were this fire’s fuel.
The current usage expansion is business-to-business interaction, but the participant actors are not humans, they're business applications. Applications reach across the Internet to band together in forming an aggregation of cooperating software components. For example, the purchase of a car involves a vehicle locating service; a financing company; a delivery service; an insurance provider; an extended warranty; and optional car mats. All these providers could support an Internet interface into their applications for access by external applications that need to request quotes, place orders, cancel orders, etc.
The poor interoperability of existing middleware technologies will not support the needs of the B2B Internet.
SOAP provides interoperability between competing middleware technologies, across the Internet. The transport protocol is HTTP, chosen because of its firewall friendly nature. The encoding scheme is XML, the lingua franca for business-to-business interoperability, since text protocols are much simpler for application programmers to deal with. Both these points may seem small, but they will be fundamental to the success of SOAP.
UserLand, Develop Mentor and Microsoft drafted the first SOAP proposal. IBM has endorsed revision 1.1. Sun isn't supporting it, but will eventually have to follow along .
SOAP version 1.1 has been submitted to two standards bodies: the IETF, and the W3C. This means that the software community at large will be contributing to the development of an internationally recognized standard for an XML RPC mechanism over text-based protocols like HTTP and SMTP.
For more information, see:
http://www.develop.com/soap/
http://static.userland.com/xmlRpcCom/soap/SOAPv11.htm
By Reg. Charney
Loyalty is a constant refrain in the give and take of hiring and being hired. No one admits to believing in it, but when push comes to shove, it is expected. The chance to belong is a very real motivator for most people. Thus, I was surprised recently by a contract I saw. It outlines the operating conditions for contractors working at a company with a terrific reputation. It clearly separates those working at the company into two groups: employees and contractors. As expected, employees get all the benefits of employment. What is surprising was the effort made to differentiate the non-employees. It extends from trivial matters to gross strategic mistakes.
First, let me point out that both direct and temporary hires work on the same projects and usually put in comparable hours. For all intents and purposes, their work load is similar and how their performance is judged is the same. This standard seems fair and consistent for both.
However, a two-tier system exists. As a trivial example, temporary employees are not allowed to use the recreational facilities. At a serious strategic level, temporary workers are not considered part of the team and are not allowed to participate in team meetings, even though they may be the lead players or majority of the teams! This makes the concept of a team a hollow parody and destroys the intent of team building which is loyalty – that which carries us together through good times and bad, and smoothes rough waters.
I have no problem with differentiating between direct and temporary workers based on pay versus benefits. That is a choice for individuals to make. But to differentiate team members on the basis of their hiring status is self-defeating to both parties. There is no incentive to give that extra 10% on the part of the temporary worker and the company can expect no loyalty or shared vision when it needs it.
I recognize that tax and employment laws make life more complicated, but it seems that we have allowed non-essential factors to destroy mutually beneficial goals. As a lawyer friend of mine once said, “Never let a lawyer make your business decisions for you.”
ACCent is aimed at programmers interested in Open Source Software and programming languages like C, C++, Java, Python and Perl. It offers three benefits to sponsors: it appeals to a highly focused group of technically capable people; it gives the sponsor good publicity and public relations by associating the sponsor with a well-known and well-respected non-profit organization like the ACCU; and the monthly issues mean that the sponsor gets a form of corporate advertising for the price of sponsorship.
The ACCU is an international non-profit organization aimed at improving the professionalism of its programming members. Its web site is www.accu.org. We currently have about a 1,000 members worldwide and are in the early stages of building a local Silicon Valley chapter, which is one of the reasons for the newsletter. Also, to misquote a politician, "All programming is local." – so our newsletter is published with the needs of Silicon Valley programmers in mind.
There are three levels of annual sponsorship: Gold, Silver and Bronze. The benefits are based on sponsorship level.
Bronze - includes the following five (5) benefits:
Silver - includes the following five (5) benefits:
Gold - includes the following seven (7) benefits:
(*) We currently produce a 6 page newsletter, but will go to 8 pages when we gain sponsors to amortize the cost of the newsletter.
(**) The online version of the newsletter is planned to start with our June 2000 issue.
Contact:
Reginald B. Charney, Editor
1330 Trinity Dr.
Menlo Park, CA 94025
Tel: 650-233-9082
Highly Recommendation ****
Eric details his travels along the way to becoming one of the main spokesmen for the Open Source movement. He describes, in five extended essays, the evolution and reson d’etre for the Open Source Software movement, its culture and its benefits to all concerned. What he talks about is very thought provoking and his reasoning is very compelling. The book can be read by anyone interested in anthropology, nerds, hackers, and why the Open Source movement is making such a big impact on today’s programming environment and tomorrow’s world. Surprisingly, being technically inclined is not necessary.
The five essays are:
A Brief History is about the early culture that gave rise to the Open Source movement and how this lead “geeks” out of the hinterland into the forefront of media attention today. He also differentiates between hackers, a complementary term, and cracker, a pejorative term. Hackers have built and open collaborative environment in which everyone can benefit. [Reviewer: Crackers are the clots who use that freedom and open access to slash and burn, thinking that by destroying other’s work, they gain power. I think of crackers as thieves – stealing from others for their own benefit alone.]
The Cathedral and Bazaar article describes the history of a project which used the Open Source model and the lessons learned from that. One of the main things learned is that “Given enough eyeballs, all bugs are shallow.” This translate into reliability and robustness. Thus, if your life depends on some software, or your business depends on a critical application, you want as many people as possible reviewing it for reliability and functionality. This is what Open Source is all about.
Homesteading the Noosphere comes from the Greek, noo-, for knowledge. In this part of the book, Eric talks about ideology and the “gift culture” that pervades hackerdom and its implications for who does what, the concept of ownership, conflict and conflict resolution, and the implications for self-organization.
The Magic Cauldron essay speaks about the economic underpinnings of the Open Source movement. Eric describes nine economic models which a business can use to survive and grow. Along the way, is clearly defines the difference between sale value and use value. In particular, the value of most of today’s software is in its use, not its sale value. For example, most companies have programming staff to develop applications for in-house use, not for sale to outside entities. Thus, people are paid to write software for internal use, not paid based on the sale value of the software. The implications of this include the debunking of the myth that producing software is a manufacturing process whose final value is the finished good. In reality, the continued maintenance and use of the software is where the value lies. This clarity in defining what make software valuable is one of the most important aspects of this book.
The last essay in the book is The Revenge of the Hackers. Eric describes the Open Source Software’s eruption on the scene in 1998 and the continued effort to promote its benefits and its implications. He then predicts the growth trends in software development, the efforts being made to stop this growth by Microsoft and some others, and the inevitability of Open Source’s success.
For you who are not affectionados of dictionaries and lexicons, Eric first came to my attention as the editor of The New Hacker’s Dictionary, 3rd Ed. published by MIT Press, ISBN 0-262-68092-0. Also it is a delight to read, if only in snippets. Thus, I was not surprised when I found Eric’s writing style is clear, pleasant, and entertaining in this new book.
The only downside of this book in its printed form is a lack of an index. However, since much of it is on the Web, you can search for what you want there.
Reviewed by Reg. Charney
By Reg. Charney
For the first time in the twelve months that I have been tracking the job market statistics, there has been a significant drop in the number of jobs offered. In the last month, IT job offerings nationwide dropped off 8.6%, while those in Silicon Valley dropped off 10.1%. Charts #1-3 gives us some perspective. Growth in most languages, platforms and technologies has been very positive over the last 12 months.
Figure #1
Figure #2
Figure #3
The dramatic downturn in new jobs being advertised applies across almost all categories, except two – Windows 2000 and XML. However, even here, the rate of employment opportunities has decreased.
Figure #4
Figure #5
Figure #6
Figure #7
Figure #8
Figure #9
Speculation on the downturn will be rampant. However, since the negative turn affects all IT technology sectors nationwide, the stock market downturn probably has a lot to do with the charts that we see here.
One small note: while the number of TCP/IP jobs has decreased in the last 30 days, the rate of decrease is still slightly positive. This indicates that the growth rate of TCP/IP related jobs still out paces the fall off in the last 30 days. Note also that non-Internet related jobs were not nearly as volatile as those related to the Internet.