Reprise du message précédent :

 
bhen un type, comme int, float et compagnie

antp a écrit a écrit :   En C++ t'as toujours besoin de mélanger ça avec des char* C'est géré par le compilo, c'est pas une classe ou un template donc je suppose que c'est aussi plus optimisé (bien que je doute qu'on voie vraiment une différence de performance)

oula ! t'as fume ?
regarde bien la classe string.h (pas du C et pas celle de Visual evidemment)
y'a pas mal de bouts en assembleur dedans, c'est vraiment pas un truc de tapette et pas fait par des debutants
en plus quand tu passes en parametre une string, il ne la recopie pas mais passe simplement une reference (ca depend de l'implementation, moi je parle de la classe de SGI)
et puis c'est un template, tout est en inline
 
nan vraiment, le doute sur la rapidite de string n'est meme pas permis, c'est le dernier truc dont il faut se soussier en programmant en C++ !
 
et je confirme ce que dis kristoph, quand je faisais du C++ / gtk (une lib en C), j'utilisais toujours string, je convertisais au dernier moment en char * avec c_str(), quand j'appelais un truc gtk, je manipulais jamais de char *
donc l'excuse "j'utilise des lib qui supporte pas string" bof
c'est trop la merde les char *, faut les bruler, les lapider etc... (et ceux qui utilisent char * aussi )
 
c'est vraiment tres tres con que string n'est pas ete introduit des le debut de C++
d'ailleurs je comprends pas que en C ca n'est jamais existe alors que le Pascal est anterieur
d'ailleurs sur quelques points le Pascal est superieur au C : genre les references avec var
 
ouais enfin en 1967 y'a des gars qui programmaient tranquille en simula... comme quoi

tanguy a écrit a écrit :   [...] et je confirme ce que dis kristoph, quand je faisais du C++ / gtk (une lib en C), j'utilisais toujours string, je convertisais au dernier moment en char * avec c_str(), quand j'appelais un truc gtk, je manipulais jamais de char * donc l'excuse "j'utilise des lib qui supporte pas string" bof c'est trop la merde les char *, faut les bruler, les lapider etc... (et ceux qui utilisent char * aussi ) [...]

Mais c'est génial les char* suffit d'être rigoureux et jamais de problèmes ...

viiz a écrit a écrit :       BAh heureusement t'as vu combien tu la payes ta license de Visual

 
c'est pas parceque c'est cher que c'est bien
et c'est pas forcement bien parceque c'est beaucoup utilise
le compilo de visual pour le C++ est une MERDE IMMONDE, le jour ou ca rentrera dans la tete des gens ca sera vraiment la fete
d'ailleurs ca compile pas du C++ mais du MS C-- tellenent c'est pitoyable, surtout venant de la 1er entreprise au monde de logiciel
 
et puis tu as mal lu mon message, j'ai ecrit :
"regarde bien la classe string.h (pas du C et PAS celle de Visual evidemment)"
 
je me demande si ton msg etait pas ironique tellement c'est gros...

DarkOli a écrit a écrit :   Mais c'est génial les char* suffit d'être rigoureux et jamais de problèmes ...

ba ouai y'a ka, c'est tellement evident
 
le nombre de buffer overflow que l'on voit...
le temps perdu avec ce truc...
 
mais bon tu dois surement etre meilleur que les autres,
quand tu utilises char * t'as pas de buffer overflow, pas de pb de securite, pas de segfault, pas de fuite memoire
bref la classe quoi
 
c'est comme les gars qui nous expliquent que les pointeurs c'est super facile et que ceux qui y arrivent pas c'est des nullos, il suffit juste de mettre delete dans le destructeur...
sans les mains, meme pas besoin de memory checker !
 
les problemes quand on veut pas les voir, ba on les vois pas, c'est aussi simple que ca...

viiz a écrit a écrit :     Moi ce que j'aime aussi c la lisibilité que ca apporte de pourvoir additionner des patates avec des choux fleurs       Code : Inc(x); Dec(z); y := x * z; Inc(x); Dec(z); Inc(y);

 
Evidement, c'est tellement plus lisible de faire ca :
 

 
que d'avoir ça:

par exemple Borland qui utilise l'opérateur << pour émuler les "sets" du Pascal, ça fait un truc un peu bizarre

tu préfère te branler la cervelle avec des outils de merde comme visual c++ peut etre. Moi personnellement je vais à la facilité, t'a qu'1 vie. Et puis tu dois etre opérationnel rapidement. Il faut pouvoir developper une IHM comme tu veux sans avoir a ce poser la question comment on fait pour mettre une image dans un bouton par exemple. Avec Windev au moins c'est simple, t'as pas a te prendre la tête. Mais s'il y a des idiots qui préfèrent réfléchir à fond la caisse et bien tantpis pour eux. Mais moi j'ai choisi de travailler facile. De toute façon si tu crois que tu va te faire un meilleurs salaire parce que tu travaille sous autre chose que Windev, alors là tu te plante.

Joli déterrage d'un topic d'il y a 6 ans...

c'est vrai ça merci

Déterrage 2010    
 
Bon, on est à la version 15 du bordel, c'est toujours aussi pourrave ?

 
Cat E&E t'aura peut-être plus de chance.  
Enfin la chance... Ca n'existe pas.
Faut que tu fasses ta place.
Pourquoi t'apprend pas un vrai langage  

 
Et moi je up.

 
 
Ah bah bravo

Est-ce que je dois arrêter de faire du Java et passer à WINDEV?
 
   

Je ne vois pas le rapport ..

Pose toi la même question sur PHP.
 
Tu vois la réponse maintenant? C'est la même

 
Attention, quand je dis "pourrave" c'est par rapport à ce qu'en disent les personnes qui bossent dessus... Je n'ai pas d'apriori...
 
Mais idem qu'au dessus, je vois pas le rapport avec PHP ???????????  

 
Windev je trouve la syntaxe absolument atroce, surtout en français (la déclaration des variables est à se pisser dessus de rire pour moi), mais faut être honnête, c'est un RAD qui vise surtout à être utilisé de façon graphique (binding...), pas à pisser des mètres de code à la main.  
J'ai beau ne pas aimer, certains dans mon entourage s'en servent, et quand je vois ce qu'ils arrivent à en tirer comme applis riches en quelques jours (génération de rapports, extractions diverses, connectivité, lecture de codes barres, interface relativement jolie sans efforts...) je me dis que le truc a quand même sa cible et son avenir. Simplement ça n'est pas un outil à mettre entre les mains d'un techos habitué à enfiler des pointeurs et pondre des diagrammes de classe...