Older blog entries for redi (starting at number 239)

5 Apr 2011 (updated 29 Nov 2011 at 12:01 UTC) »

Today I tried recompiling a fairly large codebase using GCC
4.6 and -std=c++0x (and also -std=gnu++0x). Due to a couple
of small bugs I was using 4.6.0 plus two patches that will
included in the 4.6.1 release. For the purpose of this
exercise, GCC 4.6 is pretty close to implementing the C++0x
rules in the FDIS that was voted for at last week's
committee meeting (there are several C++0x features such as
inheriting constructors and ref-qualifiers for member
functions which are not implemented in GCC yet, but those
features are new in C++0x and so aren't used in C++03

The results were very positive. Apart from adding a few
missing headers (which should have been there anyway)
only a couple of
changes needed to make the C++03 code also valid for

Narrowing conversions

I had to change some initializers to avoid narrowing
conversion (such as double to int, int to char) which are
allowed in C++0x. e.g

struct S {
int i;
S s = { 0.0 }; // should be { 0 }
for (int i=0; i < 10; ++i) {
char s[2] = { '0'+i }; // should be { char('0'+i) }


The definition of the function template
std::make_pair has changed in C++0x, but I was
surprised to find this caused a problem. In C++03 it's very

template<typename T1, typename T2>
make_pair(T1 x, T2 y);

The function deduces the types of its arguments and returns
a pair with those types. This saves you from
explicitly specifying the types, as shown by this example in
the standard:

In place of:

  return pair<int, double>(5,
// explicit types

a C++ program may contain:

  return make_pair(5, 3.1415926);// types are deduced

Simple, eh? Using make_pair is convenient, but
that's all it is, a convenience
function to save a bit of typing. It therefore makes no
sense to explicitly specify the types:

  return make_pair<int, double>(5,
// explicit types

This requires typing five more characters ("make_") than
just constructing a pair directly. It's pointless.
It takes the convenience function and then uses it
inconveniently. It's like putting a stepladder in front of a
high shelf, then standing next to the ladder and reaching
over it. You're doing it wrong!

Yet I found a few cases where that's exactly what had
written. And other members of the BSI C++ panel have
reported that it's used in their codebases too.

Why does it matter? Well in C++0x the definition has

template<typename T1, typename T2>
make_pair(T1&& x, T2&& y);

The template arguments of the returned pair are not
the same as the template arguments of make_pair
(they might be the same in some cases, but all.) As you may
be able to guess from the && decoration,
this was
done to support move semantics, so that the elements of the
returned pair can be move constructed (instead of
copy constructed) when the arguments are rvalues (i.e.

This means that if you disable argument deduction by
providing an explicit template argument list in C++0x, then
the function can only be called if the function arguments
are compatible with the explicit template argument types:
only rvalues arguments will be accepted if you call
make_pair<T1,T2> and only lvalues will be
accepted if you call make_pair<T1&,T2&>
because lvalues can't bind to rvalue-references and
rvalues can't bind to non-const lvalue references.

The solution? Don't call make_pair with
template arguments.

To be honest, there is one valid reason to give an
template argument list, which is if you want one type to be
explicitly specified and one to be deduced e.g.
return make_pair<const long>(0, x);

That could be useful to insert into a std::map.
If you really want the old C++03 semantics of
make_pair then you can write your own, as it's
really trivial. Whereas the semantics of the new C++0x
version are subtler and harder to get right, so I think it's
right that the standard library provides the complicated one
and that you have to define the simple one yourself (if you
even need it.)

fzort, here's a better response from a linguist in my family, my guess was probably wrong :)

I think it's an evolution such as takes place in any language in different ways. In English, I suspect this particular one comes from the mix of different other-language speakers learning English and the habit has spread because of modern media diffusion.

It is interstingly not a complete evolution. With two prepositions involved, it was originally 'tell it to me', just as it still is 'explain it to me'. The incompleteness can be felt/seen if you say something like 'I told him it'. There's a slightly clumsy feel, to me at least, in the use of the two pronouns side by side.

Consider also that English is unusual in having two words for what is often only one in other languages - to say and to tell, for dire in French. You wouldn't say 'Say it me' or 'Say me it'. Equally, the indirect object//dative case form applies to speak/talk//parler. 'Speak French to him', or 'talk sense to me' are the ways we say it. Not 'talk me sense' or 'speak him French'. So it is 'tell' that seems to have undergone this semi-evolution, why I cannot be sure. Or really I haven't a clue. But it doesn't have nowt to do with Latin vs Germanic etymology.

Hi, fzort! I don't even see all those diaries from proclus thanks to the rating system.

Sorry, parsing English is even more ambiguous than parsing C++.

The transitive verb "explain" can have a direct object (the thing being explained) and an indirect object (the recipient of the explanation.) "She explained me" makes "me" the direct object, that is, the thing being explained. "She explained something to me" has "something" as the direct object and "me" as the indirect object. "Tell" can be used the same way: "She told something to me" is correct, but so is "she told me something" -- but that's not the case for "explain." I'm not sure why but the difference might be because "explain" comes from Latin and "tell" comes from Anglo-Saxon, which have different grammar.

ncm, I would really really like that browser feature too.
2 Mar 2011 (updated 2 Mar 2011 at 15:24 UTC) »

In C++ foldr is pronounced std::accumulate and map is pronounced std::transform.

I don't think we have a word for unfold, but I guess I'd say it like this:

template<class OutIt, class P, class F, class G, class T>
unfold(OutIt result, P stop, F f, G g, T x)
    if (stop(x))
        return 0;
    *result = f(x);
    return 1 + unfold(++result, stop, f, g, g(x));

Edit: hmm, no I wouldn't, it's unspecified whether g or g(x) gets evaluated first, which matters if G is stateful (which it shouldn't be, but have ever tried telling a C++ programmer they shouldn't use a sharp object?) A workaround would be to pass stateful functors in by reference, e.g. using a reference wrapper such as boost::ref or std::ref but it'd be nice if that wasn't needed. I'll have to think about that further ...

audriusa please fix your diary entry, it's fscking up the following entry on recentlog
20 Jan 2011 (updated 20 Jan 2011 at 10:52 UTC) »
The Empire Strikes Back

Like chalst, I'm pleased there are still some interesting unsyndicated diaries in recentlog. If only they weren't massively outnumbered by the new spam accounts created every day.

17 Jan 2011 (updated 19 Jan 2011 at 09:40 UTC) »

kill the spammer below this post [he got killed, but despite blocking his IP range he's back again]

someone patch mod_virgule to reject all accounts from repeat spammer "tarunyadavseo" - please click on his name in "New advogato members" and mark his account as spam. Then find him and set fire to him.

6 Jan 2011 (updated 6 Jan 2011 at 20:08 UTC) »
Adventures in C++ compiler land

I've ventured into the g++ front end a couple of times recently (I usually only touch libstdc++ code) trying to fix some bugs. I haven't managed to get my patches reviewed, but as stage 3 has ended I'll have to wait until 4.6 is branched and then try to get them into 4.7

More clang bangin'

One of the goals/features of Clang/LLVM is faster compile times than GCC, so I think something's very wrong with my build (which I configured as a "Release+Asserts build"):

$ wc -l src/Order.cc
4107 src/Order.cc
$ time make CXX=g++ objs/Order.o
real    0m8.993s
user    0m8.483s
sys     0m0.339s
$ time make CXX=g++ CXXFLAGS="-O2 -DNDEBUG" objs/Order.o
real    0m12.111s
user    0m11.999s
sys     0m0.309s
$ time make CXX=clang++ objs/Order.o
real    2m11.608s
user    2m7.475s
sys     0m0.260s
$ time make CXX=clang++ CXXFLAGS="-O2 -DNDEBUG" objs/Order.o
real    17m22.577s
user    17m21.589s
sys     0m0.377s

Yes, that really did take 17 minutes at 100% CPU (on a 2.93GHz Xeon X5570) compared to 12 seconds for GCC.

One of the things I really like is that most of GCC's command-line options are supported. so I used -ftime-report to see where all that time is spent, but all the detailed stats are for the code generation stages, which is the only bit that isn't slow!

---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---
137.5871 ( 50.6%) 0.2380 ( 67.8%) 137.8250 ( 50.6%) 138.0570 ( 50.6%) Clang front-end timer
131.2420 ( 48.2%) 0.0610 ( 17.4%) 131.3030 ( 48.2%) 131.3707 ( 48.2%) LLVM IR Generation Time
3.1755 ( 1.2%) 0.0520 ( 14.8%) 3.2275 ( 1.2%) 3.2308 ( 1.2%) Code Generation Time
272.0046 (100.0%) 0.3509 (100.0%) 272.3556 (100.0%) 272.6585 (100.0%) Total

That was with a build from subversion a few weeks ago (trunk 121966) so I updated and got sensible times, although the optimised build is still slower than I expected:

$ time make CXX=clang++ objs/Order.o
real    0m7.380s
user    0m6.674s
sys     0m0.471s
$ time make CXX=clang++ CXXFLAGS="-O2 -DNDEBUG" objs/Order.o
real    0m17.667s
user    0m17.131s
sys     0m0.309s

I don't remember the earlier build being so slow a few weeks ago, so maybe some gremlins came and moved the files to a really slow bit of the filesystem over Christmas.

Using Clang on a large codebase did find a few bugs which GCC and Sun CC didn't object to (one notable feature is that clang++ found errors in templates which were never instantiated, which even EDG didn't find) and I also found a bug in clang, but one of the main reasons I wanted to try it was the static analyzer. Unfortunately it only works for C and Obj-C and trying to analyze C++ fails miserably. I guess I'll wait and try it again at a later date.

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