LupusMic a écrit 1481 commentaires

Il m y a pourtant une différence entre simple et simplet.

L'évolution des espèces n'est pas une théorie, c'est un fait observable.

Tes impôts servent à payer le curé de ma paroisse. Oui, je vis en Alsace.

Peut-être aussi des témoins de Jehovah. ils refusent les divertissements et les fêtes. Ma femme qui était institutrice en maternelle m'a raconté que les parents avaient immédiatement mis à la poubelle le cadeau que leur enfant leur avait fait à l'école.

Ils ne refusent pas les divertissements. Ils s'amusent très bien, quotidiennement, avec une Bible et de la bonne musique (au sens du bien, pas de la qualité). Un peu de culture : http://www.watchtower.org/f/200805b/article_01.htm

Et pour le rapport aux fêtes : http://www.watchtower.org/f/bh/appendix_14.htm Célébrer une anniversaire est une hérésie pour les Témoins de Jéhovah, c'est normal que le cadeau soit rejeté et détruit dans ces conditions. C'est un peu comme si un petit musulman dessinait le Prophète et le montrait à ses parents ; un peu comme un petit chrétien dessinait deux garçons se faisant des bisous alors qu'ils ne sont pas en soutane.

Noël n'est pas une fête chrétienne. Le Noël du 25 décembre est fêté par les catholiques (et dérivés), le Noël du 3 janvier par les orthodoxes. Pour celui du 25 décembre, c'est effectivement la récupération d'une fête païenne, pour faciliter la conversion des plus fidèles de Sol Invictus.

Quand on a à faire avec des gens aussi stupides, il ne faut pas céder sinon nous serrons obligés de manger de la viande hallal ou cacher et le porc sera interdit […]
C'est toi qui est stupide. Certes, ils sont superstitieux, et cela peut sembler anachronique avec la masse de connaissance que l'humanité a accumulé. Mais c'est leur droit de l'être, et de vivre leur foi. Tu es stupide parce que tu fais une confusion entre l'adaptation d'un logiciel libre à une culture, et l'imposition de la pratique religieuse à l'ensemble d'une population. Ce n'est pas raisonnable comme raisonnement.

Comparer les performances entre un système 32bit et un autre 64bit, c'est un peu prendre les lecteurs pour des melons.

C'est surtout ouvertement sexiste, puisque c'est un ordre de servir un café à sa compagne qui doit naturellement te servir puisque tu es le mâle dominant. Et tout ça en 8 lettres <3

int const B16B00B5 = 0x95e; // some people may find it tiny

C'est vrai que ça manque de clarté par rapport à une version C++ :-D

auto x = the_stars_align() ? 4 : something_else() ? 3 : 0 ;

Pas nécessairement. L'essentiel des clients de ce genre de matériel sont des professionnels. Le code de la consommation ne s'applique pas à eux, c'est le code de la concurrence qui joue en l'occurrence. L'entreprise étant une personne au fait des lois et de ses responsabilités, ce qu'il signe l'engage. Ce qui fait qu'il sera difficile d'obtenir gain de cause en justice.

Mais ça reste du trolling de la part de Cisco, et c'est mal.

Je ne suis pas expert juridique, donc j'exprime ici mon opinion, et elle est à prendre en tant que telle.

C'est de l'ordre du réglementaire, donc on risque seulement une amende. Éventuellement des dommages et intérêts si un usager du service s'est senti léger (mais il faudra qu'il prouve qu'il a subit un préjudice).

Je pense que c'est encore une fois un des nombreux jeux d'équilibres avec lesquels les dirigeant doivent jongler. Personnellement, je préfère m'assurer de la sécurité de mon SI et risquer une amende, plutôt que de risquer ma responsabilité pénale parce qu'un gus aura utilisé mon réseau comme base arrière pour attaquer un tiers et ainsi être pris en défaut de sécurisation.

Ceci dit, faire les démarches auprès de la CNIL ait autant un devoir citoyen qu'une nécessité pour l'image de l'entreprise.

Ce que tu ne veux pas comprendre, c'est que la signature throw() indique que la fonction sur laquelle elle s'applique ne lancera jamais une exception. Ça ne veut pas dire que les fonctions appelées par la dite fonction son garanties exception-free. Ce qui est garanti, c'est que l'exception n'ira pas plus loin.

C'est une garantie, importante quand on écrit du code safe-exception.

Et une chose que tu ne comprends pas non-plus, c'est que C++ conserve une compatibilité avec C. Et les fonctions C, elles ne savent pas ce qu'est une exception.

Si tu ne veux pas gérer les exceptions, le compilateur propose une option pour ça.

