Reprise du message précédent :
en tout cas, ici le '+' marche très bien, merci pour lui.
 
(bon on l'utilise pas énormément, mais ça arrive)

Je découvre le C++ en contexte réel, là (riez pas ), et je prends mon pied avec l'objet, ça fait un putain de bien, j'sais pas si je pourrais retourner au C comme ça. Et j'aime pas le C++.

J'crois je vais me mettre à programmer chez moi. J'ai fait plusieurs tentatives mais j'ai toujours eu des crises de flemmes qui font que ça n'est jamais allé bien loin, la dernière fois ce fut quand j'ai découvert l'interface (touffue) de VS Express.

C'est vrai, j'avais oublié ce cas-là bien pourri...
 
Apparemment, maintenant, la recommandation, ce serait strncpy_s

Mais putain, peine de mort quoi!
Elmoricq a parfaitement bien résumé la situation: on ne sait *rien* sur la chaîne destination à la fin d'un strncpy. On ne sait pas où elle finit, quelle taille elle fait, s'il y a un zero à la fin, etc. Bref, une fonction inutile.  
 
Encore, snprintf, je veux bien, mais strncpy quand on fait du C++, c'est vraiment demander les emmerdes avec un grand A.

Ouais le client a un centaine de weblo 8.1 donc il va pas passer à une version 9 voire 10 comme ça.
Sans compter le portage du code et des mois de tests.

 
Ben forcément si. Si on utilise strncpy, c'est bien parce qu'on est censé savoir que c'est une chaîne de caractères, donc avec un '\0', sinon autant utiliser memcpy.
Mais moi je parle de C, là, pas de C++, sinon j'utilise les string comme tout le monde.

Oui mais justement, strncpy() n'a strictement aucun intérêt par rapport à memcpy(), puisque dans les deux cas, tu dois vérifier si source n'est pas plus grand que cible pour poser, le cas échéant, un caractère null en fin de chaîne destinataire.

Mieux vaut utiliser strncat() lorsque l'on est sûr que la chaîne débute par un '\0', ou plus simple, s'en tenir à snprintf() et ne pas se prendre la tête.

pendant que vous débattez de comment on concatène des chaînes en C/C++, ici on construit un générateur automatique de tests en java si ça vous ennuie pas

Va mourir.

Hmmm, m'ouais c'est vrai.
Moi, je crois que je faisais un truc du genre (en embarqué)

strncpy(dest, src, sz);
dest[sz-1] = '\0';

Comme ça, réglé, quoi qu'il arrive. Evidemment, dans ce cas, on ne garantit pas l'intégrité du message d'origine, puisqu'on risque de perdre le dernier caractère ou plus...
Tant pis pour celui qui appelle la fonction avec la mauvaise taille.

nan mais notre truc marche justement pas mal pour tester des systèmes qui concatènent des chaînes de caractères

De toute façon, un passage sous Valgrind ou autre s'impose.

Si tu savais le nombre de programmeurs java que je vois passer en entretien et qui ne savent pas utiliser StringBuffer. Mais bon, au moins, il n'y a pas mort d'homme comme avec strncpy (d'ailleurs, je comprends toujours pas qu'en 2007 on code en C ANSI et non pas en C99 ou en C++ . )

mais t'es has-been
 
on a interdit StringBuffer ici
 
c'est passé de mode
 
comme les startups qui font du push

Et moi je peux me targuer de n'avoir jamais laissé trainer un dépassement mémoire dans mon code C/C++ et sur ce, je vous merde cordialement

(bon ok, j'ai commis des tapées d'autres bugs...   )

/o\ p'tain, pourquoi, squoi qui est pas bien ?  

http://forum.hardware.fr/hfr/OSAlt [...] 5972_1.htm
 
zut, on l'a pas eut ici

Hmmmm. Insérer ici une référence à StringBuilder, Weblogic, JDK 1.4, etc.

StringBuilder ftw?

le StringBuilder la tendance. because StringBuffer c'est synchronisé.  
 
Et même souvent je gueule pour que les gens mettent des simples Writer+StringWriter à la place, mais l'IOException est un peu repoussante.

C4EST LE DELUGE §§§

http://java.sun.com/j2se/1.5.0/doc [...] ilder.html
 
Buffer est synchronisé d'office, ce qui n'est pas intéressant 99% du temps

mais Weblogic c'est ni pojo ni un clone de RoR
 
Lam's tu as compté tes points de retraite ? il faudrait y songer

j'pense même 100% du temps parceque même en multithread, se synchroniser là-dessus ça sent la morue de toutes façons.

99.9999% du temps alors

Chuis sûr qu'on peut trouver un truc complètement stupide dans lequel n threads append sur un StringBuffer unique et m threads toStringisent dessus régulièrement

Une genre de version débile d'une Producer/Consumer queue

Je suis encore vert, j'ai beaucoup de sève qui coule. Tu ne te débarrasseras pas de moi si facilement.
(sinon, côté nouvelle techno, j'essaye d'initier très doucement mes collègues à Python. On peut pas dire que ce soit un succès pour le moment, entre ceux qui préfèrent scripter en Java, ceux qui font des programmes avec fonctions et boucles en csh, et les 2 fondus de perl...).

pourquoi faire en 5min ce qu'on peut faire en 5h

 
(ils viennent de sortir la RC3 de Jython 2.2, et apparement il y a un mec qui bosse pour intégrer Jython à Spring pour créer des beans reloadables jesaispasquoi, le truc qu'on peut déjà faire avec Groovy et qui permet de pas avoir à redémarrer sa webapp dès qu'on touche un fichier, si ça peut te servir dans ton argument)
 
(ps:

faut les abattre vite avant que l'infection s'étende au reste du troupal)
 
PPS: j'viens de screencaster la config du CMS de la boite sur ma machine locale (mon mac ) pour pouvoir la refaire la prochaine fois... 5600s
Va faloir que je bosse sur un script de config/install/deploy moi

groovy, quel interêt par rappotrt à jython ?

Bah c'est pour remplacer ce qu'un gars a fait en scriptant en C++ (et qui se fait en 5 lignes de code avec ElementTree).

Chais pas, j'en ai jamais vu.

 
Et votre topic d'élite, il sert rien qu'à se branler et non plus à dégorger blabla@prog de vos discussions de javateux?

 
C'est drole, mais nous, on a une autre politique. Touujours utiliser les objets synchronisé, et le jour ou le client gueule a cause de la vitesse, faire du profiling pour voir ceux qui posent vraiment problème.

T'auras quand même du mal à le voir au profiler

Oh que non.

Hardware problem sir !

nous c'est l'inverse : vu que de toutes façons un objet synchronisé n'est jamais synchronisé aux endroit que tu veux (à part les nouveaux truc de java 5), on ne prend jamais un truc synchronisé et on synchronise nous-mêmes à la main des blocs de code plus grands.

Sauf que si ton objet synchronisé synchronise là où ça n'a aucun intérêt, ça ne va pas trop t'aider. Bien au contraire, puisque ça va te donner un sens de sécurité ("mes objets sont synchronisés donc je risque rien) bien mal placé.

C'est d'ailleurs très précisément ce qu'impliquait nraynaud quand il a dit:

edit:

Dans les deux cas, l'important, c'est que ça tienne et que le nombre de bugs soit minime.