Older blog entries for redi (starting at number 84)

3 Feb 2006 (updated 4 Feb 2006 at 21:51 UTC) »
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?

12 Jan 2006 (updated 12 Jan 2006 at 10:18 UTC) »
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.
2 Oct 2005 (updated 2 Oct 2005 at 18:09 UTC) »
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.

23 Aug 2005 (updated 23 Aug 2005 at 14:45 UTC) »

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.
16 Jun 2005 (updated 16 Jun 2005 at 13:48 UTC) »

Joke of the day, courtesy of the GCC mailing list:

Daniel Berlin: Again, please point to specific examples.
Vincent Lefevre: GCC developers don't want examples.

Daniel Berlin is, of course, a prominent GCC developer.
Vincent Lefevre is the leader of a time-travelling race of aliens wanting to subvert GCC to their own evil purposes. Beware!

Update: it occurs to me that Vincent could be trying a Jedi mind trick, like "these aren't the droids you're looking for" ... even more reason to be wary. I suspect Darth Berlin will not be swayed but some lesser developers could be.

14 Jun 2005 (updated 14 Jun 2005 at 16:18 UTC) »

Aha! rillian, thanks for the info! I'm glad to know that too, as it confirms the theories about the cause. Damn that spam!

Oh, and the sendmail problem I was having turned out to be DNS issues at my ISP, nothing to do with the unrelated packages I'd upgraded, which is also re-assuring.

hacker, your diary entries are still there, as are your certs.

See returnoftheredi's diary for more info.

It's been blamed on a bug in the mod_virgule code that doesn't handle disk full errors, but I'm skeptical whether the disk fills up often enough to account for the frequency of the problems.

While I'm here, might as well mention I made a new release of PStreams at the weekend, which includes streambuf::in_avail() support and a close-on-exec trick to detect when the child process fails to execute, courtesy of slamb.

Oh, and it seems that by upgrading to a newer /etc/modprobe.conf.dist I've cocked up my sendmail config so that SMTP AUTH no longer works. Damn.

75 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!