Comme je l'ai dit plus haut, Java est un langage conçu pour élargir la base des développeurs tout en garantissant une qualité du développement. Ça a des avantages, ça a des inconvénient.

OSEF le piratage. Red Hat, Suse et autres vendeurs de licence de leur distribution phare ne se posent pas cette question. Alors, certes, ils vendent des services associés à la licence. Mais dans l'absolu, tu peux avoir la version complète sans le branding, sans que ça ne lèse l'éditeur. Et puis, le piratage qu'on craint dans le monde du logiciel libre, c'est l'accès frauduleux à un système d'information plutôt que la contre-façon.

Ça m'intéresse si tu as des statistiques sur le piratage des jeux à 1 €.

Mais dans l'absolu, si tu penses que tu seras piraté, tu peux toujours proposer une version gratuite (une démo) avec quelques niveaux, fonctionnalités, et une version complète qui est vendue. En tout cas, c'est certain que, si tu ne mets pas en vente une version, tu ne gagneras pas d'argent. À moins que tu ne mettes de la pub ou que tu arrives à « monetizer » les données des utilisateurs, évidement.

Et pourquoi ne le devrait-il pas ?

Si le langage laisse des libertés au compilateur, à l'implémentation, au système d'exploitation, c'est pour de bonnes raisons : c'est au développeur de décider ce qui est important. Certains développements ont besoin de fiabilité, d'autres d'être prédictifs, d'autres rapides, d'autres peu gourmand en ressources, et certains exigent de la précision là où d'autres se contente d'une approximation grossière.

Un bon exemple est la différence entre les nombres décimaux et les nombres à virgule flottante. Tu n'es pas sans savoir que, de base, C++ ne fournit pas de nombres décimaux. Car non, les nombres à virgule flottante ne sont pas des nombres décimaux. Ce sont des nombres binaires composites, qui contiennent un entier et un exposant (éventuellement un signe de positivité). Les calculs sur ces nombres sont approximatifs et ne sont pas fiables. Par exemple, on ne compare jamais un flottant à 0., mais quelque chose dans ce genre :

bool const float_equals_zero(float const number)
{
    return(number > 0. && number < std::numeric_limits::epsilon())
        || (number < 0. && number > - std::numeric_limits::epsilon()) ;
}

Dans une application de jeu vidéo en 3D, c'est bienvenue, car les calculs sur les flottant sont rapides. Y substituer des nombre décimaux en créant un type Decimal serait très malvenu. A contrario, dans une application bancaire, où la précision prime sur la rapidité d'exécution, on utilisera évidement des nombres décimaux.

Ensuite, on peut parler du scandaleux comportement de Linux, qui pratique l'overcommit memory. Encore une fois pour de basses considérations sur les performances, le noyau répond au processus qu'il a réservé la mémoire parce qu'il le peut. Mais jusqu'à ce que l'utilisation de la mémoire par l'application ne soit véritablement effectuée, Linux ne lui en réserve pas. Du coup, si dans le temps entre le moment où l'application a réservé de la mémoire, et le moment où elle écrit dedans, Linux n'a plus de mémoire à distribuer, elle tue le processus. Et là, ce n'est même pas une largesse qu'offre à Linux le C, POSIX, ou que sais-je comme autre norme : c'est une optimisation système qui privilégie la rapidité à la fiabilité.

Et nous finirons par évoquer la grande guerre des bases de données. Depuis quelques années, on a vu l'émergence d'une « nouvelle » race de base de données : les noSQL. Il y a dans ces technologies récentes plusieurs éléments qui les distingues des SGBDR dites classiques : elles renient SQL (car parser du SQL, ça prend du temps), elles ne garantissent plus le succès d'une opération et ne communiquent pas sur les échecs (ou de manière étrange, comme dans MongoDB, où on est averti de l'échec de la précédente opération). Là encore, il y a eu des compromissions avec la sécurité des données.

Je pourrais longuement continuer le catalogue des compromis effectués dans toutes ces technologies. J'ai longtemps été très rétif à toutes ces largesses. Mais depuis que j'ai touché à des architectures ou la scalabilité était primordiale, je me suis rendu compte à quel point c'était une posture idéologique en conflit avec la réalité.

C'est pour ça que je défends le choix des concepteurs de C++ de laisser le choix aux développeurs : on ne peut pas tout prévoir, et quand on essaye, on ferme des portes. Avec Java, l'exemple qui m'est le plus criant, c'est la GUI historique : certes, c'est a priori une bonne idée, mais dans les faits, on se coltine des interfaces laides et non-intégrées dans l'environnement graphique de l'hôte. Et surtout, il n'est pas possible de créer des éléments originaux puisqu'on a pas accès à la sous-couche de manière portable.

