Older blog entries for redi (starting at number 165)

In a reply to one of his recent articles, lkcl said:

here's the secret, that you and everyone else who reads what i write, don't seem to be in on...

I take objection to "everyone else," lkcl was one of the first certs I gave on this site, and the only reason I removed the Master cert I'd given him was because of his certification of mentifex, not because I don't value his work. My feeble trust-juice will have no influence on either of their ratings, but that's not the point.

There's been some more brouhaha about KDE4 recently (well, recently when I first saved this draft diary entry) including Linus Torvalds announcing he's switched to gnome. Some commenters have said that people who aren't happy on the bleeding edge should not be using distros such as Fedora. I agree, but my problems with KDE4 are not that there are unstable, unreliable parts, which I expect from new releases. It's that basic functionality was removed, resulting in stupid regressions that still aren't fixed in KDE 4.2, despite claims that it is "a compelling offering for the majority of end users." The problems for Fedora users are exacerbated by the response to any KDE-related bug reported to Fedora bugzilla: "not our problem, report it upstream." (update: and in some cases claiming it's fixed without even bothering to check.)

Despite its flaws, I really do like my eee pc. Being able to hack on code while walking down the street is brillant.

Recently I did some hacking on std::thread for libstdc++, as I needed to make a small fix before I could finish std::bind and I got carried away making improvements to std::thread.

I also suggested a few patches for Boost to fix some problems in the (fscking excellent) new thread library. Unfortunately whether I report bugs to the boost list or to trac, they seem to fall between the cracks. The list has far too much traffic for me to follow, so I don't bother chasing them up.

I've realised that one of the things I like about smart pointers in C++ is what they tell you about the programmer. Smart programmers use smart pointers. The other group use raw, unsafe pointers.

chromatic confuses unit tests and TDD, but he's not alone in that.

I wonder why jcsteele also needs to syndicate his blog to selerius. I wonder why anyone needs to syndicate their twittering to advogato.

Spammer accounts seem to be on the rise again in the last few days. It's a testament to the incompetence and stupidity of most spammers and SEO twunts that they can't even enter the same thing in two fields e.g. creating an account as "ajax09" but putting the real name as "ajax 222" ... if they weren't such idiots it might be a lot harder to identify accounts created by spammers.

The Emperor's New Desktop

I still think KDE4 sucks enormous quantities of shit.

Xerces-C++ is a conspiracy to make C++ look bad

Xerces-C++ sucks even more shit. Writing a C++ API with unclear memory-ownership semantics was pretty dumb a decade ago. It just makes you look idiotic in 2009. Dynamic memory management in C++ is a solved problem. Requiring explicit calls to release memory at scope exit can be attributed to stupidity, but not providing an RAII type to restore some sanity to the API begins to look like malice.

diary of micro hacks

I had hoped to update GCC's std::tr1::bind and friends to also serve as std::bind (after breaking them and having to back out my changes a few weeks ago) but I didn't get any hacking done over twixtmas, except some small changes to the GCC manual and some largely pointless changes to the non-functional std::tr1::regex code.

Last week I updated the RPM spec files I wrote for STLsoft & Pantheios RPMs for Fedora. They're closer to the Fedora packaging guidelines now, and all my STLsoft patches have been accepted upstream which makes life simpler.

If I get time I might release some C++ container templates I wrote recently, worm::map<Key,T>, worm::set<T> and non-unique counterparts, which provide a similar interface to the standard associative containers but implemented using sorted std::vectors. This means they have random-access iterators and better memory locality, but sacrifice the nice iterator invalidation rules of the standard associative containers. I need to remove some sharp edges and figure out whether I can keep the same interface w.r.t const and ordering invariants, or whether I need to make them immutable to prevent self-inflicted gunshot wounds to the foot.

I chickened out of Movember after only a week, as it was too itchy and with a cold I didn't fancy wiping snot from my 'tache all day! The badge to the left takes you to the sponsorship page of a friend who started it with me, but didn't give up.

My shared_ptr changes will be in GCC 4.4.0 and I've solved the remaining issue with result_of, so I hope that will be in 4.4.0 too.

Fast Forward The Future

I found some time at the weekend to finish updating GCC's std::shared_ptr with the changes from n2637. operator< on shared_ptrs now compares the contained pointers instead of comparing the address of the control block. This makes operator< a partial function, which is consistent with comparisons on raw pointers ... but makes it useless in nearly all cases where you might use shared_ptr!

LSB

Wow, they haven't finished flogging that dead horse yet.

