Older blog entries for redi (starting at number 159)

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.

reality check

adulau says an OS is useless without Git. Even if I ignore the existence of non-developers, I can think of some more important tools. adulau's own recipe for updating screen is useless without make and a compiler and he could download a tarball of the screen sources instead of using git. Am I alone in not being sexually aroused by Git?

14 Aug 2008 (updated 14 Aug 2008 at 11:20 UTC) »
die, spammer, die

If DrDeniro isn't spammer scum I don't know who is. A huge <div> obscures the button to flag the account as spam and on Internet Explorer also redirects to a pharmacy site. This seems like a mod_virgule bug that should be addressed.

Click here to flag the account as spam.

robogato, I've emailed you the problematic markup in the "Notes" section.

Uh oh.

pa.swap(pb) still works even without the new swap() overloads, and is still equivalent to pa = pb.

Stay tuned for more live C++0x.

7 Aug 2008 (updated 7 Aug 2008 at 20:47 UTC) »

The answer to my C++0x quiz is that the explicitly-specified template argument means that these swap() overloads are tried:

  
void
swap<A>(shared_ptr<A>&, shared_ptr<A>&);
 
void
swap<A>(shared_ptr<A>&&, shared_ptr<A>&);
 
void
swap<A>(shared_ptr<A>&, shared_ptr<A>&&);

pb doesn't match any of those types, but if a temporary shared_ptr<A> (pointing to the A subobject of *pb) is created from pb, that temporary then binds to the rvalue-reference in the the third swap() overload. So pa is swapped with a temporary, and both pa and pb end up pointing to the same object; swap has performed an assignment!

The solution proposed by Howard Hinnant an hour ago is simply to remove the new swap() overloads from the working paper. The original motivation for them came from n1690, but now that we have std::vector::shrink_to_fit() there's no need for the overloads. So I won't bother adding them to libstdc++.

cdfrey, you may remove your suspenders ;-)

6 Aug 2008 (updated 7 Aug 2008 at 20:23 UTC) »
C++0x quiz

This came up while I was bringing GCC's shared_ptr up to date with the latest C++0x working paper.

What will happen here?


$ g++ -xc++ -std=c++0x - <<EOT && ./a.out
#include <memory>
#include <cassert>
struct A { };
struct B : A { };
int main()
{
  std::shared_ptr<A> pa(new A);
  std::shared_ptr<B> pb(new B);
  std::swap<A>(pa, pb);
  assert( pa.get() != pb.get() );
  return 0;
}
EOT

What do you think should happen?

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