Older blog entries for redi (starting at number 164)

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.

sucking shit

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.

Movember - Sponsor Me 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.

28 Oct 2008 (updated 28 Oct 2008 at 15:32 UTC) »
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.

21 Oct 2008 (updated 21 Oct 2008 at 18:15 UTC) »

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.

21 Oct 2008 (updated 21 Oct 2008 at 18:18 UTC) »
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.
18 Sep 2008 (updated 18 Sep 2008 at 13:22 UTC) »

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.
5 Sep 2008 (updated 5 Sep 2008 at 10:20 UTC) »

Softkid is surprised V8 support x86 and ARM but not ia64. He must know more people than I do who run Windows desktops or mobile phones on Itanium.

Top Tips

GNU maintainers, tease your users by automatically inserting this boilerplate into man pages, then don't provide texinfo docs, so they get the same man page via info.


The full documentation for fubar is maintained as a Texinfo
manual.  If  the  info  and  fubar  programs  are  properly
installed at your site, the command
      info fubar
should give you access to the complete manual.

Amazingly the BSDs and OpenSolaris seem to be sticking with manpages. Maybe GNU should finally give up on texinfo? Please?

C++0x update

The troublesome swap() overloads are still in the latest C++0x draft, so I've added them to libstdc++. The std::shared_ptr on GCC's trunk is now complete, except for the constructor from std::nullptr_t which isn't available yet in GCC.

My next goal is to extend result_of to meet the C++0x requirements. The TR1 requirements allow result_of to fail if it can't determine the result of a function invocation, but C++0x requires it to do the Right Thing, using magic if necessary. With decltype and variadic templates in GCC, it's pretty easy. I've seen The Future, and it kicks ass.

155 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!