cinamod, the simplest solution is to add an overload with the parameters reversed. That's easy if you use a function object instead of a function pointer:

  
struct my_pred
{
  bool operator()(const ComplexType& v1, int v2) const
  {  return v1.field < v2; }
  bool operator()(int v1, const ComplexType& v2) const
  {  return v1 < v2.field;  }
};
...
lower_bound(begin, end, val, my_pred());

What MSVC is doing is not unreasonable, lower_bound requires a StrictWeakOrdering and one of the properties of a strict weak ordering is anti-symmetry. It's not possible to verify your predicate is antisymmetric if the order of the argument types matters.

Also, see the definition of equivalence used by the STL. Your predicate makes it impossible to test for equivalence.

I'm working on a short article about StrictWeakOrderings, which I'll post here when it's ready.

chalst, in addition to the subject matter, I suspect kgb's diary entries are rated low because of the large number of images that load very slowly. I see him at 2 ±2.1 (confidence .11) so I don't see them at my usual thresholds, but I can live with that.

Formatting of diary previews is very broken, especially if you use <pre> or try to control the layout. It makes posting code annoying. The problem seems to be related to blank lines inside <pre> blocks, which get <p> elements added. The auto-paragraph-break feature should not apply to text within a <pre> which is by definition already formatted.

result_of

Some ramblings about result_of, a little utility available from Boost. It was proposed for standardisation in n1454, was included in TR1, and will be in C++0x. It's used inside some other Boost libraries, but many C++ programmers will never need to use it directly, or know any of what follows. If you do need to know about it, there's a much better description in Pete Becker's book.

The syntax, e.g. result_of<Func(Arg1*, Arg2&)>::type may not obvious at first glance, even if you know C++ fairly well. Result_of is a unary metafunction, a template with one parameter:

  
template<typename Signature>
  struct result_of;

There is no definition for the primary template, only for partial specializations where the template parameter is a function type:

  
template<typename Fn, typename... ArgTypes>
  struct result_of<Fn(ArgTypes...)>
  {
    typedef ??? type;
  };

The specialization contains a typedef, type. In the earlier example, the function type used as the template argument to result_of is Func(Arg1*, Arg2&)

That type is a function taking a pointer to Arg1 and an lvalue-reference to Arg2, and returning Func. Compare it to the more familiar declaration of a pointer to such a function:

Func (*)(Arg1*, Arg2&)

This doesn't mean there is a function taking those arguments and returning Func, it's just a made-up type passed to result_of, which extracts the necessary information from the type using a bit of template metaprogramming from the school of Boost. The function-type syntax is used to mimic the syntax of invoking some callable type, Func, with arguments of those types, as in

Func func;
Arg1 arg1;
Arg2 arg2;
func(&arg1, arg2); // compare with Func(Arg1*,Arg2&);

So result_of<Func(Arg1*,Arg2&)>::type is a typedef for the return type of the call above, which due to overloading and implicit conversions could be pretty much anything!

  
// type is int if Func is:
typedef int (*Func)(Arg1*,const Arg&);
// type is char if Func is:
struct Func {
  void operator()(int);
  char operator()(void*, Arg2) const;
};
// type is double given:
struct Base { };
struct Arg1 : Base { };
struct Arg2 : Base { };
struct Functor {
    int operator()(Arg1*, Arg2&);
    double operator()(Base*, Base&, Base* = 0) const;
};
typedef const Functor Func;

In the last example the first operator, which matches the argument types exactly, is not const, so cannot be called on a const Functor, so the second operator is chosen, converting the arguments and using the default for the third argument. Getting result_of to give the right answer was a fun little exercise.

C++0x support in GCC

I'm still working on std::result_of for libstdc++. Implementing it to follow the current C++0x draft was easy ... unfortunately I think the current draft is wrong.

  
struct X {
  void operator()(int&) { }
  int  operator()(int&& i) { return i; }
} x;
std::result_of< X(int&&) >::type i = x(0);

I think the code above should compile, but if I follow the draft wording it won't, because result_of selects the first overloaded function-call operator, which has a void return type.

  
struct Y {
  int i;
};
typedef int Y::*MemPtr;
std::result_of< MemPtr(Y*) >::type i;

The example above works with tr1::result_of but not with std::result_of, because this is not valid:

  
MemPtr mp = &Y::i
Y y = { };
mp(&y);    // ERROR - must use (y.*mp) instead

N1695 addressed this topic and suggested making pointers-to-members callable as above. Without that change it's harder to write generic code that works with all callable types. This is just one of the places where C++ syntax isn't as regular as it could be (to put it politely) but once geniuses such as Peter Dimov and Doug Gregor have done the hard work (e.g. std::bind, std::function) the rest of us can use higher-order functions in C++ without caring that the implementations aren't always pretty.