[F] [mOved] Mon langage est mieux que le tien - Page 113

https://softwareengineering.stackexchange.com/questions/362491/can-we-assume-while-testing-software-that-a-user-wouldnt-perform-such-silly-act
C'est beau, l'innocence des débutants

Eux ils m'ont pas eu comme testeur

Le testeur qui entre n'importe quoi pour embêter le reste de l'équipe, on a déjà eu ça comme un des rôles dans le TP "Software Engineering 1" à l'université.

Si vous maîtrisez plein de trucs, voici une offre d'emploi pour vous :
https://www.freelancer.com/projects/software-architecture/net-graphic-user-interface/

Par contre, vu le tarif horaire (en haut à droite), faudra vous préparer à manger des pâtes

Des pates? je suis meme pas sur c'est en dessous du smic horaire

Ouch, vu le nombre de réponses de pays dits émergents, la concurrence va être dure !

Tu as vu les reponses? Le gars cherche du C# certains repondent "je fais du python" ou d'autre trucs qui n'ont rien a voir.

Les gars cherchent n'importe quoi, ça ne me choque pas que les candidats arrivent avec des profils hétéroclites ^^

https://wiki.sei.cmu.edu/confluence/display/c/FIO19-C.+Do+not+use+fseek%28%29+and+ftell%28%29+to+compute+the+size+of+a+regular+file :
Seeking to the end of a binary stream in binary mode with fseek() is not meaningfully supported and is not a recommended method for computing the size of a file.

Ben mince, je ne savais pas ça... et si j'en crois le reste de la page, la seule solution pour déterminer la taille d'un fichier, c'est de faire appel à une fonction de l'OS (donc non portable)... Vive le C

STREAM. parce que ca peut être stdin ou un socket. pour un fichier dont tu sais qu'il est sur un filesystem ca marche très bien.

sinon ouais c'est fstat(). c'est moins portable que seek?

fseek/ftell n'on jamais ete fait pour ca c'est certain, si le fichier est un stream ca n'a aucun sens par exemple. Si le fichier est un device ca n'a aucune sens aussi .

fstat pourrais etre standard, mais non c'est con, c'est POSIX, apres le probleme de fstat c'est que sa structure est trop dependant de l'OS, certaines infos ne sont pas pertinentes sous autre chose qu'un UNIX, mais oui une fonction standardisé pour savoir le type de fichier (ficher, stream, device, ...) la taille si c'est un fichier etc... serait plus que la bienvenue.

Apres sous Windows il y a un equivalent a fstat pour connaitre la taille.

Je pense que quand la libc a ete definie, ce type d'information etait trop floue pour etre simplement standardisé. Maintenant (mais c'est probablement trop tard) ils pourraient le faire.

en réponse a : topics/154076-yarotweet-ou-le-topic-des-pensees-a-la-con/557#post-16685

Pen^2 (./16685) :
Lequel ? Il y a beaucoup d'observers évidemment avec swing, mais sinon ? Tu penses à quel factory concrètement ?

La bibliothèque standard est correcte mais dans les programmes Java sur lesquels je tombais couramment, il y avait trop souvent des organisations de classe inutilement complexes a vouloir gérer trop de choses. Je ne parle pas des forcément des Factory en particulier. C'était pas vraiment un problème du langage lui même mais une mauvaise habitude généralisée chez les architectes Java qui adorent recourir a des structures complexe pour prouver leur compétences alors qu'une solution simple était tout a fait possible, ce qui lui a donné une réputation de langage verbeux.

Je me souviens pas des détails, ça fait un moment que j'en ai pas refait, mais Spring était pas mal dans le style de multiplier les objets intermédiaires et les interfaces qui ne sont qu'un masque de l'implémentation. Je ne parle même pas des EJB qui étaient un horreur absolue.

Et puis il y a les getter/setter qui sont une notion capitale du langage et qui ne sont pas foutus d'avoir une syntaxe dédiée.

les getter setters sont juste des fonctions et java a peu de sucre syntaxique, c'est a dire de trucs redondants (dans le langage lui même hein, je parle pas de la lib)

sinon oui les kilotonnes d'interface pour rendre réutilisables des classes ultra-spécialisées, c'est chiant.

Oui, la c'est juste un manque de sucre, pas de la sur-conception, mais c'est juste tellement aberrant de ne pas en avoir fait une notion du langage que j'ai pas pu résister à le citer.

Uther (./3372) :
les architectes Java qui adorent recourir a des structures complexe pour prouver leur compétences

incompétence, tu veux dire

Les instances des EJB oué annéfé c'est moche, mais c'est pas le java, c'est le framework et il faut quand même reconnaître que c'est puissant. Les accesseurs c'est presque un détail, oué, je ne trouve pas ça aberrant, sans doute largement lié aux habitudes.

Je suis sur qu'en plus on pourrait faire des annotations qui génèrent le bon code, le compilateur s'en charge en phase de précompilation.

Voila ca existe déja, en fait:

https://projectlombok.org/features/GetterSetter

Oui je connaissais Lombok, mais comme il l’expliquent noir sur blanc sur leur propre site, c'est clairement un hack.

c'est du préprocessing de sources grace a une fonction du compilo qui a été ajoutée pour ca, autant qu'elle serve

