Older blog entries for redi (starting at number 87)

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.

I agree with terceiro, you do forget how to hide a bike - mine got stolen from the front garden last year because I didn't hide it well enough. (Sorry, Antonio, couldn't resist :-) My bike really did get stolen, but you've made me see a funny side to it! By the way, feel free to add yourself to the PStreams as "Helper" or whatever you think appropriate.)

That reminds me -- cdevienne, to record that you're the maintainer of libxml++ log in to advogato, then go to the libxml++ project page and choose a "Type of relationship" at the bottom of the page.

Been distracted from finishing the next version of PStreams by many things ...

Tweaked Marc Rochkind's Ux code to work with recent versions of GCC and glibc and sent him the updates.

Spent some time reading the strawman proposal for a C++ memory model, got confused by an example until I realised there must be a typo, which has now been corrected. That means I did understand it correctly - good!

Backlog of libstdc++ work is increasing. Lots of half-finished doc updates that I need to polish off. The std::tr1::shared_ptr in libstdc++ is still sub-optimal, using empty critical sections to provide full bi-directional memory barriers. One of the super-optimised asm versions in Boost's shared_ptr has turned out to cause a problem in certain situations with a certain compiler and so there's an update to 1.33.0 already, so there's something to be said for playing it safe - especially when I'm still learning about all this sink/hoist/yo-ho-ho-and-a-bottle-of-rum stuff. "Correctness is a constraint; performance is a goal."

Got sick of poor developer docs for Apache and am improving a small part of them that I happen to be familiar with (actually, the code in question is part of aprlib.) Have some ideas for some C++ types for use with aprlib, to register objects and cleanup functors (not just int (*)(void*) functions) with pools, kinda similar to TnFOX's transaction rollback stuff, but with pools.

I'm about to leave the job I've had for the past 6 years, which was mostly Apache-1.3 module development in C++, so I figure I've got a fair bit of relevant experience to make use of and now that I'm not constrained by business requirements (i.e. only using apache 1.3) I can play with 2.0 and the APR. The state-of-the-art of writing Apache modules in C++ doesn't seem to be very advanced. I see no reason why you shouldn't be able to write modules using exceptions and other modern C++ features and not worry about interfacing with C. I'm probably missing something that already makes it easy. Step 1: make mod_cplusplus exception safe.

Hope the new job lets me contribute to free software, I really don't see myself staying anywhere else for 6 years if I don't have permission to write (and license) my own code in my own time. It'll be nice to finally a recent version of GCC though, so I'll know code I worked on is being used :-)

Ankh, bash-completion for FC2 is in the (now defunct) fedora.us repository. For FC3 that repo has become Fedora Extras.