API plus sûres existent, elles sont typiquement plus laborieuse à utiliser (.at() au lieu de [], value() au lieu de * ou ->), alors que les besoins en perfs sont typiquement concentrés et non pas diffus
Oui mais non, généralement quand j'accède à un indice dans un vecteur, je sais que je ne vais pas taper dans le vide, je ne l'ai pas choisi aléatoirement, * et -> sont des accesseurs sur les pointeurs, et je ne m'attends pas à un test.
C'est des sémantiques proches du C, et c'est tant mieux, le comportement est similaire. Rien n'est plus piégeant en java que le == qui tantôt va le faire sur les valeurs (type primitifs), tantôt sur les référence d'objet, et parfois avec la mutualisation des références, va fonctionner quand même.
C'est typiquement le type d'opérateur que j'utilise en coeur de boucle, et l'appli sur laquelle je bosse ne peut pas se permettre de perdre des perfs.
J'ajouterai que modifier le comportement d'un programme lors de la mise à jour d'un langage n'est pas souhaitable; si tu veux être 'sécure' lit la putain de doc et apprends à coder!
Des mauvais codeurs, même avec un langage safe te feront toujours du mauvais code; ces deux derniers jours j'ai du refactorer une partie de code (faite il y a 3 semaines); on appel ça une fin de chantier chez nous... Au final j'ai diminué le code de 100 lignes, et c'est plus générique (une classe pilotée par 2 booléens constant à la création, là ou une Intergace et deux implémentations auraient suffit...) et puis ça aurait été trop demandé à la classe de gérer ces cas... Non il fallait tester ces booléens pour savoir quelle fonction appeler... C'était du java
Honnêtement, je préfère ne pas avoir de codeur plutôt qu'un mauvais codeur.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Mouais
Posté par fearan . En réponse au journal Le glissement du C++ (et dans une moindre mesure du C) vers une position indésirable. Évalué à 2.
API plus sûres existent, elles sont typiquement plus laborieuse à utiliser (.at() au lieu de [], value() au lieu de * ou ->), alors que les besoins en perfs sont typiquement concentrés et non pas diffus
Oui mais non, généralement quand j'accède à un indice dans un vecteur, je sais que je ne vais pas taper dans le vide, je ne l'ai pas choisi aléatoirement, * et -> sont des accesseurs sur les pointeurs, et je ne m'attends pas à un test.
C'est des sémantiques proches du C, et c'est tant mieux, le comportement est similaire. Rien n'est plus piégeant en java que le == qui tantôt va le faire sur les valeurs (type primitifs), tantôt sur les référence d'objet, et parfois avec la mutualisation des références, va fonctionner quand même.
C'est typiquement le type d'opérateur que j'utilise en coeur de boucle, et l'appli sur laquelle je bosse ne peut pas se permettre de perdre des perfs.
J'ajouterai que modifier le comportement d'un programme lors de la mise à jour d'un langage n'est pas souhaitable; si tu veux être 'sécure' lit la putain de doc et apprends à coder!
Des mauvais codeurs, même avec un langage safe te feront toujours du mauvais code; ces deux derniers jours j'ai du refactorer une partie de code (faite il y a 3 semaines); on appel ça une fin de chantier chez nous... Au final j'ai diminué le code de 100 lignes, et c'est plus générique (une classe pilotée par 2 booléens constant à la création, là ou une Intergace et deux implémentations auraient suffit...) et puis ça aurait été trop demandé à la classe de gérer ces cas... Non il fallait tester ces booléens pour savoir quelle fonction appeler... C'était du java
Honnêtement, je préfère ne pas avoir de codeur plutôt qu'un mauvais codeur.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent