Older blog entries for lerdsuwa (starting at number 62)

Part 1 to 4 of friend class injection is committed to GCC. Part 5 (name hiding, which is almost ready) and 6 (friend of class template, which still has some issues left) are very likely to be delayed until GCC 4.1. Now it's time to fix regression in preparation for GCC 4.0 release.

Finally my new Athlon64 system is setup. It's a 3200+ with 2.2 GHz. CPU and mainboards are quite in shortage and much harder to find compare to a Pentium 4 3.2E system. Got MSI K8N Neo Platinum mainboard as another MSI model is the only other choice. There is about 2x speed boost for GCC bootstrap and regression test :)

The friend class name injection work should progress a lot more but it turned out codes in libjava are relying on the current broken behavior. A patch to fix friend class usage went into libjava earlier, and now it appears I need to write a few more patches to fix friend function usage. After then, my friend class name project can proceed.

Looked at template specialization of nested class again, and just like the last time, it is returned to the shelf. :(

On the bright side, I am getting a new machine next week. It should be an Athlon64. :)


The member class as template friend patch is finally committed October 20. This lags the feature member function as template friend by almost 11 months (committed November 22, 2003). Now I am working on friend class name injection. I wonder when friend function name injection will be finished :)


Finished some friend class injection work (Patch 1 and Patch 2). Now I have to decide which issue to fix next. One is about name injection during template instantiation (Bug 4403). The other is hiding injected name (Bug 1016).

Yuck! the attempt to fix friend lookup bug failed because it was based on lookup_tag function. It could only find types and completely ignore typedef and template type parameter, so it can't diagnose invalid codes like:

  template <class T> class A {
    typedef int U;
    friend class T; // Invalid
    friend class U; // Invalid

Now I have to figure out the implementation based on lookup_name function which will find all such names. And the result will have to be checked for validity. :(

Start working on GCC friend name lookup and name injection issues such as bug 14513. The current fix for this bug looks promising a patch could be ready in a few days.

This is unlike the previous one where I spent about a week playing with template specialization of nested class (bugs 4882, 13088, etc.). They turned out to be a real pain. Those are back to the shelf.

The patch member class as template friend is finished and posted. I ended up using typename for both code cases mentioned in the previous diary:

template <class T> class C {
  friend class D<T>::X;
  template <class U> friend class D<U>::Y;
I used the fact that, after instantiation of C such as C<int>, the first one become template-parameter non-dependent while the other still depends on the template parameter U.

After some experiment, using typename for internal representation is not enough. It cannot distinguish between the following two cases:

template <class T> struct D { ... };
template <class T> class C {
  friend class D<T>::X;                    // use typename here?
  template <class U> friend class D<U>::Y; // also use typename?
My latest idea is to invent a new tree node to represent the second friend.

I find myself reviewing yet another C++ book. This time it's a new edition, not a new book. So it's already in a good shape and doesn't need much comment. This makes my work a lot easier.

For GCC, I just get back to member class as template friend feature as in code like

class C {
  template <class T> friend class A<T>::X;
One more step is accomplished: checking class-key syntax error for codes like

template <class T> class C {
  friend typename T::X;     // Syntax error
  friend typename T::X f(); // OK
is moved to parser. The new friend feature requires the same internal representation as 'typename' so the diagnostics of such error cannot be performed in later stages. Next step: making friend codes able to handle the typename representation.

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