michael_acreall a écrit 5 commentaires

  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.

    C'est pas la STL qui a un problème c'est l'usage que t'en fait.
    std::list est une liste chainée elle est très perfomante quand il s'agit d'ajouter ou de retirer des éléments à la liste.
    Dans le cas que tu as écrit le plus rapide est d'utiliser :

    static const int TAILLE = 10000000;
    std::vector lst = std::vector(TAILLE);

    qui te crée un tableau de taille 10000000 donc y a plus d'allocation, et les itérateurs sont très rapides puis que ceux sont alors des entiers.
    Pour conclure :
    Le C++ est plus rapide que c# ou java mais beaucoup plus difficil ;-)
    Sa force est dans la métaprogrammation (c.f. la bibliothèque boost) et les STL (en créant ses propres straits on fait du placement d'objet ce qui n'est pas possible en java).
  • # Subversion vs GIT

    Posté par  . En réponse à la dépêche Le basculement de KDE vers Subversion est terminé. Évalué à 1.

    Subversion étant maintenant au point depuis plus d'un an, on peut se demander si les raisons ayant poussé Linus Torvald à développer GIT sont bien fondées ?
    Puisque subversion dispose d'une architecture en couche,
    n'aurait il pas été possible de remplacer l'attaque de la base de donnée berkley par l'attaque du file système ?
  • # A quand une version open source ?

    Posté par  . En réponse à la dépêche Objecteering/UML 5.3.0 est sorti sous Linux x86. Évalué à 10.

    Pour avoir évalué les versions précédentes je peux dire que ce modeleur UML est bien fait, mais on peut lui reprocher les points suivants:
    Code propriétaire.
    Utilisation de Ilog views (sur Linux c'est un peu fastidieux).
    Difficile de lire le code XMI d'autre modeleur (Mais parait que tout va changer avec UML 2.0 (TM))
    On ne peut pas exporter les documents au format OpenOffice (c'est Word ou rtf)
    La démarche MDA (TM) suppose de tout gérer dans le "repository" du logiciel et il devient fastidieux de gérer la conf dans Subversion (il y a des plugins pour cvs).
    Pas de génération pour python (d'ailleurs si quelqu'un connait un modeleur pour python?)

    Par contre le support technique est à la hauteur, et je trouve le modeleur facile à utiliser même s'il n'est pas beau graphiquement.

    Les alternatives libres les plus intéressentes que j'ai trouvées sont:
    ArgoUML (http://www.argouml.tigris.org(...)) ecrit en java
    Umbrello (http://www.umbrello.org(...)) écrit en C++ et utilisant QT
    Mais hélas, ils leurs manquent des diagrammes et/ou sont instables.

    Peut être que lorsque l'OMG aura sorti un "shema" pour XMI et non une DTD on verra fleurir d'autres alternatives (avec UML 2, l'OMG devrait utiliser SVG pour décrire graphiquement les diagrammes, pour l'instant chaque éditeur fait ce qu'il veut).
  • [^] # Re: Java Generics vs. C++ Templates

    Posté par  . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.

    Je me demande si Java pourra (dans Java 6 ;-) ) prendre en compte les paramètres par défaut des templates (ex: template<int A = 0> ... ) et les spécialisations (ex: la seconde structure Fact du code d'exemple).
    Dans l'état actuel, je n'ai pas regardé si le fait d'instancier un template génère un fichier .class correspondant à la nouvelle classe, ou si comme j'ai l'impression il ne s'agit que d'une bidouille de la JVM.
    Quelqu'un sait comment ils ont impléménté ce bidule??
  • # Java Generics vs. C++ Templates

    Posté par  . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 4.

    Sur le site de Sun on peut lire "A C++ template on the other hand is just a fancy macro processor;"
    Pas seulement, les templates ont ouvert la méta-programmation "statique" à C++.
    En C++, il est possible de créer des types "statiques" conditionnels, C.f. la bibliothèques BOOST sur boost.org, ou le parseur Spirit qui permet ainsi de faire le même boulot que Lex/Yacc directement au moment de la compilation.
    L'emprunt partiel des template à C++, fait par Java ne permet pas de faire les choses suivantes:

    #include
    /**
    * Structure permettant le calcul d'une factorielle lors de la compilation
    * Calcule récursivement la valeur de la factorielle
    * Le code final ne contiendra que le résultat final (un entier)
    */
    template <int N>
    struct Fact {
    static const int m_Value = N * Fact< N - 1 >::m_Value;
    };
    /**
    * Condition d'arret du calcul de la factorielle
    */
    template <>
    struct Fact<0> {
    static const int m_Value = 1;
    };

    /**
    * Exemple de fonction IF en méta programmation
    * On peut remplacer les types de A et B par des classes voire d'autres templates
    * Ici on traite le cas True
    */
    template <int A, int B, bool BOOL>
    struct IF {
    static const int m_Value = A;
    };
    /**
    * Traite le cas False
    */
    template <int A, int B>
    struct IF<A, B, false> {
    static const int m_Value = B;
    };

    int main() {
    int fact10 = Fact<10>::m_Value;
    std::cout << fact10 << std::endl; /* fact10 est remplacé par 3628800 lors de la compilation */
    static const bool VAL_TRUE = true;
    static const bool VAL_FALSE = false;
    std::cout << IF<2,3, VAL_TRUE>::m_Value << std::endl; /* IF<2,3, VAL_TRUE> est remplacé par 2 */
    std::cout << IF<2,3, VAL_FALSE>::m_Value << std::endl; /* IF<2,3, VAL_TRUE> est remplacé par 3 */
    return 0;
    }