Archive for June, 2005

Busy busy busy

June 24th 2005

Last week I started my next school for my training to be a submarine officer. It has been quite hectic, I generally don’t really have time to do much once I get home since I have to do the normal stuff like eat, take a shower, maybe check my email, and then whoops, time for bed. The hours for this school are incredibly long. Although one nice thing is that they generally don’t try to beat the unimportant stuff into our heads. One student asked a question during the explanation of a certain type of equation solving method, and the instructor explained about alternate methods, but then added, “Don’t worry about it though, you won’t need it.”

Today I played Unreal Tournament online with one of my classmates. And just last weekend my wife and I went our for dinner with another student and his wife. It’s kind of nice getting some more person-to-person interaction (indeed, the closeness of the submariner community was a big reason I chose this difficult route).

Unfortunately this doesn’t really leave me time during much of the week for KDE-related things. It’s a shame too, as there is increasingly so much that could be done that I’d like to help with. Oh well, maybe on the weekends. ;-)

Posted by mpyne under Uncategorized | No Comments »

Other C++ tidbits

June 17th 2005

Recently there have been posts about C++ on Planet KDE, so I just thought I’d chip in.

Someone was wondering why a class must define operator=() even though a perfectly good copy ctor already exists. Personally I think that the compiler should automatically define a operator=() somehow based on the copy ctor. I’m willing to bet that the reason this isn’t done is because that by declaring a default ctor or copy ctor manually, you have pointed out to the compiler that there is something special that needs to be done which isn’t done by default, and this is probably true for the assignment operator as well.

Ruurd mentioned how important it is to implement the Big Four for C++ classes, which are the constructor, copy constructor, assignment operator, and destructor. He’s right, but if you’re like me and don’t feel like typing it in manually, you should know that if you leave the constructors and assignment operator undefined, then C++ will define them for you. The compiler-generated functions will merely copy the data members over. One thing to note is that although basic data types like pointers, int, bool etc will just be copied byte-for-byte, any class data members will be copied by having their copy constructor or assignment operator called as appropriate. This means that you can use QString data members and such without being forced to define the initializers as long as the default behavior is appropriate. Note: If you’re holding a pointer the default behavior is probably never appropriate.

A final point is that Ruurd noticed that Foo a = b acts weird. Or in other words, code that does this:

void func(const Foo &b) {
  Foo a = b;
}

Would actually call Foo::Foo(const Foo &other), not Foo::Foo() followed by Foo::operator=(const Foo &other) as some would expect. This is a flaw in the language design since based on the behavior of new, I would expect that Foo a with no parameters would implicitly call the default ctor since Foo *pFoo = new Foo does that. (In fact, that syntax is required, new Foo() doesn’t work, and neither does Foo a();).

But consider the alternative. The new object is going to be created for the first time in the Foo a = b line. Most of the time you’re not trying to call the default ctor followed by the assignment operator, you just want to duplicate b. So in this case, C++ does what you meant (which is refreshing, for once). It’s also normally an optimization. Imagine having to have a coding standard to always use the relatively weird looking Foo a(b) syntax to duplicate an object instead of having the compiler figure it out for you. I wouldn’t want that, and besides, I can’t think of too many situations where it would be a good idea for:

Foo a; a = b;

to mean something different from:

Foo a(b);

Posted by mpyne under Uncategorized | No Comments »

Advanced parameter substitution with bash

June 11th 2005

I’m tired of looking up information on how to use those special fancy features to do parameter substitution in bash scripts, so I’ve decided to blog about it (at least some of the more useful ones). It’ll be quicker to find it this way than to Google it again.

First off, let me demonstrate with a sample:

KDEDOCS=${KDEDOCS:-default}

The :- says that if KDEDOCS is unset (or is set to a null value), then to use default as the result. The original variable is left unchanged.

There are other useful ones, which I’ll summarize here. For more definitive information, consult the Advanced Bash Scripting Parameter Substitution page, which is where I found the explanations. Also, as you may guess from the page title, some of these substitutions are specific to the bash shell. The example I gave seems to work on plain sh compatible shells though, but I can’t check.

