Donc en gros, si je résume bien, pour permettre à une personne de recevoir une aumône, cette dernière passe par une maison d'édition pour avoir une visibilité de 6 mois, et après jusqu'à 70 après la mort de cette personne, personne ne peut profiter de l’œuvre.
Yep y'a pas à dire faut vraiment conserver ce système, il parait tout à fait correct.
PS: je ne parle évidemment pas des auteur à succès, qui de toute façons pourraient vivre largement de leur art si la protection n'était que de 10 ou 20 ans après publication de l’œuvre.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Yep, c'est tout le problème en informatique à force de parler mi franglais mi anglefranc on nous regarde bizarrement lorsque l'on parle dans le train de string ou de subtilité digital…
Alors que si on se contentait du Français on parlerai de chaine de caractère et dépassement de tampon, les gens nous regarderai enfin normalement… ou pas ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Putain faut pas déconner une recherche sur n'importe quel moteur de recherche te donne la réponse!!!
Si tu ne prends pour argent comptant que ce qui semble sourcé ou qui va dans ton sens de pensé on est pas rendu. Une info t'interpelle?
Sors toi les doigts du cul essuies-les et fait une (ou deux) recherche, et enrichi la discussion avec tes résultats, quitte à commenter sur ta surprise.
Si la recherche est infructueuse, là tu peux poser la question.
Une discussion est censé être un échange, pas un champs de bataille où on se bat à coup de référence.
De toute façons les pointeurs sont bien plus instructifs ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Il est toujours difficile de dire ce qui aurait été, mais on sait au moins ce qu'ils ont voulu faire (nommer des généraux de Vichy, nous interdire de posséder notre monnaie (remplacement du franc, par des dollars dépendant de leur bon vouloir, en Italie cela à provoqué une chute de leur monnaie).
Cependant cette administration américaine aurait été temporaire et limitée pour juste relancer le pays.
Non c'était pour nous 'protéger' contre de Gaule, et siphonner nos colonies, relancer notre économie était la façade.
Je n'aime pas cette façon de voir les choses. Que ce soit les russes ou les américains qui se mettent en avant dans le conflit. Les deux ont eu un rôle majeur, c'est indéniable, essayer de quantifier qui a le plus été utile est je pense assez ridicule.
En fait sans les russes on parlerai allemand, sans les américains, on parlerai russe, sans le concours de Churchill on parlerai anglais (quand les américains sont venus ils avaient déjà les projets d'administration dans leur sac). Bref, je suis très content que tout ce petit monde ait contribué à la victoire.
À la fin de la guerre, si on sondait la population Française pour savoir qui avait le plus contribué à la victoire des alliés, le réponse était très majoritairement l'URSS, avec le temps, et les films, la perception à changé. on peut même dire que les deux ont échangé leur place dans la tête des Français https://www.ifop.com/wp-content/uploads/2018/03/3025-1-study_file.pdf
Forcément cela occulte un peu dans notre mémoire collective l'effort soviétique qui concernait des zones où nous n'y sommes pas.
Ce qui est surtout marrant, c'est que ceux qui ont vécu le débarquement, justement pensaient à l'inverse de notre vision romancée, que dis-je holywoodé. Hors on pourrait croire que la proximité de l'action leur ait donné un prisme favorable au débarquement.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
autre points que je n'avais pas remarqué, dans l'ancienne version les champs from et to sont placés chacun sur une ligne et prennent toute la largeur de la fenêtre, c'est un très bon point, dans la nouvelle, je vois juste un champ from, et on a même pas le chemin complet.
De plus ça tronque la fin, ne laissant que le début de visible, or généralement le plus déterminant c'est la fin ;)
Il faut reconnaitre quand même que la nouvelle fenêtre est plus jolie et fait moins austère.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Je n'utilise pas super-copier, généralement mes copies se font en ligne de commande la résistance au changement c'est pas moi !!! :P
Le soucis que je vois sur la nouvelle, c'est qu'elle affiche par défaut des infos dont on se contrefiche royalement et empiète d'autant plus sur l'écran. Le vieux winamp était un exemple de compactitude et de simplicité, vlc se contente de peu.
C'est un peu le reproche que je fais à certains ide qui inondent le développeur d'info qui ne lui sont utile que ponctuellement (arborescence de fichier/classe/projet/module) structure du fichier, plugins actif, gestionnaire de version. et on se retrouve à coder sur un timbre poste.
Alors oui ce sont des information extrêmement importante, mais pas en permanence. Dans le cas de super copier, ce qui est "utile" (dans l'ordre de préférence
* c'est le temps restant
* le fichier copié
* le temps restant pour le fichier copié
Ces 3 infos permettent de savoir à partir de quand on peut utiliser un ficher (ou tous les fichiers)
Ensuite, viens les infos moins pertinente mais utile quand même
* le débit actuel, ça permet de surveiller facilement la perte de lien
* liste des fichier copiés / à copier
Et enfin le détail
* le débit moyen
* historique de débit.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Le soucis avec ça c'est que parfois tu veux bien une égalité de référence (is, ou == en java), mais que comme le langage décide que certains entiers ou chaines de caractères pointent vers la même…
Moi ce qui m'affole, c'est que le comportement change sur des valeurs arbitraire (-6), ajoute à cela que certaines sont immutable, et d'autre mutable, selon les contextes (paramètres par défaut)…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Il y'en a une, si tu veux parler d'une graphique, j'aurais tendance à dire que ce n'est pas le boulot du langage de devoir maintenir une bibliothèque graphique;
il suffit de voir une appli java utilisant les composant de base pour se dire que c'est moche!
il suffit de coder en java sur plusieurs années pour se retrouver avec des morceau noté comme dépréciés
il suffit de coder en java pour se rendre compte que l'interface de swing est dépassée
Bref, le coeur du langage doit se concentrer sur les outils de base.
Pour le graphique, réseau, xml, Qt fait très bien le taf ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
pour un fichier binaire j'éviterai d'utiliser int, short ou long mais int32_t, int16_t ou int64_t qui eux te garantissent la taille ;)
Ça m'a un peu étonné de ne pas pouvoir faire ça, pour un langage pourtant si puissant en terme de templates.
tu peux le faire mais avec le bon itérateur :
std::vector<int>bufferInt((std::istream_iterator<int>(file)),std::istream_iterator<int>());// ou bufferInt.insert(bufferInt.end(),std::istream_iterator<int>(file),std::istream_iterator<int>());
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
mais j'espérais qu'une version moderne d'Eclipse soit plus avancée que ça en C++
Eclipse est à la ramasse sur le java par rapport a intelliJ,
Eclipse est à la ramasse par rapport à qtCreator, vsCode, et même Clion sur tout ce qui a trait au c++.
Eclipse est beaucoup plus lourd que les 4 cités ci-dessus; Par contre, il est multi-langage, et y a une tetrachié de modules
Par ailleurs c'est une mauvaise idée de naviguer dans la stl, en tout cas celle de g++, le code est difficilement lisible, et tu pourrais prendre des choses comme acquises qui ne font pas partie de la norme.
Il y a certaines fonctionnalités que je ne trouve pas alors
Tu peux donner des exemples ? car à part l'introspection, j'ai du mal a voir ce qu'il manque par rapport au java (au niveau des capacités du langage)
Moi ce qui me manque quand je change de langage (généralement java), c'est la non maitrise des const, impossibilité de choisir entre valeur/référence/pointeur, impossible de redéfinir les opérateurs (simplification d'interface), les template…
Ça m'est totalement obscur. Voir ça en 2019 m'a fortement déçu sur l'évolution de C++ et de son écosystème. Et le bout de code en exemple, je l'ai trouvé sur le net. Tout seul je n'aurais pas su l'écrire,
Je t'invites a écrire sans aide un appel de java vers c++, ou java vers ada, ou ada vers pascal !
Clairement le morceau de code que tu as donné est un interfaçage de C vers C++; et je dirais même un mauvais interfaçage; on récupère un pointeur de pointeurs et on va stocker les pointeurs (probablement des chaine de caractères) dans un vector, le tout sans aucun commentaire sur l'ownership (qui libère quand comment) (ici j'ai l'impression que c'est la bibliothèque qui le fait, mais ça ne dispense pas d'un commentaire); bref, si je suis relecteur de ce code c'est un rejet direct.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Le programme a un comportement indéfini, et contient donc un bug.
Je ne dis pas le contraire, j'aurais probablement expliquer plus en détail ma première réponse.
Le fait que ça affiche le bon résultat pour toi n'est que par chance. Sso ou pas.
La chance n'a rien à voir la dedans; c'est la façon dont est implémenté la stl dans g++; clang; si , par exemple te fait une erreur à la compilation. Et je peux relancer le programme 1010 fois, j'aurais toujours le même résultat.
C'est typiquement ce genre de bout de code qui peut tourner 20 ans sans broncher, passer les versions de compilos, parce que quelqu'un à voulu faire du printf debugging, et n'a jamais remis le tout sur une ligne, et planter royalement le jour où tu rajoute 3 caractères dans un fichier de conf.
Si une version avec une "chaine vraiment trop longue pour rentrer dans la short string optimisation" là donner le 'bon' résultat est du à la chance.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
tu ne réutilises jamais un pointeur sur un objet désalloué
On est bien d'accord; mais tu as demandé la sortie de ton morceau de code; je te la donne, et je t'explique pourquoi ton code est prévisible; on est dans un comportement indéfini très bien défini du moment que la sso est présente ; j'y peux rien si tu ressors les exemples d'il y a 20 ans sans te soucier de voir si ils sont d'actualité.
tu peux avoir une interruption qui va modifier la stack entre-temps
Dans ton programme ? Je demande à voir!
tu peux avoir ta bibliothèque qui va effacer la zone mémoire pour des raisons de sécurité
Tu continues de changer l'énoncé au fil de l'eau ;) Tu peux aussi avoir une bibliothèque qui ne recouvre pas la mémoire.
CC sur Solaris, il y 15 ans t'aurais donné le même résultat; on a même du code critique qui a tournée pendant des années avec des comportements indéfini, et ne c'est pas propre au C++ …
{[...]char*b=a// free(a);returnb}
On s'est rendu compte de la blague en passant sous linux + gcc, que des chaines vides à la place des résultats ;); le pire c'est que le code de duplication avait été commenté en disant qu'il ne servait à rien…
Tu peux aussi redéfinir tes new/delete
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Honnêtement, ça aide beaucoup de connaitre le besoin (en plus d'écarter les éventuels 'faites mes devoirs', ou 'faites mon job')
Une autre solutions (sans ligne de commande), c'est ouvrir tous les fichiers dans un éditeur et de faire un remplacer dans tous les fichiers; certains éditeurs le permettent, mais ça va dépendre du nombre de fichiers et de leur taille ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
LinuxFr a toujours été un lieu de débat philosophique, de discussion sur les licences et autres sujets liés (DRM…), de moto, de bronsonisation… en plus de la dernière version de Fedora avec une liste de numéros de version des logiciels.
Tu pose une question, je répond, va pas changer l'énoncé ensuite, même valgrind ne bronche pas sur le premier exemple.
D'un point de vue technique (norme) le pointeur renvoyé c_str() (ou data()) reste valide tant que la chaine initiale n'est pas modifié. La chaine est détruite à la fin de la ligne const char *c1= s.substr(2).c_str(); , et la ligne suivante donne donc théoriquement un comportement indéfini;
cependant au vu de la taille de la chaine résultante, "123", on est dans le cas de la short string optimisation, ce qui fait que la totalité de la string est stocké sur la pile; non partagé avec qui que ce soit; et donc en absence de nouvelle allocation locale, on y touche pas; donc la mémoire est toujours valide ;) Ce qui fait que ton cas est parfaitement prévisible ;)
évidemment, si on agrandi la chaine résultante pour ne plus bénéficier de la short string optimisation, on n'alloue plus sur la pile mais le tas, et là tu vas faire broncher valgrind ;)
Ensuite du C dans du C++, c'est fréquent; par contre je le redis : on ne passe en char* qu'au dernier moment ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
tu as tout faux, même si ton compilateur en a tiré qq chose
Je connais le problème des pointeur / référence sur temporaire; il se trouve que dans un environnement simple ton test donnée ne va jamais planter parce que le recouvrement de mémoire n'est pas fait, même valgrind ne râle pas, c'est pour dire! :P
Le vrai soucis c'est que tu combine du C (stdio.h) avec du C++. normalement, tu ne passe en c_str qu'au dernier moment.
sed -r 's/monNomDeDomaine[.]fr/monNouveauNomDeDomaine.org/g' -i.old $(find -iname '*html' -or -iname '*md')
en gros va remplacer toutes les chaines monNomDeDomaine[.]fr par monNouveauNomDeDomaine.org dans tous les fichier se terminant par html ou md.
dans le cas où tu aurais des / dans les noms à repplacer, il vaut mieux uiliser # comme séparateur de champs, donc
sed -r 's#monNomDeDomaine[.]fr#monNouveauNomDeDomaine.org#g' -i.old $(find -iname '*html' -or -iname '*md')
le -i.old permet de ne pas perdre les fichier d'origines, ils seront simplement renommé en .old
-i tout court va modifier les fichiers sans sauvegarde :)
le [.] dans la première partie permet de ne pas interpréter le . (dans une regEx, le . désigne n'importe quel caractère ) ou plus précisément [.] prends un caractère dans la liste des caractères entre les [] ici il n'y a que le . certains utilisent ., mais ça devient vite le bordel, notamment quand on inclue des chaines de caractères dans les autres.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: mouais
Posté par fearan . En réponse au journal Une Sacem du logiciel libre?. Évalué à 10.
Donc en gros, si je résume bien, pour permettre à une personne de recevoir une aumône, cette dernière passe par une maison d'édition pour avoir une visibilité de 6 mois, et après jusqu'à 70 après la mort de cette personne, personne ne peut profiter de l’œuvre.
Yep y'a pas à dire faut vraiment conserver ce système, il parait tout à fait correct.
PS: je ne parle évidemment pas des auteur à succès, qui de toute façons pourraient vivre largement de leur art si la protection n'était que de 10 ou 20 ans après publication de l’œuvre.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Une intuition comme ça
Posté par fearan . En réponse au journal Vive l'insertion digitale. Évalué à 9.
Yep, c'est tout le problème en informatique à force de parler mi franglais mi anglefranc on nous regarde bizarrement lorsque l'on parle dans le train de string ou de subtilité digital…
Alors que si on se contentait du Français on parlerai de chaine de caractère et dépassement de tampon, les gens nous regarderai enfin normalement… ou pas ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Quand ça ne marche pas, taxe!
Posté par fearan . En réponse au journal Une Sacem du logiciel libre?. Évalué à 4.
Putain faut pas déconner une recherche sur n'importe quel moteur de recherche te donne la réponse!!!
Si tu ne prends pour argent comptant que ce qui semble sourcé ou qui va dans ton sens de pensé on est pas rendu. Une info t'interpelle?
Sors toi les doigts du cul essuies-les et fait une (ou deux) recherche, et enrichi la discussion avec tes résultats, quitte à commenter sur ta surprise.
Si la recherche est infructueuse, là tu peux poser la question.
Une discussion est censé être un échange, pas un champs de bataille où on se bat à coup de référence.
De toute façons les pointeurs sont bien plus instructifs ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: propagande
Posté par fearan . En réponse au journal [cinéma] Chernobyl, la mini-série en cinq épisodes. Évalué à 9. Dernière modification le 24 juin 2019 à 11:46.
Il est toujours difficile de dire ce qui aurait été, mais on sait au moins ce qu'ils ont voulu faire (nommer des généraux de Vichy, nous interdire de posséder notre monnaie (remplacement du franc, par des dollars dépendant de leur bon vouloir, en Italie cela à provoqué une chute de leur monnaie).
Non c'était pour nous 'protéger' contre de Gaule, et siphonner nos colonies, relancer notre économie était la façade.
https://www.monde-diplomatique.fr/2003/05/LACROIX_RIZ/10168
Ensuite il est indéniable qu'ils ont contribué à la libération de la France, mais ils avaient leur propre agenda.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: propagande
Posté par fearan . En réponse au journal [cinéma] Chernobyl, la mini-série en cinq épisodes. Évalué à 8.
En fait sans les russes on parlerai allemand, sans les américains, on parlerai russe, sans le concours de Churchill on parlerai anglais (quand les américains sont venus ils avaient déjà les projets d'administration dans leur sac). Bref, je suis très content que tout ce petit monde ait contribué à la victoire.
À la fin de la guerre, si on sondait la population Française pour savoir qui avait le plus contribué à la victoire des alliés, le réponse était très majoritairement l'URSS, avec le temps, et les films, la perception à changé. on peut même dire que les deux ont échangé leur place dans la tête des Français https://www.ifop.com/wp-content/uploads/2018/03/3025-1-study_file.pdf
Ce qui est surtout marrant, c'est que ceux qui ont vécu le débarquement, justement pensaient à l'inverse de notre vision romancée, que dis-je holywoodé. Hors on pourrait croire que la proximité de l'action leur ait donné un prisme favorable au débarquement.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Nouvelle disposition de la fenêtre
Posté par fearan . En réponse au journal Ultracopier 2 Beta. Évalué à 3.
autre points que je n'avais pas remarqué, dans l'ancienne version les champs from et to sont placés chacun sur une ligne et prennent toute la largeur de la fenêtre, c'est un très bon point, dans la nouvelle, je vois juste un champ from, et on a même pas le chemin complet.
De plus ça tronque la fin, ne laissant que le début de visible, or généralement le plus déterminant c'est la fin ;)
Il faut reconnaitre quand même que la nouvelle fenêtre est plus jolie et fait moins austère.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Nouvelle disposition de la fenêtre
Posté par fearan . En réponse au journal Ultracopier 2 Beta. Évalué à 7.
Je n'utilise pas super-copier, généralement mes copies se font en ligne de commande la résistance au changement c'est pas moi !!! :P
Le soucis que je vois sur la nouvelle, c'est qu'elle affiche par défaut des infos dont on se contrefiche royalement et empiète d'autant plus sur l'écran. Le vieux winamp était un exemple de compactitude et de simplicité, vlc se contente de peu.
C'est un peu le reproche que je fais à certains ide qui inondent le développeur d'info qui ne lui sont utile que ponctuellement (arborescence de fichier/classe/projet/module) structure du fichier, plugins actif, gestionnaire de version. et on se retrouve à coder sur un timbre poste.
Alors oui ce sont des information extrêmement importante, mais pas en permanence. Dans le cas de super copier, ce qui est "utile" (dans l'ordre de préférence
* c'est le temps restant
* le fichier copié
* le temps restant pour le fichier copié
Ces 3 infos permettent de savoir à partir de quand on peut utiliser un ficher (ou tous les fichiers)
Ensuite, viens les infos moins pertinente mais utile quand même
* le débit actuel, ça permet de surveiller facilement la perte de lien
* liste des fichier copiés / à copier
Et enfin le détail
* le débit moyen
* historique de débit.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: OK mais
Posté par fearan . En réponse au journal Microsoft Love Linux ... et tout l'écosystème opensource .... Évalué à 3.
je trouve ta remarque un peu acide ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Je hais le C++
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 1.
Le soucis avec ça c'est que parfois tu veux bien une égalité de référence (is, ou == en java), mais que comme le langage décide que certains entiers ou chaines de caractères pointent vers la même…
Moi ce qui m'affole, c'est que le comportement change sur des valeurs arbitraire (-6), ajoute à cela que certaines sont immutable, et d'autre mutable, selon les contextes (paramètres par défaut)…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Performance
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2.
Il y'en a une, si tu veux parler d'une graphique, j'aurais tendance à dire que ce n'est pas le boulot du langage de devoir maintenir une bibliothèque graphique;
Bref, le coeur du langage doit se concentrer sur les outils de base.
Pour le graphique, réseau, xml, Qt fait très bien le taf ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Solution de facilité
Posté par fearan . En réponse au journal [FAILLE] Code execution dans Vim via un fichier malicieux forgé. Évalué à 6.
mais ça c'est parce que tu est méchant :P
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Performance
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2.
pour un fichier binaire j'éviterai d'utiliser int, short ou long mais int32_t, int16_t ou int64_t qui eux te garantissent la taille ;)
tu peux le faire mais avec le bon itérateur :
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Performance
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 3.
Eclipse est à la ramasse sur le java par rapport a intelliJ,
Eclipse est à la ramasse par rapport à qtCreator, vsCode, et même Clion sur tout ce qui a trait au c++.
Eclipse est beaucoup plus lourd que les 4 cités ci-dessus; Par contre, il est multi-langage, et y a une tetrachié de modules
Par ailleurs c'est une mauvaise idée de naviguer dans la stl, en tout cas celle de g++, le code est difficilement lisible, et tu pourrais prendre des choses comme acquises qui ne font pas partie de la norme.
Si tu veux utiliser la stl, tu vas sur
* https://en.cppreference.com/w/
* http://www.cplusplus.com/reference/
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Performance
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 1.
Tu peux donner des exemples ? car à part l'introspection, j'ai du mal a voir ce qu'il manque par rapport au java (au niveau des capacités du langage)
Moi ce qui me manque quand je change de langage (généralement java), c'est la non maitrise des const, impossibilité de choisir entre valeur/référence/pointeur, impossible de redéfinir les opérateurs (simplification d'interface), les template…
Je t'invites a écrire sans aide un appel de java vers c++, ou java vers ada, ou ada vers pascal !
Clairement le morceau de code que tu as donné est un interfaçage de C vers C++; et je dirais même un mauvais interfaçage; on récupère un pointeur de pointeurs et on va stocker les pointeurs (probablement des chaine de caractères) dans un vector, le tout sans aucun commentaire sur l'ownership (qui libère quand comment) (ici j'ai l'impression que c'est la bibliothèque qui le fait, mais ça ne dispense pas d'un commentaire); bref, si je suis relecteur de ce code c'est un rejet direct.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Je hais le C++
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2.
Je ne dis pas le contraire, j'aurais probablement expliquer plus en détail ma première réponse.
La chance n'a rien à voir la dedans; c'est la façon dont est implémenté la stl dans g++; clang; si , par exemple te fait une erreur à la compilation. Et je peux relancer le programme 1010 fois, j'aurais toujours le même résultat.
C'est typiquement ce genre de bout de code qui peut tourner 20 ans sans broncher, passer les versions de compilos, parce que quelqu'un à voulu faire du printf debugging, et n'a jamais remis le tout sur une ligne, et planter royalement le jour où tu rajoute 3 caractères dans un fichier de conf.
Si une version avec une "chaine vraiment trop longue pour rentrer dans la short string optimisation" là donner le 'bon' résultat est du à la chance.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Je hais le C++
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2. Dernière modification le 06 juin 2019 à 13:58.
Comme je le dis tu continue de changer l'énoncé au fil du fil.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Je hais le C++
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2. Dernière modification le 05 juin 2019 à 22:23.
Prendre comme exemple une lib incomplète ? T'en a d'autre pour justifier ton manque de préparation pour tes tests ? ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Je hais le C++
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2.
On est bien d'accord; mais tu as demandé la sortie de ton morceau de code; je te la donne, et je t'explique pourquoi ton code est prévisible; on est dans un comportement indéfini très bien défini du moment que la sso est présente ; j'y peux rien si tu ressors les exemples d'il y a 20 ans sans te soucier de voir si ils sont d'actualité.
Dans ton programme ? Je demande à voir!
Tu continues de changer l'énoncé au fil de l'eau ;) Tu peux aussi avoir une bibliothèque qui ne recouvre pas la mémoire.
CC sur Solaris, il y 15 ans t'aurais donné le même résultat; on a même du code critique qui a tournée pendant des années avec des comportements indéfini, et ne c'est pas propre au C++ …
On s'est rendu compte de la blague en passant sous linux + gcc, que des chaines vides à la place des résultats ;); le pire c'est que le code de duplication avait été commenté en disant qu'il ne servait à rien…
Tu peux aussi redéfinir tes new/delete
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: c'est un peu vague comme énoncé
Posté par fearan . En réponse au message Logiciel pour remplacer mots. Évalué à 2.
Honnêtement, ça aide beaucoup de connaitre le besoin (en plus d'écarter les éventuels 'faites mes devoirs', ou 'faites mon job')
Une autre solutions (sans ligne de commande), c'est ouvrir tous les fichiers dans un éditeur et de faire un remplacer dans tous les fichiers; certains éditeurs le permettent, mais ça va dépendre du nombre de fichiers et de leur taille ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Dépêchisable je pense en effet !
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 3. Dernière modification le 05 juin 2019 à 10:15.
Tu oublie cinéma (https://linuxfr.org/tags/cinema/public) et la cuisine cuisine (https://linuxfr.org/tags/recette/public)
Traitre !!!
Et puis on parle aussi de boulangère et parfois - hem - politique ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Je hais le C++
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2. Dernière modification le 05 juin 2019 à 09:34.
Tu pose une question, je répond, va pas changer l'énoncé ensuite, même valgrind ne bronche pas sur le premier exemple.
D'un point de vue technique (norme) le pointeur renvoyé c_str() (ou data()) reste valide tant que la chaine initiale n'est pas modifié. La chaine est détruite à la fin de la ligne const char *c1= s.substr(2).c_str(); , et la ligne suivante donne donc théoriquement un comportement indéfini;
cependant au vu de la taille de la chaine résultante, "123", on est dans le cas de la short string optimisation, ce qui fait que la totalité de la string est stocké sur la pile; non partagé avec qui que ce soit; et donc en absence de nouvelle allocation locale, on y touche pas; donc la mémoire est toujours valide ;) Ce qui fait que ton cas est parfaitement prévisible ;)
évidemment, si on agrandi la chaine résultante pour ne plus bénéficier de la short string optimisation, on n'alloue plus sur la pile mais le tas, et là tu vas faire broncher valgrind ;)
Ensuite du C dans du C++, c'est fréquent; par contre je le redis : on ne passe en char* qu'au dernier moment ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Je hais le C++
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2.
Je connais le problème des pointeur / référence sur temporaire; il se trouve que dans un environnement simple ton test donnée ne va jamais planter parce que le recouvrement de mémoire n'est pas fait, même valgrind ne râle pas, c'est pour dire! :P
Le vrai soucis c'est que tu combine du C (stdio.h) avec du C++. normalement, tu ne passe en c_str qu'au dernier moment.
En C moi j'ai eu ça
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: En France d'ailleurs
Posté par fearan . En réponse au message Plateforme équivalente . Évalué à 3.
j'aurais dis /. mais ça fait longtemps que je n'ai pas été y faire un tour ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Je hais le C++
Posté par fearan . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 4.
Toi ça ne te choque pas qu'un paramètre par défaut soit modifié à chaque appel ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: c'est un peu vague comme énoncé
Posté par fearan . En réponse au message Logiciel pour remplacer mots. Évalué à 7. Dernière modification le 04 juin 2019 à 16:37.
rapidement
en gros va remplacer toutes les chaines monNomDeDomaine[.]fr par monNouveauNomDeDomaine.org dans tous les fichier se terminant par html ou md.
dans le cas où tu aurais des / dans les noms à repplacer, il vaut mieux uiliser # comme séparateur de champs, donc
le -i.old permet de ne pas perdre les fichier d'origines, ils seront simplement renommé en .old
-i tout court va modifier les fichiers sans sauvegarde :)
le [.] dans la première partie permet de ne pas interpréter le . (dans une regEx, le . désigne n'importe quel caractère ) ou plus précisément [.] prends un caractère dans la liste des caractères entre les [] ici il n'y a que le . certains utilisent ., mais ça devient vite le bordel, notamment quand on inclue des chaines de caractères dans les autres.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent