Re: [Texmacs-dev] [Announce] nogencc-15 released

[Joris van der Hoeven]

> > mais j'ai un peu de mal à comprendre ce que tu as voulu
> > faire dans ce fichier très particulier test2.cc.
> > Ca serait donc bien que tu m'aides un peu et que l'on en discute.
> > Par exemple, je ne comprends pas le pourquoi de déclarer
> > les fonctions test1/7 comme des templates.
> 
> Ha! I admit that part *is* tricky.
> 
> In the original code, some of those functions where compiled
> conditionally depending on wether the "divisible" symbol was defined.
> That is required because those function use some operators which are
> not defined for all types.
> 
> To provide support for this feature in C++ we must templatize those
> "conditionnaly compiled" function. Here we use the feature that no
> semantic check (not even symbol lookup) is performed on templates
> which are not instanciated. That trick is reminiscent of another trick
> called "compile-time dispatch" which is used where I defined local
> structs called "internal".
> 
> Those functions which did not need conditional compilation were also
> templatized to provide a uniform interface.
> 
> A great book which made me discover those features (and much more) is
> "Modern C++ Design" by Andrei Alexandrescu. I am sure after you read
> that book you will change you mind about templates. They provide a
> real metalinguistic facility, and it is built into the language.

OK, voici les corrections à faire :

1. La ligne 222 dans relaxed.cc devient

  h->eq= (series<C> ((new aux_inv_series_rep<C> (g))) * series<C> (h)) << 1;

2. La ligne 289 dans relaxed.cc devient

  return internal::log(f, has_special_functions<C>::value_as_type());

Toutefois, ça me génère des segfaults à l'éxécution.
Tu peux vérifier que les segfaults disparaissent si
on compile sans optimisation (il faudrait que tu me donnes
quelques instructions sur comment compiler sans optimisation
et/ou avec information pour gdb).

> > Aussi, étant donné
> > que l'on est passé aux templates, on pourrait peut-être remplacer
> >
> >     #define series<int_mod<1234577> >
> >
> > par
> >
> >     #define series<CST>
> >
> > Est-ce que c'est permis ? Peut être qu'il serait encore mieux de faire
> > un
> >
> >     typedef int_mod<1234577> CST;
> 
> I prefer that latter form, but I did not make the change for fear you
> tag them as unecessary.

Please use the typedef form, which seems the best solution to me too
(I probably could not do the same thing before for some reason).

> > > Il s'agit très probablement d'erreurs de résolution de surcharge qui
> > > sont dus à la place particulière des templates dans l'algorithmes de
> > > résoltion de surcharge du C++.
> >
> > Tu peux nous exmpliquer brièvement quels peuvent être les problèmes
> > avec la résolution de surcharge en relation avec les templates ?
> > (Désolé, mais je n'ai pas encore eu le temps d'acheter le livre
> > que tu m'as conseillé...)
> 
> The probleme here is that operators are defined as
> 
>   template<class C> series<C> operator * (series<C>, series<C>);
> 
> implicit_but<C> does not inherits for series<C>, in the previous code
> the overload resolution was done by implicitely using
> implicit_series_C::operator series_C (). But "if a template function
> argument has been determined by template argument deduction [which is
> always true for operator used in infix style] that argument cannot
> also have promotions, standard conversions or user-defined conversion
> applied." (TC++PL3 section 13.3.2).
> 
> That could be fixed by defining something like:
> 
>   template<class C> implicit_series<C>
>   operator * (type_x f, type_y g) {
>     return series<C>(f) * series<C>(g); }
> 
> where type_x and type_y are any combination of implicit_series<C> and
> series<C>. But one clearly see that approach does not scale.

OK, I guess that we have to live with this absurdity of C++.

> > > Le correctif simple est d'effecture des
> > > cast explicites vers SERIES, le bon correctif est de déplacer les
> > > opérateurs sur series<C> pour être des membres de la classe
> > > series<C>.
> >
> > C'est précisement le genre de correctif que je déteste :
> > je n'aime pas voir les opérateurs sur series<C> comme fonctions
> > membres. Enfin, si on ne peut pas faire autrement...
> 
> I know you do not like that, but that is the right way to do it.
> 
> The point here is that when (say) operator* is a member of a template
> class, the template parameter is determined solely by the right hand
> type of the member access operator. So the member operator parameter
> will not contribute to template argument deduction, and thus will be
> promoted, converted, etc...
> 
> To understand this you have to recall that
> 
>   A * B; // * is an overloaded operator defined in the class of A
> 
> is equivalent to
> 
>   A.operator*(B);
> 
> Actually, it would be better to have implicit_series<C> inherit from
> series<C>, and consistently use passing of counted pointer parameters
> as const references (to preserve pass by value semantics as well as
> polymorphism). But that is quite a heavyweight restructuring.

OK, we'll talk about that later.

Please take care of what has been said above.
In the meantime, I will rewrite some help/webpages and
make some other final changes for the nogencc release.