Prologin
2025
jeu, 02/02/2012 - 23:32 — LLB
> Ca s'appelle un langage de haut-niveau et des abstractions.
Quid du Java qui n'offres pas plus de construction de haut-niveau (je dirai meme moins) et qui offre moins de garanties
sur l'execution du programme ? Quid des LISP qui est bien haut-niveau et qui offre plein de garanties sur ce qu'il se
passe a l'execution ?
Certes il y a de ca, typiquement en assembleur on sait exactement ce qu'il se passe. Mais ce n'est pas tout.
jeu, 02/02/2012 - 23:32 — LLB
> Un développeur C reprochera la même chose au C++ :
Il y a quand meme une bonne difference entre PHP et C++ et entre C et C++. Je vais repondre a chaque point, meme si ce
n'est pas tres utile (puisque en effet chacun de tes points contient une part de verite.)
jeu, 02/02/2012 - 23:32 — LLB
> entre les objets de la STL
/me marmonne quelque chose au sujet de la standard thread library
Je ne vois pas le probleme avec les objets de la lib standard, leur but est d'etre abstrait. Forcement il y a autant de
garantie sur eux que sur les objets et fonctions d'une quelconque lib C et de n'importe quelle lib en general
d'ailleurs. Je dirais meme qu'il y a plus de garantie sur le fonctionnement de la lib standard que sur celui d'une lib
lambda.
jeu, 02/02/2012 - 23:32 — LLB
> la surcharge d'opérateurs
Alors, j'aime bien le coup du "quand tu fais a+b tu ne sais meme plus si c'est une addition", mais quand tu fais
"a.add(b)" ou "add(a, b)", tu ne peux pas le savoir non plus.
D'un point de vue C, cela ce rapproche de :
jeu, 02/02/2012 - 23:32 — LLB
> C'est pas toujours simple de savoir, par exemple, ce qui est copié et quand
En effet en C++, quand on fait function(object), on ne sait pas si object est copie ou non (selon si la fonction prend
l'argument par valeur ou par reference). Mais d'une part si on appelle cette fonction, on doit bien savoir ce qu'elle
fait et ce qu'elle prend en argument, donc ce n'est pas non plus difficile de verifier la presence d'une esperluette et
par ailleurs c'est plus une decision de l'appele que de l'appelant. Dans une moindre mesure c'est aussi present en C :
1 2 3 4 5 6 7 | typedef struct A { double v[42*42*42*42]; } A;
typedef A *B;
void f(A){} void f(B){}
int main(){
A a; f(a); // Ahah !
B b; f(b); // Bhbh !
}
|
jeu, 02/02/2012 - 23:32 — LLB
> les constructeurs implicites,
Oui mais c'est possible de savoir quand est ce qu'un constructeur (y compris non-explicit avec un seul argument) est
appele, les regles sont peut etre un peu complexe certes, mais elles existes.
jeu, 02/02/2012 - 23:32 — LLB
> les destructeurs, etc
La par contre je ne vois pas ou est le probleme (et comme a dit Ekleog, c'est meme plutot un point positif.)
jeu, 02/02/2012 - 23:32 — LLB
> "C'est chouette, en théorie. En pratique, les temps de compilation et les
> messages d'erreurs font que ce n'est pas toujours aussi bien qu'on le
> voudrait."
Ce n'est pas un argument, au sujet du temps de compilation, l'utilisation des templates n'est pas obligatoire, la plus
part des langages n'ont pas de mechanisme similaire mais sont tout de meme utilisables, c'est une possibilite offerte
par C++. Les messages d'erreurs dependent du compilateur (c.f. les sorties d'erreurs de clang).
ven, 03/02/2012 - 12:33 — Ekleog
> D'où les concepts, qui permettraient de simplifier les messages d'erreur en
> annonçant clairement ce qu'on veut. J'espère que ce sera bon pour la
> prochaine norme c++.
Ouais bon, il n'y a pas besoin des concepts pour simplifier les messages d'erreur.
ven, 03/02/2012 - 12:33 — Ekleog
> Et, pour les temps de compilation, c'est en partie possible à résoudre par
> les templates exportées
Pitie, tout mais pas ca, comment faire pire que les templates exportes ? C'est une blague, le mec qui a eut cette idee
doit aussi etre a la source de PHP et Java.
A ce sujet, je cite N1373 :
> Phantom advantage #2: Fast builds, reduced dependencies. Many users expect
> that export will allow true separate compilation of templates to object code
> which they expect would allow faster builds. It doesn’t because the
> compilation of exported templates is indeed separate but not to object code.
> Instead, export almost always makes builds slower, because at least the same
> amount of compilation work must still be done at prelink time. Export does
> not even reduce dependencies between template definitions because the
> dependencies are intrinsic, independent of file organization.
Voir egalement l'article du Sutter a ce sujet.
ven, 03/02/2012 - 12:33 — Ekleog
> ou (plus portable) par les instanciations explicites. Exemple : J'ai une
> paire de fichiers a.hpp et a.cpp ; je sais que a.cpp utilise MaTemplate. Je
> vais créer une instanciation explicite dans a_inst.cpp ; l'annoncer dans
> a.hpp ; et je n'aurai plus à compiler MaTemplate à chaque modification de
> a.cpp. C'est magique, non ? =D
Ca rajoute des dependences inutiles, a ne pas utiliser imho (a moins que le temps de compilation soit vraiment
vraiment VRAIMENT important.)
Donc, oui C++ est plus bas niveau que PHP c'est surement une des raisons pour les quelles il y a autant de garantie a l'execution, mais par rapport a d'autres langages PHP est (sur ce point la) bien mal place, contrairement a C++ imho.