Substitution Syntax Action
${VAR-default} If VAR is set (to any value, even null) then return $VAR, otherwise return the default provided. VAR is unchanged. If you use :- instead of -, then the default is also used when VAR is set to null.
${VAR=default} This is exactly like doing ${VAR-default}, except that VAR is set to the result as well. You may also use := instead of =, which has exactly the same difference.
${#VAR} This returns the number of characters in VAR. Note: I am not clear how this works with Unicode. I would assume that by characters they mean actual characters and not bytes, but I don’t know.
${VAR#pattern} This returns VAR with the shortest instance of pattern removed from the front. pattern itself is a shell-style glob, not a regular expression. If you use ## instead of #, then the longest matching pattern is removed instead of the shortest.
${VAR%pattern> Exactly the same as above, except that it applies to the back of VAR, not the front.

Apparently the following options were taken from ksh. So, you can assume that they’re not plain sh compatible:

Substitution Syntax Action
${VAR:pos} Returns $VAR, expanding from pos instead of the beginning.
${VAR:pos:len} Same as above, except that no more than len characters are expanded.
${VAR/pat/replacement} Returns VAR with the first instance of the shell-glob-style pat replaced with replacement. If you use //pat instead of /pat then all instances are replaced, not just the first.

So, intrepid bash hackers, put these tips to good use!


Also, George Staikos just added some plugin for Konqueror to kdeaddons that will extract specially formatted HTML as a vCard. I’ve decided to add my info to this blog for testing purposes, we’ll see if it works. ;-)

Posted by mpyne under Uncategorized | No Comments »

arghhh

June 8th 2005

Alexander Neundorf found yet another flawed, inaccurate C/C++ comparo. I’d add comments to the blog entry, but I don’t feel like looking up my user name, and this also satisfies my own blog quota for the week. =D

The article makes a few assertions about the perfomance of C++ code compared to C. Let’s debunk them:

  1. “C++’s virtues are expensive. Advanced OOP features, such as templates and the practice of using classes in the place of primitives, to name two examples, cause unacceptable code bloat.”

    Well, just as in other languages, C++ has features that may be counterproductive in some situations. And as always, the solution is to don’t use them. Templates, by the way, are not object-oriented. Instead they are a form of generic programming. You are perfectly free to do C and Java-style collections if you’d like by holding pointers to everything, where at least you can get C++ type safety.

    As far as using classes instead of primitive types go, if you’re really only able to use primitive types, then just use primitive types. You’ll still gain C++’s improved type safety abilities.

  2. “A C++ compiler may generate many routines for one function (templates) or create routines where no function explicity appeared (constructors, casts, etc.)”

    You’ve already seen my response to templates. People should keep in mind that templates are simply a better form of C macros. In some cases it may actually reduce bloat. Think about it: Say you have a moderately complex macro to retrieve a value. It’s a macro because you can’t use a function (more than one type), and it generates a non-trivial amount of code (perhaps it has to lock a mutex).

    In this case, a template would actually save code, because it would remove all of those inline macro expansions (which lead to serious code bloat), and instead replace them with a function call (only one function per type). This is especially useful on systems with small processor caches, such as embedded systems.

    “hidden functions” is another non-argument. The functions are hidden because you always have to use them. FILE * structures don’t automatically appear, do they? No, you have to call fopen(), fdreopen(), etc. And it’s likewise with C++. Instead of forcing you to remember which exact function you have to call, you can instead use constructors. These are functions that you would have to call in C anyways, so I don’t see how we can call this anything other than a win for C++, not a loss.

  3. “Virtual methods and polymorphism complicate runtime linking and require many relocations. This slows C++ application launch time considerably.”

    Now this can certainly be true (although templates and polymorphism are the big killers here, not necessarily virtual methods). However, we don’t live in 1999 anymore. Linkers and compilers have improved, so that they don’t generate a billion function names when the C++ code only needed 10 (e.g. the visibility support in recent GCC), and we now have programs available to “prelink” binaries so that they load quickly even if they have a lot of symbols. I’ll admit this has been an issue, but it’s not such a big deal in 2005.

  4. “Each class with virtual methods has an associated vtable array, which adds memory overhead.”

    Well duh, but it’s not like it adds 10K per class. In fact it’s actually more efficient than what GTK+ does to support virtuals (oh, by the way, GTK+ has virtual methods too), since it can be done at the language level instead of being emulated in C.

  5. “C++’s tighter type-checking makes it difficult to write the space-conscious code reuse common to C applications (think: void *).”

    And people seriously wonder why it is that in 2005 we still have buffer overflows. As Alexander pointed out, C++ didn’t take away void *. You can still use static_cast (and even C style casts) to your heart’s content. Sure, C++ will actually put up a fight when you’re doing bone-headed things and throwing pointers around willy-nilly. But that’s supposed to be a good thing, right? Oh, wait, it’s embedded, we don’t need to worry about security problems there. :-P

  6. “The small, simple code demanded of embedded projects provides maintainability. There is no reason to assume OOP will further simplify such systems.”

    BZZZT, WONG!! A clean design provides maintainability, not the latest ooh-look-how-many-unintended-sideeffects-I-can-use mentality. Of course a clean design is commonly a small design, but there’s a design nonetheless. Luckily, C++ is more than just OOP, and supports many different types of design. If you’re trying to scrap OOP though, you’d better look for something other than GTK+, which also uses a heavily object-oriented system. “Although GTK+ is written in C, a language without explicit support for object-oriented program, the design of GTK+ is heavily object oriented.”

  7. “GUIs may not have a simple solution in a rigorous OOP model.”

    Well, it’s a good thing you’re using GTK+, which isn’t heavily object-oriented, huh? Oh, wait…

  8. “It’s easy to get carried away and start doing OOP for OOP’s sake. The One True Object Model may describe a problem perfectly, but it comes at the cost of excessive code.”

    See above. And above that.

  9. “Carefully written C code can be much faster than C++ code, especially on embedded hardware. GTK+’s hand-crafted object system offers much better spatial locality than C++’s more numerous and distributed constructors. Our device has a tiny cache, so locality is an especially important performance consideration.”

    To be honest, I really don’t know. In the end, locality is up to the linker and compiler, not the programmer unless he’s using special features to control where .o files get placed in the final result. Of course, such features would work with both C and C++. And, once again, I’ve already pointed out that any constructors you’d need for C++ objects you’d also need for C structs. I suspect there isn’t much difference, even on those oh-so-fragile little embedded devices.

I don’t know why people always assume that you’re forced to use objects everywhere with C++. I mean, sure C++ makes it ridiculously easy to use a safe string type instead of always working with const char *. But no one’s forcing you. Even if you do nothing more than use C++ as a stricter C it’d still be a win for you. Although if you actually investigated you’d find that there is no difference between an object with no virtual methods, and the eqivalent C representation of a struct and related functions. Except that the syntax would be much cleaner.

I just wish that people would have the cojones to say what they mean sometimes. Like I wish the author of the piece would have just said: “Look, I don’t like C++, don’t feel like learning it or picking it up, I just want to code in C, and that’s that.” instead of rambling on and spouting half truths and other FUD about C++.

There *are* things to fault about C++, easy things too, and yet every point he brought up wasn’t one of them. Whatever. :-/

Posted by mpyne under Uncategorized | No Comments »

I’m back (online)

June 3rd 2005

I’m finally back on the intarweb. It’s kind of ironic. I’ve been in my new location for a full week. I *just* got my things moved in here yesterday, and the cable guys finally got the Internet to work after two trips over here.

The first trip was on Friday, the day after I moved up here. I was even excited that the service was going to be connected so quickly. The cable guy informed me that there was apparently a wire cut somewhere in the apartment attic (my unit doesn’t have access to the attic), and that he wouldn’t be able to get anything working. It was kind of annoying, but he made up for it by having used Linux enough to prefer KDE over GNOME. ;-) He was pretty impressed when I told him that I contribute to the KDE project. What’s even more amazing is that his only experience with KDE comes via Red Hat, which doesn’t exactly ship a polished KDE desktop with every release.

Thanks to the Memorial Day weekend, our goods didn’t even make it into the city I live in now until yesterday, even though it’s only a four hour drive from my old house. So I was without all of my furniture, my washer, and various other niceties. My wife and I did fill our cars up with things before we left, so she had her laptop, which proved absolutely invaluable, and I still had my desktop system. At least we were able to watch the Strong Bad email DVD collection. The movers re-assembled approximately 0% of the furniture (they didn’t even hook up the washer and dryer like they’re supposed to). They were real polite though, and only broke our el cheapo furniture (which we’ll be putting a claim on anyways.)

It turns out that I live like 20 feet away from a fellow student and Officer of mine, who loaned me the air mattress that he used when he first moved in a couple of weeks before I did. To pass the time over the past week my wife and I did a lot of driving around, visiting stores and the movie theater (and, of course, the bowling alley). We also visited yet another fellow Officer who was having a weekend party. It turns out that I’m OK at volleyball, but not so good at playing the Mafia party game where you sometimes are chosen to be the Mafia guy and must try to kill all the townspeople without them killing you first.

Now I await the start of school, when I can apparently expect 0530 - 1730 days (or worse…), along with mandatory studying on weekends. =D Before that I suppose I should finish unpacking though.

Posted by mpyne under Uncategorized | No Comments »