Je ne comprends pas ton raisonnement. Si tu avais rendu payant le jeu disponible sur l'AppStore, même en publiant le source sous licence libre, si le jeu est bon et attractif se vendrait. La raison est que l'installation via l'AppStore est plus rapide et facile (accessible par tous), contrairement à compiler les sources et installer manuellement sur son téléphone. Ceux qui veulent utiliser cette dernière option paieront de leur temps plutôt que de leur argent, certains pourraient même publier l'application gratuitement. Ce ne serait pas très honnête de leur part, mais à ce moment là, tu peux, à l'instar de la Mozilla Foundation avec Mozilla Firefox, toujours faire en sorte qu'une portion congrue des assets soit une marque (comme le nom du jeu, le logo, etc) et empêcher la contre-façon.

Un jeu est un logiciel à la base, donc la même logique s'y applique. Bien qu'il y ait des assets pour lesquels la tradition libre n'existe pas vraiment.

Je pense qu'il doit y avoir un business model qui s'applique aux jeux libres. Je pense que le commentaire de pepp (https://linuxfr.org/nodes/94503/comments/1360480) est caractéristique : le jeu a l'air pensé et fini (je ne l'ai pas essayé). Ce qui est dommage, c'est qu'ils ne le vendent pas sur le site de l'AppStore. Ceci n'empêcherait pas la publication des sources en GPL, ce qui serait payé, c'est la mise à disposition sur l'AppStore, la facilité d'installation.

Jusqu'à présent, il est vrai qu'il est difficile de penser qu'un jeux libre peut être payant. Mais avec le développement des jeux en free-to-play (Web, FB, etc), les jeux à 2 € (et pourtant de qualité) vendus sur les plate-formes de vente des constructeurs (iStore, AppStore, XBLA, etc), et les jeux à DLC, je pense qu'il y a moyen de créer une activité économique viable et libre.

Très franchement, j'avais longtemps cru que Java disposait de bonnes idées. Et plus j'avance dans mon expertise technique, plus je me convainc que ce sont de fausses bonnes idées. Mais contrairement à PHP, Python ou C++, je n'ai pas assez pratiqué. On verra quand je me mettrais sérieusement à Java pour faire des apps Android >

Le langage permet beaucoup, beaucoup de choses. D'ailleurs, en C++, nombres de comportements sont indéfinis. Le plus des compilateurs, s'est de détecter et d'avertir le développeur. Quand j'ai commencé à développer il y a dix ans, le compilateur de détectait pas le renvoie d'un pointeur ou d'une référence sur une variable de portée locale. Aujourd'hui, G++ fait un gros warning qui fait tout péter quand tu compile correctement (-Wall -Werror).

En même temps, Java, c'est conçu pour que les crétins puissent contribuer à un projet sans le compromettre en permanence :o)

La signature throw() ne veut pas dire qu'aucune exception ne sera pas levée dans la fonction, mais garanti qu'aucune exception ne sera émise par la fonction. En l'occurrence, std::terminate sera appelé si une exception tente de s'échapper de la fonction-qui-ne-peut-lever.

Ceci sert quand on écrit des fonction exception-safe. C'est une garantie qu'il faut fournir, par exemple, dans les fonctions utilisées par le destructeur virtuel d'une classe.

Je partage l'avis que le compilateur devrait râler sur ce cas précis, et honnêtement, avant d'écrire l'exemple, je pensais qu'il le fait. Mais ce n'est pas un problème du langage : c'est un problème du compilateur. Si ça se trouve, LLVM ou MSC++ émettent un warning, peut-être que GCC a une option pour ça qui n'est pas incluse avec -Wall.

Ce qui te semble est faux : http://www.gotw.ca/publications/mill22.htm

Rien n'empêche le compilateur de le savoir ?

// dude.cpp
// c++ -o dude{,.cpp} -Wall -pedantic -std=c++0x
#include <iostream>
#include <stdexcept>
#include <memory>

struct People
{
    virtual void joke() throw() = 0 ;
} ;

struct SkinHead
    : People
{
    virtual void joke() throw() ;
} ;

struct Dude
    : People
{
    virtual void joke() throw() ;
} ;

int main()
{
    std::shared_ptr<People> arse { new SkinHead } ;
    arse->joke() ;
}

void SkinHead::joke() throw()
{
    throw std::logic_error("Racist joke") ;
}

void Dude::joke() throw()
{
    std::cout << "The usual thing\n" ;
}

Si les définitions des fonctions membres ne sont pas dans la même unité de compilation, le compilateur ne pourra pas deviner que People::joke ne lancera jamais d'exception.

Oui je trouve ça beaucoup plus lisible. À noter qu'ici tu as utiliser un outil encore plus pourave que la concaténation de chaines : l'opérateur d'injection. C'est une horreur totalement illisible, qui rend la compréhension du code tout à fait fatigante.
Avec une chaîne de format (qui sera utilisé par l'outil de localisation), on peut se concentrer sur la manière de formater le texte, puis de décider quelles données fournir.

Au fait, l'opérateur d'injection n'est pas disponible pour les std::string, mais pour les std::stringstream.

Mais n'étant pas un sauvage, j'utilise boost::format depuis un moment.

std::cout << boost::format("Bonjour %s. Vous avez %i nouveaux messages\n")
    % name % 3 ;

D'ailleurs, les Variadic Tuples vont te donner la migraine sur ce point. Herb Sutter montre un exemple d'application de VT qui concerne justement une écriture de de print type-safe http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond

Ta critique sur l'inférence de type est risible. C'est une chaîne de formatage, ce qui implique qu'on formate la sortie. La précision du type est historique, mais on peut aussi vouloir préciser la précision, compléter le nombre, etc. Je sais bien que les stream permettent ça : mais c'est bien là tout le soucis de lisibilité qui pointe le bout de son nez. Là où il faut 4 caractère pour indiquer un format pour afficher un nombre sur trois digit, il faut tout d'un coup configurer le flux à la volée. En première instance, c'est magique. Mais à l'usage, c'est pénible et illisible.

C++ n'est pas un langage bas niveau. C'est un ensemble d'outils haut-niveau, qui permettent un haut niveau d'abstraction.

C++ est justement équipé de fonctionnalités permettant de manipuler des vecteurs mathématiques. Le type std::complex est un premier pas dans ce sens.
http://www.cplusplus.com/reference/std/complex/

Et Boost, en proposant ses octonions qui font pleurer, achève de te clouer :-D

D'ailleurs, la dernière mouture de C++ montre l'effort pour rendre encore moins prépondérant le côté « programmation système ». Par exemple, en encapsulant la fabrications de pointeurs intelligents (template make_shared())

Quel serait le sens d'une variable de type void ?

[quote]Une première chose est la verbosité des déclarations. Finalement, les histoires de "@safe pure nothrow" ne sont que des commandes d'optimisation, que l'on utilise principalement pour aider les compilos. Je ne suis pas certain que ça soit au programmeur de gérer ça. La raison principale est que, selon mon expérience, ça nuit à l'évolution et à la flexibilité du programme. Je ne connais pas assez D, mais en C++, on se tape des arbres super-complexes de const à gérer ; modifier le status "const" d'une variable est quasiment impossible dans un programme complexe, le compilo hurle avec des milliers de messages d'erreur, et on finit par saloper le design avec des mutable, et/ou par dupliquer toutes les méthodes avec une version const et une version non-const strictement identiques. Je pense que les langages doivent aussi être conçus pour les gens qui ne sont pas des experts en programmation, y compris en évitant au maximum de faire faire le boulot du compilo aux programmeurs.[/quote]

Tout dépend des contraintes et de l'exigence que tu as sur ton projet. Si tu t'en fou de savoir qu'une fonction ne lance jamais d'exception, tu te balances donc de savoir si ton programme sera stable. Si en C++, et visiblement en D, on indique la capacité à lancer des exceptions (et lesquelles), c'est pour garantir un contrat. C'est très important pour une fonction utilisée dans un destructeur, par exemple. Et ça, le compilateur ne peut pas le deviner tout seul lors de la compilation de la fonction.

Je suis d'accord que la gestion des capacités const et non-const est parfois galère. Mais il ne faut pas oublier que, si une fonction membre const modifie l'objet sur lequel elle est appelée, il y a peut-être un problème de design.

Enfin, si tu as deux fonctions au contenu identique, et que la seule différence est ça constness, c'est que tu ne connais pas cette méthode :

Ret const & Object::get() const
{
   return m_something ;
}

Ret Object::get()
{
    return const_cast<Ret &>(const_cast<Object *>(this)->get()) ;
}

Comment ça la seconde fonction est illisible :D

La concaténation de chaîne est un ennemi mortel, qui rend le code illisible, en réduit la maintenabilité, et empêche une gestion efficace de l'internationalisation. Même en PHP je l'ai banni, car son usage entraîne des trous de sécurité systématiques (oublie de l'usage des fonctions de sécurisations des données, entre autres).

Ce que tu regrette, c'est le système de formatage historique introduit par le bibliothèque C. Mais si tu regardes, de nombreux langages ont proposé une syntaxe qui permet d'auto-documenter le formatage. Comme c'est le cas en Python.