Archive
State Of The Union
For the multi-threaded CSCI that I’m developing, I’ve got to receive and decode serialized messages off of “the wire” that conform to the design below. Depending on the value of “payloadType” in the message, each instance of the “WireMessage” class will have either an instance of “DataBlock1” or “DataBlock2” embedded within it.
After contemplating how to implement the deserialized replica of the message within my code, I decided to use a union to keep the message at a fixed size as it is manipulated and propagated forward through the non-polymorphic queues that connect the threads together in the CSCI.
The figure below shows side by side code snippets of the use of a union within a class. The code on the left compiled fine, but the compiler barfed on the code on the right with a “data member with constructor not allowed in union” error. WTF?
At first, I didn’t understand why the compiler didn’t like the code on the right. But after doing a little research, it made sense.
Unlike the code on the left, which has empty compiler-generated ctor, dtor, and copy operations, the DataBlock1 class on the right has a user-declared ctor – which trips up the compiler even though it is empty. When an object of FixedMessage type is created or destroyed, the compiler wouldn’t know which union member constructor or destructor to execute for the two class members in the union (built-in types like “int” don’t have ctors/dtors). D’oh!
Note: After I wrote this post, I found this better explanation on Bjarne Stroustrup’s C++0x FAQ page:
But of course, the restrictions on which user-defined types may be included in a union will be relaxed a bit in C++11. The details are in the link provided above.
Revoked Membership
In Stop Coddling the Super-Rich, Warren Buffet states:
My friends and I have been coddled long enough by a billionaire-friendly Congress. It’s time for our government to get serious about shared sacrifice. – Warren Buffet
OUR leaders have asked for “shared sacrifice.” But when they did the asking, they spared me. I checked with my mega-rich friends to learn what pain they were expecting. They, too, were left untouched. – Warren Buffet
As Vineet Nayar is to CEOs, Warren Buffet is to the super-rich. I luv both those guys. What about you?
Pick Your Tyranny
Given the choice between “tyranny of the majority” and “tyranny of the minority“, I’d choose the former every time – especially when the minority is a junta in the latter case. In representational democracies like the good ole USA, the “representational” aspect decreases the chance of being governed by the “tyranny of the majority“. In really bad corpricracies, the “tyranny of the minority” is the rule and, since it’s a subtle form of tyranny, everyone up and down the ladder of importance accepts it in quiet desperation – with no questions asked.
Manager Types II
This post is an updated refinement of BD00’s class hierarchy for the manager types previously presented in the UCBH post. For your viewing displeasure, I’ve reproduced the “rev 0” version of the inheritance tree here:
The “rev 1” version, with all class operations elided because they’re not important for understanding the message I want to get across, is shown below. The absence of the “Tweener” in rev 0, which inherits the attributes and operations from both the “Bozo” and “Helper” classes, was a major mistake.
“Rev 1” is a much more accurate mental model of the manager kingdom because, as the probability density function below shows, the vast majority of manager “objects” are of the relatively boring, harmless, and ho-hum “Tweener” type.
If you look closely at the threshold locations in the scraggly drawn probability distribution, BD00 has postulated that even though the population is comprised mostly of “Tweeners“, there are more BMs than PHORs. Do you agree?
Luckily and happily, BD00 has never worked for, or with, a conscious BM. But he’s directly heard, and indirectly read, several stories from those poor souls who have (are you one of them?). Thus, BD00 is convinced that they do exist in nature.
All models are wrong. Some, however, are useful – George Box
More What?
My dog “Morrie” is a beautiful creature. On top of that, he’s uh hilariously dumb ass in the mould of his human step father. Depending on the situation we’re involved in together, I either call him “More-Easter“, or “More-Keester“. Every once in awhile, I call him by his real name, “Morrie”, so he doesn’t fugget it. I call him “More-Easter” (like the Nor’easter storm and not the dogmatic christian easter) when he’s wreaking havoc, and “More-Keester” when he’s acting like his dad; a keester. Which nickname do ya think I use more frequently?
Desired And Actual
Raising Ire
I’m a member of several C++ programming groups on LinkedIn.com. Because I’m passionate about programming and software engineering, I like to share links to what I think are interesting C++ articles to the groups.
Bam! Out of the blue, I get this BS “warning” from a hot shot moderator of one of the groups:
After challenging this self-important dude to point out some examples of “off topic” postings, to define excessive “posting frequency“, and to provide the name of my accuser, I received silence.
Out of curiosity, I contacted the group owner and asked WTF was going on. He checked into the situation and said that I wasn’t posting too frequently (of course, there IS no rule about posting “too frequently“) and that he enjoyed my posted links. Nevertheless, I quit the group since there are many other C++ groups to contribute to without being hassled by a power monger and control freak. Life is too short.
Via a simple analysis of the content in the “scary” warning message, I arrived at the conclusion that the dude was reading this bogus blog and got pissed off cuz he is either a BM or a BM wannabe – and the shoe fit. So, I sent a message to Mr. God and suggested:
“If my blog upsets you, then don’t read it.”
Of course, since he didn’t admit to it, I don’t know fer sure if Mr. little Hitler stumbled onto this blog and blew his stack . But, as you know, BD00 is prone to making stuff up and bouts of wild speculation. D’oh!
This Is Why….
….I don’t use my own clipart on this blog:
The Emergence Of The STL
In the preface to the 2006 Japanese translation of “The Design and Evolution of C++“, Bjarne Stroustrup writes about how the C++ STL containers/iterators/algorithms approach to generic programming came into being. Of particular interest to me was how he struggled with the problem of “intrusive” containers:
The STL was a revolutionary departure from the way we had been thinking about containers and their use. From the earliest days of Simula, containers (such as lists) had been intrusive: An object could be put into a container if and only if its class had been (explicitly or implicitly) derived from a specific “Link” or “Object” class containing the link information needed by the compiler (to traverse the container). Basically, such a container is a container of references to Links. This implies that fundamental types, such as ints and doubles, can’t be put directly into containers and that the array type, which directly supports fundamental types, must be different from other containers. Furthermore, objects of really simple classes, such as complex and Point, can’t remain optimal in time and space if we want to put them into a container. It also implies that such containers are not statically type safe. For example, a Circle may be added to a list, but when it is extracted we know only that it is an Object and need to apply a cast (explicit type conversion) to regain the static type.
The figure below illustrates an “intrusive” container. Note that container users (like you and me) must conform to the container’s requirement that every application-specific, user-defined class (Element) inherits from an “overhead” Object class in order for the container to be able to traverse its contents.
As the figure below shows, the STL’s “iterator” concept unburdens the user’s application classes from having to carry around the extra overhead burden of a “universal“, “all-things-to-all people”, class.
The “separation of concerns” STL approach unburdens the user by requiring each library container writer to implement an Iterator class that knows how to move sequentially from user-defined object to object in accordance to how the container has internally linked the objects (tree, list, etc) and regardless of the object’s content. The Iterator itself contains the container-specific equivalent navigational information as the Object class in the “intrusive” container model. For contiguous memory type containers (array, vector), it may be implemented as a simple pointer to the type of objects stored in the container. For more complex containers (map, list) the Iterator may contain multiple pointers for fast, container-specific, traversal/lookup/insertion/removal.
I don’t know about you, but I think the STL’s implementation of containers and generic programming is uber cool. It is both general AND efficient – two desirable properties rarely found together in a programming language library:
…the performance of the STL is that it – like C++ itself – is based directly on the hardware model of memory and computation. The STL notion of a sequence is basically that of the hardware’s view of memory as a set of sequences of objects. The basic semantics of the STL maps directly into hardware instructions allowing algorithms to be implemented optimally. The compile-time resolution of templates and the perfect inlining they support is then key to the efficient mapping of high level expression of the STL to the hardware level.
The Elephants In The Room
One of the originators of RUP and the creator of the 4+1 view modeling approach, Phillippe Kruchten, has written a terrific article on the “twenty elephants in the room” that haunt the agile movement. Here’s a subset of his infamous list that resonates with me:
- Commercial interests censoring failures (tell me about the failures).
- Failure to dampen negative behaviours (no analysis of failures).
- Context and contextual applicability of practices (can you say “safety-critical systems“?)
- Anarchism (preventing a more systematic organization of the body of knowledge).
- Elitism (blame failure on the “unenlightened” others)
- Certification (effective tool to assess maturity for individuals and organization, or commercial ploy from trainers and consultants to rake in the dough?)
- Role of architecture and design (they are still often equated to BUFD, and rapidly brushed aside with claims of YAGNI, or “we’ll refactor it later”)
- Scaling naïveté (with a bit of imagination all agile practices scale up, and if this does not work it is because you have not tried hard enough).
- Technical debt (while agile practices could help control technical debt, they are also often at the root, the cause of massive technical debt).
- Effective ways of discovering information without writing source code (uh, can you say “modeling“?).
Of course, because of his involvement in the development of the perceived horrible, heavyweight, RUP process, extreme agilistas will not even listen to Phillippe’s ideas – let alone ponder the validity of any of them.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 