Godzil (./3371) :
fseek/ftell n'on jamais ete fait pour ca c'est certain, si le fichier est un stream ca n'a aucun sens par exemple. Si le fichier est un device ca n'a aucune sens aussi .

En effet. Utiliser fseek et ftell pour déterminer la taille d'un fichier est clairement un hack. Ça ouvre le fichier pour rien (et du coup ne fonctionne pas si l'utilisateur n'y a pas accès en lecture). C'est à ça que sert fstat.

fstat pourrais etre standard, mais non c'est con, c'est POSIX, apres le probleme de fstat c'est que sa structure est trop dependant de l'OS, certaines infos ne sont pas pertinentes sous autre chose qu'un UNIX, mais oui une fonction standardisé pour savoir le type de fichier (ficher, stream, device, ...) la taille si c'est un fichier etc... serait plus que la bienvenue.

fstat existe aussi sous Windows. Je vois mal quel autre système non-POSIX tu voudrais viser.

Uther (./3372) :
La bibliothèque standard est correcte mais dans les programmes Java sur lesquels je tombais couramment, il y avait trop souvent des organisations de classe inutilement complexes a vouloir gérer trop de choses. Je ne parle pas des forcément des Factory en particulier. C'était pas vraiment un problème du langage lui même mais une mauvaise habitude généralisée chez les architectes Java qui adorent recourir a des structures complexe pour prouver leur compétences alors qu'une solution simple était tout a fait possible, ce qui lui a donné une réputation de langage verbeux.

Je me souviens pas des détails, ça fait un moment que j'en ai pas refait, mais Spring était pas mal dans le style de multiplier les objets intermédiaires et les interfaces qui ne sont qu'un masque de l'implémentation. Je ne parle même pas des EJB qui étaient un horreur absolue.

Un exemple d'API absolument bordélique à utiliser est Calendar. Heureusement que JSR 310 a apporté une API utilisable pour ça.

Même NuttX implémente fstat(). Mais pour les vxworks et autres nucleus, aucune idée.

Ce n'est pas fstat mais _fstat sous windows ( https://msdn.microsoft.com/en-us/library/aa246905(v=vs.60).aspx )


Et c'est, je site le manpage de fstat:

CONFORMING TO
       stat(), fstat(), lstat(): SVr4, 4.3BSD, POSIX.1-2001, POSIX.1.2008.

Ce ne fait pas partit du C, donc supporté par un OS que si il veux implementer POSIX ou proche.

#if defined(WIN32)
#define fstat _fstat
#endif

Donc c'est pas portable, CQFD.
(je définis "portable" comme "compilable sans modif pour toutes les plateformes pour lesquelles il existe un compilo C qui respecte le standard")

Kevin Kofler (./3379) :
Ça ouvre le fichier pour rien (et du coup ne fonctionne pas si l'utilisateur n'y a pas accès en lecture). C'est à ça que sert fstat.

Sauf que souvent, si tu as besoin de connaître la taille d'un fichier, c'est justement parce que tu veux le charger. Et utiliser une fonction qui donne la taille du fichier avant de l'ouvrir introduit une race condition.

()

non, tu veux pas que ce soit portable la, tu veux que ce soit dans la lib standard du C.

y'a pas, point.

fstat fonctionne partout modulo de légers ajustements, c'est donc portable.

si tu veux ouvrir ton fichier apres avoir vérifié la taille, tu prends fseek

si ton machin doit gérer un stream, tu vas probablement pas vérifier la taille et ouvrir ensuite.

Non non non et non.

Zero a raison sur la race condition et ce n'est pas a prendre à la légère.

Mais vous faites tous erreur, vous confondez stat et fstat:

int stat(const char *pathname, struct stat *statbuf);
int fstat(int fd, struct stat *statbuf);

fstat demande d'ouvrir le fichier avant d'en avoir les infos, vous confondez avec stats qui lui prends le nom de fichier.

La ou fstat est contradictoire c'est qu'il est préfixé par "f" alors qu'il ne fait pas partie de la stdlib (fopen/fclose/fread/fwrite/...) mais est dans le domaine de plus bas niveau (open/close/read/write)

Et sans être aussi extrémiste je suis d'accord avec Zero, "modulo de légers ajustements" n'est pas définition de portable, ça veux clairement dire que le code d'appel peux complètement changer d'un système a l'autre (sans compter le contenu de la structure "struct stat" qui je suis sur est très très différente entre Windows et Linux, en plus je ne suis pas sur qu'elle soit clairement définie par POSIX. (structure qui est "struct _stat" sous Windows d'ailleurs, je ne comprends pas pourquoi Microsoft à préfixé ces fonctions/structure..))

Merci Godzil

Par contre :

Godzil (./3385) :
excremiste

Je suis pas sûr de vouloir savoir ce que ça veut dire, et encore moins que Nil nous explique

LOL

(hmmm, non, t'es sûr que tu ne veux pas ? )

Sinon c'est pas portable parce que le C est censé fonctionner sur des systèmes qui n'ont pas forcément de systèmes de fichiers je crois ?

Zerosquare (./3383) :
Donc c'est pas portable, CQFD.

Bof de toute façon le C c'est pas portable. CQFD