You mislead people. I suggest obtaining minimal understanding of core C++ before composing stories like that. It’s all your violent imagination.

Bad signs in this article:

1) “…load _woInitialized in a register…”
2) “…they don?t know how this function is implemented internally and thus cannot be sure that _woInitialized won?t change between the two if-s…”
3) “…out-of-order instruction execution, coupled with delayed cache writing virtually ensures…”

C++ is a high level language. This kind of thinking (I mean registers, processors and so on) damages the brain of good C++ engineer. Yes, C++ is designed to allow low-level details to be specified in a program: there is “asm” declaration, for example. However, a well-formed program that does not specify that details is guaranteed to behave consistently on any conforming language implementation.

The following quotes from standard should help any judicious person understand what’s wrong:

all quotes are from [intro.execution]

1.9.5
“A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible execution sequences of the corresponding instance of the abstract machine with the same program and the same input… ”

1.9.6
“The observable behavior of the abstract machine is its sequence of reads and writes to volatile data and calls to library I/O functions.”

1.9.7
“Accessing an object designated by a volatile lvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression might produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.”

1.9.8
“Once the execution of a function begins, no expressions from the calling function are evaluated until execution of the called function has completed.”

1.9.11
“The least requirements on a conforming implementation are:
— At sequence points, volatile objects are stable in the sense that previous evaluations are complete and subsequent evaluations have not yet occurred…”

1.9.16
“There is a sequence point at the completion of evaluation of each full-expression.”

1.9.17
“When calling a function (whether or not the function is inline), there is a sequence point after the evaluation of all function arguments (if any) which takes place before execution of any expressions or statements in the function body. There is also a sequence point after the copying of a returned value and before the execution of any expressions outside the function. Several contexts in C++ cause evaluation of a function call, even though no corresponding function call syntax appears in the translation unit. [Example: evaluation of a new expression invokes one or more allocation and constructor functions; see 5.3.4. For another example, invocation of a conversion function (12.3.2) can arise in contexts in which no function call syntax appears. ] The sequence points at function-entry and function-exit (as described above) are features of the function calls as evaluated, whatever the syntax of the expression that calls the function might be.”

Given that bulk of standard text, can you tell what is redundant in author’s solution and what is missing?

#import <c :\\windows\\system32\\hnetcfg.dll> tlbid(3)

…in a project of yours, and do the full compile cycle; then look for the generated .tlh and .tli files - this is whether VC will put in the generated code.

Look up the value between the tlbid() brackets with OleView. Turns out often the ‘more useful’ TLB to be imported is not the first (or only) one in a DLL

But generally speaking, there’s all kinds of management. You are more likely to find people who know their a%% from a martini drink in a smaller company. Large corps - well, let’s just say that enlightened middle management is… extremely rare

But it’s confidential, isn’t it?

I use rational rose approach to write software architecture document.
However, when it comes to the desgin spec. such as for a library, an application,
rational rose did not give us any template to follow.
I wonder if you could send me some examples how to document your design spec. for your library, application etc….
Thanks a lot

To protect the client’s IP (even though this was a 2003 project), this is not the final thing, some sections have been cut out, and many name references were mangled. Still, it should give you a very good idea on the approach we at Delera use.

http://www.delera.com/blog/share/SolutionSpec%20XXXBase.zip

A good example might be Linux; it practically destroyed the MS monopoly on operating systems, which is a Good Thing (the various Unixes predating Linux never stood a chance). Other good examples are many developer’s libraries and tools that can be done in a few man-months of work: these things bring enough benefits to justify several small companies to go out of business.

When I complain about rip-offs, I mostly consider FOSS projects that are feature-for-feature compatible with existing software produced by small and medium companies (and, oftentimes, are also, how to put it, “user interface compatible” with those too

To me, this embodies incredible short-sightedness on the part of FOSS developers. Projects like these make it nearly impossible for small and medium ISVs to compete on the global marketplace, thus leaving the battlefields to the big guys only (the likes of IBM). FOSS advocates often like to talk about helping the Good Guys with their software. Well guess what? A large percentage of the Good Guys are among those small shops which get out of business - or are never able to get started.

JBOSS in partciular is a strange case that has both pros and cons to it. On one hand, it is most certainly a rip-off of a commercial product. On the other hand, it attacks the provenance of large corporations - and large firms in the IT world could certainly use some attacking, given how they’ve shifted their strategies from “50% innovation, 50% sales and market bullying” to “10% innovation, 90% sales and market bullying” in the recent years.

Resently, companies have begun to attempt to leverage both these existing code bases and the development model for their own purposes. Whether they succeed or fail has less to do with FOSS and more to do with how they adopt that model to the business world.

Although I am a closed-source guy (MS Developer), I of course know many people who work with FOSS software. One of my friends has been working on a project that involves moving from WebSphere to JBOSS. He told me that in initial tests, JBOSS was running some of their code nearly twice as fast as WebSphere. The hardware savings the project yields will probably be more significant than the licensing costs. To relegate JBOSS to ‘generic rip-off’ is probably a bit unfair.

http://www.forbes.com/technology/2005/05/26/cz_dl_0526linux.html

Please email me privately and I’ll be happy to send you samples of some specs I did.
Overall, technical detail should correspond to what the developers could understand. I’ve always had the change to work with smart developers who could not only code, but also _think_.

http://blogs.msdn.com/oldnewthing/archive/2004/09/15/229915.aspx

First, we’d have to make sure that Str and StrMT are the same in every respect - which requires 50 or so methods to be duplicated. Many of them would be exactly the same, and the rest would differ in only a few lines. We could also use a template class, or define something like StrBase and descend Str and StrMT from it. But still, it is not a clean solution.

The second issue is that we’d have to define numerous “cross-class” helper operators. A simple example would be the assignment operator: in addition to its current forms (Str = Str, Str = const STRCHAR*), we would have to enumerate the additional possibilities (Str = StrMT, StrMT = Str). Multiply that by the number of operators in str.h and you will see what I mean.

public class AutoBuffer
{
private DataBuffer* pDataBuffer;

AutoBuffer(DataBuffer* pBuff)
{
pBuff->AddRef();
}

~AutoBuffer()
{
pBuff->ReleaseRef();
}
}

I am sure you have thought about it, but I am interested why you have not used this pattern.