change ton R_xlen_t en int tu as deux autre résultats.
Prends ta souris, rajoute une trompe, grossis 1000 fois, et tu as un éléphant, donc une souris ressemble vachement à un éléphant.
Tu as volontairement pris un exemple avec une faible occurrence, pour prouver ton propos.
C'est totalement faux. Je me suis demandé "tiens, prenons un algo trivial, le calcul de moyenne", j'avais un script R ouvert, j'ai été chercher le source sur Google, et je l'ai sorti.
Mais bon, si tu imagines que les interlocuteurs avec qui tu n'es pas d'accord sont systématiquement de mauvaise foi, alors c'est sûr que tu vas avoir l'impression d'avoir toujours raison.
c'est cet agencement qui est protégé par le droit d'auteur.
Ça n'est qu'une interprétation très lointaine et très douteuse de ce qu'est le droit d'auteur. Le code est protégé par le droit d'auteur de la même manière qu'un texte ou une œuvre quelconque, et c'est toi qui te construis tout une idée de ce qui est protégé et de ce qui ne l'est pas. Sur les textes littéraires par exemple, je ne connais pas de cas où un auteur a été condamné pour avoir repris la structure d'un roman (ou alors beaucoup de films Hollyhoodiens auraient un problème).
voila j'ai fait le tour de ce qu'on peut faire en c++ pour un développeur normal;
Pas de bol, ça n'est pas l'implémentation de std::swap, qui utilise std::move
et on peut encore inverser a et b. ou replace a+=b par a = a + b, ou utiliser auto à la place de T;
Ou spécialiser le template pour les pointeurs, ou appeler a et b comme on veut, ou mettre class à la place de typename, ou appeler la fonction myswap ou n'importe quoi d'autre pour la distinguer de std::swap... Donc oui, il existe des dizaines de manières d'implémenter ce truc trivial.
D'ailleurs, un très bon exemple est l'implémentation de la stl par les différents compilos. Les implémentations se ressemblent parfois un peu, mais la plupart du temps, elles diffèrent grandement! Impossible d'affirmer qu'il n'y a qu'un moyen de coder la stl, alors que pourtant, on reste dans des fonctions très génériques, avec la même API et les mêmes contraintes!
Toujours si on veut aller ver la protection du code, il faut que ton analyse soit capable de repérer des inversions de lignes, virer le code 'mort', Bref maitriser les techniques de dissimulations, il faut que ton outil soit suffisamment fiable pour ne pas se planter tous les deux commits.
Non, parce que ça n'est pas du tout l'objectif. C'est un peu comme si tu demandais à ce que l'algo de Youtube arrive à déceler les vidéos composées d'images de film variés, qui durent 1/24 seconde, montées à l'envers et distordues par tout un tas de filtres... Mais non, c'est à côté de la plaque. Les ayant-droit se foutent complètement que tu proposes des trucs illisibles qui ne servent à personne, ils ne veulent pas que tu diffuses leur truc à leur place, c'est tout.
L'idée n'a jamais été de mettre des filtres infaillibles, c'est la communauté du logiciel libre qui fantasme sur des risques purement théoriques. Tu dis qu'un filtre doit faire ci, ci, ou ça, mais pourquoi tu lui inventes des contraintes? Si ça se trouve, les filtres vont porter au niveau du fichier, voire du projet! Mais non, on préfère se faire peur en prétendant que "for (int i = 0; i < size; i++)" va être interdit. On n'est pas là pour se monter un jeu de rôle! Ces filtres servent à empêcher l'upload de matériel protégé par le droit d'auteur ; je reste sur ma conviction qu'il est strictement impossible de créer plusieurs lignes de code identiques par coïncidence dans des pojets réels, et il est aussi très probablement impossible de créer plusieurs dizaines d'instruction assembleur identiques après compilation (donc là, exit les noms de variable et l'indentation du code). Et je ne parle même pas des chaines de caractères, des commentaires, des messages d'erreurs!
Après, il y a peut-être quelques copieurs-colleurs fous qui mouillent un peu ; en particulier, les algos non-triviaux publiés sur le web ou dans des bouquins ne sont peut-être pas libres, et oui, si on passe notre vie à faire semblant de coder, ça peut être problématique.
[^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?
Posté par arnaudus . En réponse au journal Le filtrage à la source. Évalué à -1.
Prends ta souris, rajoute une trompe, grossis 1000 fois, et tu as un éléphant, donc une souris ressemble vachement à un éléphant.
C'est totalement faux. Je me suis demandé "tiens, prenons un algo trivial, le calcul de moyenne", j'avais un script R ouvert, j'ai été chercher le source sur Google, et je l'ai sorti.
Mais bon, si tu imagines que les interlocuteurs avec qui tu n'es pas d'accord sont systématiquement de mauvaise foi, alors c'est sûr que tu vas avoir l'impression d'avoir toujours raison.
Ça n'est qu'une interprétation très lointaine et très douteuse de ce qu'est le droit d'auteur. Le code est protégé par le droit d'auteur de la même manière qu'un texte ou une œuvre quelconque, et c'est toi qui te construis tout une idée de ce qui est protégé et de ce qui ne l'est pas. Sur les textes littéraires par exemple, je ne connais pas de cas où un auteur a été condamné pour avoir repris la structure d'un roman (ou alors beaucoup de films Hollyhoodiens auraient un problème).
Pas de bol, ça n'est pas l'implémentation de std::swap, qui utilise std::move
Ou spécialiser le template pour les pointeurs, ou appeler a et b comme on veut, ou mettre class à la place de typename, ou appeler la fonction myswap ou n'importe quoi d'autre pour la distinguer de std::swap... Donc oui, il existe des dizaines de manières d'implémenter ce truc trivial.
D'ailleurs, un très bon exemple est l'implémentation de la stl par les différents compilos. Les implémentations se ressemblent parfois un peu, mais la plupart du temps, elles diffèrent grandement! Impossible d'affirmer qu'il n'y a qu'un moyen de coder la stl, alors que pourtant, on reste dans des fonctions très génériques, avec la même API et les mêmes contraintes!
Non, parce que ça n'est pas du tout l'objectif. C'est un peu comme si tu demandais à ce que l'algo de Youtube arrive à déceler les vidéos composées d'images de film variés, qui durent 1/24 seconde, montées à l'envers et distordues par tout un tas de filtres... Mais non, c'est à côté de la plaque. Les ayant-droit se foutent complètement que tu proposes des trucs illisibles qui ne servent à personne, ils ne veulent pas que tu diffuses leur truc à leur place, c'est tout.
L'idée n'a jamais été de mettre des filtres infaillibles, c'est la communauté du logiciel libre qui fantasme sur des risques purement théoriques. Tu dis qu'un filtre doit faire ci, ci, ou ça, mais pourquoi tu lui inventes des contraintes? Si ça se trouve, les filtres vont porter au niveau du fichier, voire du projet! Mais non, on préfère se faire peur en prétendant que "for (int i = 0; i < size; i++)" va être interdit. On n'est pas là pour se monter un jeu de rôle! Ces filtres servent à empêcher l'upload de matériel protégé par le droit d'auteur ; je reste sur ma conviction qu'il est strictement impossible de créer plusieurs lignes de code identiques par coïncidence dans des pojets réels, et il est aussi très probablement impossible de créer plusieurs dizaines d'instruction assembleur identiques après compilation (donc là, exit les noms de variable et l'indentation du code). Et je ne parle même pas des chaines de caractères, des commentaires, des messages d'erreurs!
Après, il y a peut-être quelques copieurs-colleurs fous qui mouillent un peu ; en particulier, les algos non-triviaux publiés sur le web ou dans des bouquins ne sont peut-être pas libres, et oui, si on passe notre vie à faire semblant de coder, ça peut être problématique.