Older blog entries for redi (starting at number 89)

cdfrey, cert'ing everyone as journeyer is a silly policy and doesn't help make the trust metric any more reliable. I've noticed some oddities with certs anyway - to pick one example (and I'm not making skills judgments either) herzi. And fxn is a Master now even though most of the Master certs he has are from people who aren't cert'd at all or are not regular contributors. Update hmm, I've forgotten of course that some certs are invisible, due to vanishing accounts - most of my own certs don't show up on my personal page, but still contribute to my Journeyer rating. Upupdate Chris, I see the point you're making better now.

I don't even have my computer at the moment, let alone a FSF copyright assignment, so no non-proprietary code from me this year :-(

And VC6's asm output has what to do with Free Software? htonl() on real hardware's a no-op anyway ;-)

firefly, copy-in copies from stdin to the filesystem, copy-out copies from the filesystem to stdout. Or maybe you'd prefer to think of copy-in as copying files from an external medium (e.g. tape archive) in to the system. Now that I've answered your question, how about answering mine?

nconway and ncm, C99 also allows declarations mid-block, so you can declare the variable where you initialise it.

firefly, that apgcc page seems to be missing some important information. What happens if I apgcc with 3.3.6 and 4.0.2 ? Should I be able to run at least one of those binaries on a similar system with any GCC version > 3.2.0 ?

fzort, I think that UMB Scheme crash is RH bug 170533

operationalize? What a stupid word.

Whitespaced

Can anyone identify something I read last year that suggested that whitespace and brace placement in C should be strictly enforced by the standard, so that we can get on with writing code instead of squabbling about the bits in between?

robsta that particular post is classic /. bullshit. "C++ already does type deduction, so where is the problem?" - er, none - that's why it's coming in C++0x. "template typedefs are there for the exact same reason" - er, what template typedefs? "template concepts; correct solution, but why they say it is difficult to implement?" - which solution, the Indiana or Texas one? Look at ConceptGCC for a working implementation. "templates were little more than C macros" whatever. "No one has used C++ for any major operating system," Windows. "and no one has used C++ for any hardcore military project." Joint Strike Fighter.

Typical /. moron. Some of the points are less worthless, but he's not saying anything that hasn't been said a million times before.

Marcus, see the FreeBSD man page for adduser(8). RedHat's version of useradd(8) behaves similarly.

cdfrey,

Creating template versions of the mozilla string class, perhaps parameterized with the various functionality as template arguments, would cause each function that needed a general string argument to be a template as well, to accept whatever the user passed in. Am I missing something obvious here?

Yes. If a function takes some specialization of a template, it is not a template. I can pass std::string to non-template functions, yet std::string is std::basic_string<char> which is, of course, a template!

If you have a function that takes nsAString& and doesn't care what the dynamic type is, this can be achieved with a simple handle class that wraps a particular specialization of a template, so that all specialisations can be handled through a uniform type.

Aside: The idea of types "parameterized with the various functionality as template arguments" is sometimes known as policy-based design and Andrei Alexandrescu has produced a policy-based std::string-compatible string class. A version of this is being developed for Boost under the name flex_string.

Your statement "the larger your template functions become, the more each instance costs every time you use it" simply doesn't wash with me. Factor out common parts that don't depend on the template arguments to avoid duplicating them (just as you would if you were hand-coding the function for all the types you want to use it with!)

If you want a function that operates on objects of three types, you should not end up with any more machine code if you write one template and instantiate it with three types than if you write three functions. Most claims of "template bloat" I've come across are FUD, bad style, or plain ignorance about the subject matter. If you instantiate the template willy-nilly with every type in your system, then you'll end up with a lot of bloat, but why the hell are you doing that if you don't need to? And if you do need to, you'd have had to hand-code the function for every type anyway, so you'd still have the bloat.

Apparently a recent Microsoft linker will actually merge common code for you, so parts of template functions that don't depend on the template args will use the exact same machine code - which potentially means less bloat with templates than hand-coded functions!

As for inheritance, one reason to use it judiciously is that public inheritance provides implicit conversions from derived to base (a.k.a up-casts,) which implies substitutability (c.f. LiskovSubstitutionPrinciple.) Unsafe or unintended implicit conversions weaken the type system and can lead to fragile, hard to debug code. If your types do not follow the LSP, do not use public inheritance.

If your types are not substitutable you might think that using private or protected inheritance would be better, but it is usually better to use composition, not inheritance, in that case. Say you want to re-use the implementation of some class A, so you do this:

class B : private A {
  void f();
};

If, at some later time, A is changed to add a virtual f(), then suddenly your class will either fail to compile (if the return types are not compatible) or will silently change the behaviour of the derived class in completely unintended ways. If A is not designed for use as a base class, don't inherit from it, add a member of type A to B instead.

You should try to use the weakest coupling between two types that you can, inheriting (privately or publicly) might bring more names into scope than you intended, causing clashes, or might cause your code to silently change meaning if the base class changes.

Inheritance is one of the strongest relationships available in C++ (along with friend) and inheritance leads to high coupling, coupling leads to spaghetti, spaghetti leads to late night debugging headaches, which is the way of the Dark Side.