Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
3094 connectés 

 


 Mot :   Pseudo :  
 
 Page :   1  2  3  4
Auteur Sujet :

conversion adresse de tableau de pointeurs

n°748337
vivelec
Posté le 02-06-2004 à 00:26:31  profilanswer
 

Reprise du message précédent :

el muchacho a écrit :

Alors prépare-toi à bouffer du pain sec, parce que des boîtes rétrogrades, c'est pas ça qui manque.


Et puis la soupe y est bonne !
Après tout, tant qu'ils paient ...

mood
Publicité
Posté le 02-06-2004 à 00:26:31  profilanswer
 

n°748341
bjone
Insert booze to continue
Posté le 02-06-2004 à 00:29:45  profilanswer
 

vivelec a écrit :

Si t'es en pleine crise d'ado ou que tu t'es fait larguer par ta copine, ce n'est pas mon problème.
On est simplement là pour discuter tranquillement sans fatalement partir dans tous les sens.
Si t'es dans ta studette avec ton linux, tant mieux.
Mais sache que dans l'industrie, il n'y a pas que du c99, de la mandrake, et du gcc.
Et si, à ton premier entretien d'embauche, tu commences à traiter Solaris de vieux truc dépassé, tu risques d'être dans la merde.
 
Bonne nuit !
 :p


 
Personnellement, je suis d'accord avec toi qu'une bonne partie de l'industrie est conservatrice au niveau des technologies, ou plustôt dans ce cas là de la chaine d'outils employée.
 
Donc avertir d'un problème potentiel de non compatbilitée des outils modernes (d'un même standard) avec des outils anciens est très important.
 
ça a son importance lorsque l'on doit intervenir sur du logiciel utilisé en production depuis des années, et qui n'a pas bougé depuis.  
 
MAIS il ne faut pas dramatiser, et prôner la restriction dans le jeu de fonctionalitées.
 
J'ai compris que ce que tu reproches, c'est pas que le C99 et + (++ :D)), et mauvais, mais dans certains contexte industriel, on y a pas droit.  
 
-----------
ça me fait penser au film Space Cowboy, où ils sont obligés d'aller chercher le gars qui a conçu le satellite y'a 30 ans, puisque les techniques employés sont tombées dans l'oubli.
------------
 
Mais tu noteras, que normalement, si tu as fait beaucoup de C (depuis longtemps je supposes), toutes les évolutions qui viennent avec le C99, et d'autres langages comme le C++, sont des évolutions naturelles et une fois que tu les utilises, tu te demandes comment tu faisais avant, et tu regardes tes anciens devs d'un oeil bizarre.

n°748353
vivelec
Posté le 02-06-2004 à 00:47:26  profilanswer
 

bjone a écrit :


... MAIS il ne faut pas dramatiser, et prôner la restriction dans le jeu de fonctionalitées.
...
 
Mais tu noteras, que normalement, si tu as fait beaucoup de C (depuis longtemps je supposes), toutes les évolutions qui viennent avec le C99, et d'autres langages comme le C++, sont des évolutions naturelles et une fois que tu les utilises, tu te demandes comment tu faisais avant, et tu regardes tes anciens devs d'un oeil bizarre.


On s'adapte de toutes façons à tout language, ainsi qu'à ses évolutions.
Cependant, le problème qui se pose actuellement et que j'ai souligné quelques messages plus hauts, c'est que l'on assiste à une dégradation importante de la qualité des produits livrés dans l'industrie liés à deux phénomènes prépondérants :  
- la décentralisation des dévelloppements dans les pays dits "à faible coût" (tunisie, pakistan, inde, ...) où les délais impartis sont trop courts et les formations insuffisantes,
- la dévalorisation du statut de "developpeur C/C++".
Les sources générées ne respectent donc même plus les règles élémentaires du C, ne serait-ce que de ne pas faire de strcpy sur un pointeur non alloué.
D'autre part, chez les grands comptes, on n'a pas forcément le choix ni de l'os ni de la version du compilateur que l'on aura à disposition. Or le C99 est trop récent pour être accepté (cf AIX : fin 2002).
 
Aujourd'hui, dans mon travail, je suis justement chargé de fixer des règles de programmations, afin d'éviter d'avoir à tout refaire.
Et je suis donc très loin de préconiser le C99.
Il faut d'abord que les intégrateurs apprennent à faire la distinction entre un développeur php et développeur C, et à livrer des sources propres, un tant soit peu portable.
Pour la petite histoire, je ne suis pas sûr que les outils d'analyse de code du marché supportent cette norme ...

n°748355
el muchach​o
Comfortably Numb
Posté le 02-06-2004 à 00:51:35  profilanswer
 

Préconise l'Objective Caml ou l'ADA, ça leur évitera de continuer à faire des conneries.
Pour le reste, je suis tout-à-fait d'accord (surtout pour la dévalorisation du statut de développeur C/C++).
Tout change... :pfff:  
Et il va falloir s'habituer à voir les avions s'écraser sur le sol.
 
Sinon, tu es bien la première personne qui me dit passer lint (ou splint ?) sur le code.


Message édité par el muchacho le 02-06-2004 à 00:58:19
n°748356
Taz
bisounours-codeur
Posté le 02-06-2004 à 00:51:42  profilanswer
 

el muchacho a écrit :

Purée, là, Taz... :heink:

non, je vois l'erreur, maintenant, ça toujours était un comportement indéfini depuis la toute première version du C.

n°748359
vivelec
Posté le 02-06-2004 à 00:57:41  profilanswer
 

el muchacho a écrit :


Sinon, tu es bien la première personne qui me dit passer lint (ou splint ?) sur le code.


En fait, lint est un un vérificateur de code assez tatillon, standard unix.
Mais si lint ne ressort aucun warning, tu peux livrer ton code presque les yeux fermés.

n°748361
el muchach​o
Comfortably Numb
Posté le 02-06-2004 à 00:59:31  profilanswer
 

Je sais, c'est bien pour ça que je n'ai jamais vu personne l'utiliser. Par contre, des gars qui se foutent des warnings du compilo, ça, j'en ai vu...
 
Idéalement, splint utilisé correctement, càd avec des pré et des postconditions et des annotations, c'est mieux.
 
Et des langages modernes et carrés, genre Ocaml ou Eiffel c'est encore mieux. Mais je sais, je rêve... :sleep:


Message édité par el muchacho le 02-06-2004 à 01:06:31
n°748364
Taz
bisounours-codeur
Posté le 02-06-2004 à 01:03:47  profilanswer
 

Code :
  1. benoit@athlon >>> cat torture.c
  2. int main()
  3. {
  4.   int i;
  5.   int *p = (int*)(int)&i;
  6.   *p = 0;
  7.   return 0;
  8. }
  9. [01:03:29][pts/30][/tmp][#89]
  10. benoit@athlon >>> lint torture.c
  11. LCLint 2.4b --- 18 Apr 98
  12. Finished LCLint checking --- no code errors found


autre chose peut être ?

n°748374
vivelec
Posté le 02-06-2004 à 01:30:25  profilanswer
 

Taz a écrit :

Code :
  1. benoit@athlon >>> cat torture.c
  2. int main()
  3. {
  4.   int i;
  5.   int *p = (int*)(int)&i;
  6.   *p = 0;
  7.   return 0;
  8. }
  9. [01:03:29][pts/30][/tmp][#89]
  10. benoit@athlon >>> lint torture.c
  11. LCLint 2.4b --- 18 Apr 98
  12. Finished LCLint checking --- no code errors found


autre chose peut être ?


 
Il faut tout de même retenir que l'implémentation du lint est Os/dépendante donc, dans ce cas prècis, tu as pris le lint de linux qui peut s'avérer moins verbeux que celui de solaris, par exemple.
D'autre part, dans ton exemple, lint n'a pas de raison concrète de réagir sur "int *p = (int*)(int)&i; " puis que tu double-castes de ta propre initiative.

n°748376
vivelec
Posté le 02-06-2004 à 01:34:31  profilanswer
 

el muchacho a écrit :

Je sais, c'est bien pour ça que je n'ai jamais vu personne l'utiliser. Par contre, des gars qui se foutent des warnings du compilo, ça, j'en ai vu...
 
Idéalement, splint utilisé correctement, càd avec des pré et des postconditions et des annotations, c'est mieux.
 
Et des langages modernes et carrés, genre Ocaml ou Eiffel c'est encore mieux. Mais je sais, je rêve... :sleep:


 
A ce niveau-là, j'en suis resté au lint, je n'ai pas beaucoups explorer la manne freeware.
Je testerai splint demain.
Quant aux langages modernes, il y en a tellement eu par le passé ... qui ont défuncté ... raison suffisante, à mon niveau, pour conserver le C (le code doit être maintenable, même 10 ans après).

mood
Publicité
Posté le 02-06-2004 à 01:34:31  profilanswer
 

n°748378
el muchach​o
Comfortably Numb
Posté le 02-06-2004 à 01:43:47  profilanswer
 

Malheureusement, le C n'a jamais été créé pour faire du code sûr. Et c'est d'ailleurs l'un des langages les moins sûrs qui aient jamais été créés.
Résultat, l'industrie paye très très cher son utilisation dans des applis critiques.


Message édité par el muchacho le 02-06-2004 à 01:51:47
n°748380
vivelec
Posté le 02-06-2004 à 01:56:24  profilanswer
 

el muchacho a écrit :

Malheureusement, le C n'a jamais été créé pour faire du code sûr, contrairement à Ada ou Eiffel par exemple. Et c'est d'ailleurs l'un des langages les moins sûrs qui aient jamais été créés.
Résultat, l'industrie paye très très cher son utilisation dans des applis critiques.


Je ne dirais pas que le C n'est pas sûr, mais il est très permissif et mise peut-être un peu trop sur le caractère "responsable" du développeur.
Il nécessite simplement une certaine rigueur et le respect de certaines règles implicites.
Le problème actuel de l'industrie est d'avoir accepter des livraisons sans n'avoir effectué aucun audit.
Maintenant, oui, effectivement, elle en paie les frais.
En même temps, ça génère de la maintenance, donc de l'emploi, ... et donc tout le monde s'y retrouve, moi le premier.
D'où mon pseudo : Vive Le C.

n°748384
el muchach​o
Comfortably Numb
Posté le 02-06-2004 à 02:26:15  profilanswer
 

vivelec a écrit :

Je ne dirais pas que le C n'est pas sûr, mais il est très permissif et mise peut-être un peu trop sur le caractère "responsable" du développeur.
Il nécessite simplement une certaine rigueur et le respect de certaines règles implicites.


 
Moi si, je le dis. Le C permet tout et n'importe quoi, tu as été le premier à le dire en postant ton exemple de tableau non initialisé. Qu'il nécessite de la rigueur, c'est évident, mais c'est le cas quelque soit le langage employé. Simplement, on est moins productif, parce que la découverte des erreurs se fait plus tard et que le temps de mise au point est par conséquent plus long. Et enfin, on n'est jamais certains de la correction du programme, sauf à l'avoir testé de manière exhaustive, ce qui est extrêmement coûteux.
 
[citation]
Le problème actuel de l'industrie est d'avoir accepter des livraisons sans n'avoir effectué aucun audit.
Maintenant, oui, effectivement, elle en paie les frais.
En même temps, ça génère de la maintenance, donc de l'emploi, ... et donc tout le monde s'y retrouve, moi le premier.
D'où mon pseudo : Vive Le C.
[/citation]
 
C'est sûr. Mais je pense que c'est un faux argument, car de toute façon, on ferait d'autres développements. Fort heureusement, on ne s'est pas limité à Algol et à Cobol pour sauvegarder l'emploi des informaticiens. Aujourd'hui, plus personne n'a envie de faire de la maintenance Cobol qund on peut faire du Java à la place.  
Je maintiens que l'industrie paye cher son conservatisme quand il existe des outils plus adaptés.

n°748403
Taz
bisounours-codeur
Posté le 02-06-2004 à 07:18:22  profilanswer
 

vivelec a écrit :

D'autre part, dans ton exemple, lint n'a pas de raison concrète de réagir sur "int *p = (int*)(int)&i; " puis que tu double-castes de ta propre initiative.

ah bon ? genre ça te pose pas de problème de caster un T* en int ?

n°748464
vivelec
Posté le 02-06-2004 à 09:09:00  profilanswer
 

Taz a écrit :

ah bon ? genre ça te pose pas de problème de caster un T* en int ?


Le C est permissif.
Ceci dit non, sur une architecture 32 bits, il n'y a aucun problème.
C'est sale, mais ça ne core pas.

n°748509
cricri_
Posté le 02-06-2004 à 09:58:34  profilanswer
 

Joel F a écrit :

Essaye ca :
 

Code :
  1. short * buf[2][10];
  2. short *** GetBuffer(void)
  3. {
  4. return( &buf[0]);
  5. }




vi, j'ai essayé ça aussi mais j'ai la même erreur.
 
Taz : effectivement je suis conscient d'avoir perdu la dimension avec ce pointeur ...
 
bon, pis vous fachez pas à cause de ma question à la c*n ...  :whistle:
C'était surtout pour comprendre la différence, et voir s'il y avait un moyen d'écrire ça proprement sans cast sauvage.
je vais faire autrement.
 

n°748516
Taz
bisounours-codeur
Posté le 02-06-2004 à 10:03:22  profilanswer
 

vivelec a écrit :

Le C est permissif.
Ceci dit non, sur une architecture 32 bits, il n'y a aucun problème.
C'est sale, mais ça ne core pas.

bien vu, alors qu'est-ce que tu viens nous parler de portabilité et à nous la jouer expert si après tu nous dis que ça ne pose aucun problème sur un système 32bits ...

n°748644
vivelec
Posté le 02-06-2004 à 11:51:33  profilanswer
 

Taz a écrit :

bien vu, alors qu'est-ce que tu viens nous parler de portabilité et à nous la jouer expert si après tu nous dis que ça ne pose aucun problème sur un système 32bits ...


Ecoute Taz, il y a deux ou trois choses que tu n'as pas encore comprises :  
- on ne détourne pas les propos des autres
- un forum peut être consulté par des recruteurs potentiels, et en l'occurence j'en suis un.  
Et franchement, si par malheur je t'avais eu comme salarié, j'aurais tout fait pour te virer. Les bases mêmes de l'esprit d'équipe sont la courtoisie et l'entre-aide. Tu n'en respectes aucune.
- il y a un gros delta entre le monde universtaire dans lequel tu es et le milieu industriel : concrètement quand t'auras fini ta maîtrise, tu auras tout à apprendre.
- linux n'est pas unix.
Si tu veux continuer à avoir un tel comportement, tâche au moins de ne pas faire référence à ton site perso et à tes noms et prénoms. Je te rappelle encore une fois que le monde de l'informatique est très petit. On revoit toujours les mêmes têtes.
Maintenant franchement, tu me pompes avec tes remarques à deux balles et j'ai autre chose à faire que te d'écouter meugler.

n°748774
Taz
bisounours-codeur
Posté le 02-06-2004 à 13:17:24  profilanswer
 

mince alors ... bon allez, tu veux que je t'insultes pour être sur de jamais te voir ?
 
t'es un mariole, un amateur, voilà tout. le reste je m'en fiche.mais pour dire aux autres qu'ils sont frustrés, ça y va. l'amateur, on en a tous eu la preuve plusieurs fois, c'est toi.

n°748786
bjone
Insert booze to continue
Posté le 02-06-2004 à 13:31:16  profilanswer
 

on s'calme ici.
 
J'ai l'impression de voir des supporters de football.

n°748802
drasche
Posté le 02-06-2004 à 13:49:05  profilanswer
 

vivelec a écrit :

Le C est permissif.
Ceci dit non, sur une architecture 32 bits, il n'y a aucun problème.
C'est sale, mais ça ne core pas.


ici on n'aime pas ce qui est sale, mais si ça plante pas :o
si tu veux discuter avec Taz, t'as intérêt à maîtriser cette notion aussi vite que possible :D (c'est pareil avec les autres habitués d'ailleurs :o)


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
n°748805
lordankou
Posté le 02-06-2004 à 13:57:09  profilanswer
 

un short *** c pas bo ?
ça donne quoi alors une structure donc je passe une partie en paramètre avec un char *** ?  
bouh j'ai pas hate de voir la réponse lol


---------------

n°748813
el muchach​o
Comfortably Numb
Posté le 02-06-2004 à 14:01:26  profilanswer
 

C'est fini, ces disputes d'ados prépubères ?
 
vivelec a visiblement AUSSI des choses intéressantes à dire.
Merci de ne pas faire fuir tous les nouveaux qui peuvent apporter qq chose à e forum, comme ce fut le cas avec assyrium, par exemple.

n°748825
lordankou
Posté le 02-06-2004 à 14:11:15  profilanswer
 

euh ma question est sérieuse car j'ai des doutes sur ma structure...
 

Code :
  1. // structure du tableau contenant les vecteurs vitesses  
  2. typedef struct Tableau
  3. {
  4.     // tableau contenant les coordonnes du vecteur propre à un fichier
  5.     float ** tabCoordonnees;
  6.     // nombre de vecteurs vitesse
  7.     int NombreVecteur ;
  8.     // nom du fichier correspondant aux mesures;
  9.     char * NomDuFichier;
  10.     // heures de la mesure
  11.     char * HeureMesure;
  12.     // pointeur vers le tableau suivant
  13.     struct Tableau * suivant ;
  14. } TableauVitesse ; // nom final de la structure


 
de plus j'utilise pour stocker des noms de fichier un char ** que je dois passer en paramètre ce qui me donne donc un char ***
de plus je gère tout en dynamique et je me pose la question de savoir si il n'y a pas des risques d'écritures en mémoires (à l'exception de mes propres erreurs)


---------------

n°748843
Taz
bisounours-codeur
Posté le 02-06-2004 à 14:20:07  profilanswer
 

ben elle est bonne ta structure. pour le reste, à toi de pas faire n'importe quoi avec tes pointeurs.

n°748866
lordankou
Posté le 02-06-2004 à 14:28:28  profilanswer
 

mici monsieur Taz. j'avais vraiment un doute sur la structure. bon ensuite vais réfléchir un peu sur l'algo et tout ce qu'il y a avant !


---------------

n°749695
vivelec
Posté le 02-06-2004 à 23:08:08  profilanswer
 

drasche a écrit :

ici on n'aime pas ce qui est sale, mais si ça plante pas :o
si tu veux discuter avec Taz, t'as intérêt à maîtriser cette notion aussi vite que possible :D (c'est pareil avec les autres habitués d'ailleurs :o)


C'est ton copain taz qui a codé cette merde pour tester lint, pas moi.

n°749696
vivelec
Posté le 02-06-2004 à 23:09:19  profilanswer
 

lordankou a écrit :

un short *** c pas bo ?
ça donne quoi alors une structure donc je passe une partie en paramètre avec un char *** ?  
bouh j'ai pas hate de voir la réponse lol


En clair, tu fais ce que tu veux.
Sur linux : char *******
Sur unix : char ** max.

n°749712
Joel F
Real men use unique_ptr
Posté le 02-06-2004 à 23:29:54  profilanswer
 

vivelec a écrit :

En clair, tu fais ce que tu veux.
Sur linux : char *******
Sur unix : char ** max.


 
Encore une fois NON !
gcc 3.3.1 pour SUN ou AIX supporte aprfaitement un niveau quelconque d'indirection !

n°749728
vivelec
Posté le 02-06-2004 à 23:32:55  profilanswer
 

Joel F a écrit :

Encore une fois NON !
gcc 3.3.1 pour SUN ou AIX supporte aprfaitement un niveau quelconque d'indirection !


Justement, il se pose des problèmes avec gcc.
Une archive (.a) basée sur des compils gcc ne sont pas compatibles avec les cc constructeurs.
En d'autres termes, les .o ne sont pas portables entre compilos.

n°749730
Joel F
Real men use unique_ptr
Posté le 02-06-2004 à 23:33:31  profilanswer
 

vivelec a écrit :

Justement, il se pose des problèmes avec gcc.
Une archive (.a) basée sur des compils gcc ne sont pas compatibles avec les cc constructeurs.
En d'autres termes, les .o ne sont pas portables entre compilos.


 
j'abandonne , t'es trop obtus c'est pas possible  [:everything4free]

n°749743
vivelec
Posté le 02-06-2004 à 23:48:40  profilanswer
 

Joel F a écrit :

j'abandonne , t'es trop obtus c'est pas possible  [:everything4free]


Je ne suis pas obtus, mais confronté à ce genre de problème tous les jours avec des contraintes de temps.

n°749745
Joel F
Real men use unique_ptr
Posté le 02-06-2004 à 23:49:47  profilanswer
 

bon ok t'as gagné, je ressort mon gcc 1.0.2beta, je fait plus d'objet et j'oublie l'existence des templates, du C99 et du metaprogramming, welcome to the seventies.

n°749755
vivelec
Posté le 02-06-2004 à 23:57:06  profilanswer
 

Joel F a écrit :

bon ok t'as gagné, je ressort mon gcc 1.0.2beta, je fait plus d'objet et j'oublie l'existence des templates, du C99 et du metaprogramming, welcome to the seventies.


Je t'avouerais que je suis aussi embêté que toi.
Il y a aujourd'hui des binaires "commerciaux" compatibles exclusivement gcc.
Je n'invente rien.
Quant aux seventies, ne te trompe pas de décade, à environ 5 ans d'intervalle on a le même âge.
Simplement, l'industrie (et oui) fait vieillir plus tôt que prévu.

n°749759
Joel F
Real men use unique_ptr
Posté le 02-06-2004 à 23:58:42  profilanswer
 

vivelec a écrit :


Il y a aujourd'hui des binaires "commerciaux" compatibles exclusivement gcc.


ben c'est des abérrations, faudrait que ces gens "de l'industrie" se mettent du plomb dans la tête ...
 

vivelec a écrit :


Simplement, l'industrie (et oui) fait vieillir plus tôt que prévu.


l'industrie c'est le mal :o

n°749765
vivelec
Posté le 03-06-2004 à 00:03:24  profilanswer
 

Joel F a écrit :

ben c'est des abérrations, faudrait que ces gens "de l'industrie" se mettent du plomb dans la tête ...
 
 
l'industrie c'est le mal :o


Je suis d'accord, cependant, c'est dont il est question plus haut.
Plus on complexifie, plus il y a besoin de ressources, plus il y a de business, plus ...
Conclusion, il faut bénir l'industrie.
Avec 20% des effectifs actuels en informatique, les S.I. seraient plus stables et tourneraient, pourquoi pas, sur des clusters linux.
Mais s'il n'y avait que ça ...
L'essentiel, encore une fois, c'est de manger, et bien, de préférence.
Donc, ne crachons pas dans la soupe.

n°750247
docmaboul
Posté le 03-06-2004 à 10:33:41  profilanswer
 

Taz a écrit :

c'est pas parce que tu utilises des sytèmes pourris et que tu as des admin systèmes payés à rien foutre que tout le monde doit faire pareil. y a des gens qui aiment profiter des dernières technologies et de la dernière version de leur compilateur, parce qu'ils constatent que cela accroit leur productivité. bien sur ça demande de la formation


 
Oula, cela ne marche pas comme ça dans l'industrie. Nouvelles technologies <=> suspiscion (il faut d'abord faire ses preuves). Je me souviens encore de mon premier jour ou, architecte fraîchement émoulu de l'école, j'arrive sur mon tout premier projet. Le directeur technique m'accueille me présente l'équipe, me donne mon compte sur le serveur de dev, un peu de doc à potasser, ... Je vois qu'il y a un "module commun" dans leur affaire servant dans tous les programmes. La doc ne dit quasiment rien à ce propos et je me dis donc que je vais aller lire le code histoire de voir ce qu'on y trouve. Là, je tombe sur des horreurs du type:
 

Code :
  1. char * prout()
  2. {
  3.   char sz[123];
  4.   /* prout prout prout */
  5.   return sz;
  6. }


 
Je m'en fais donc une copie locale et je corrige les bugs. En milieu d'après-midi, le directeur technique revient me voir pour savoir comment ça se passe.
 
Moi: j'ai trouvé des bugs dans le module commun
Lui: ah bon? fait voir...
M: ben, je les ai corrigés
L: ah non. Ca va nous obliger à re-tester tous nos programmes
M: Quand même! Ca va péter tôt ou tard là, et ils n'en marcheront que mieux.
L: Ecoute, tu es nouveau, tu viens d'arriver et toute modification dans le code oblige à re-tester les programmes. Ca va nous coûter très cher ton histoire.
M: Bon, on pourrait au moins mettre des commentaires avec mes corrections là où ils se trouvent histoire de les signaler.
L: Non. Tu ne te rends pas compte mais tes commentaires pourraient entraîner des bugs dans le compilateur.
M: Hein???  
L: Tu oublies ces bugs et tu continues à lire ta doc. Tu n'es pas développeur, d'accord?
M: D'accord. Mais qui est le programmeur ayant écrit le module commun?
L: C'est moi, pourquoi?
M: heuuu, pour rien...
 
Ce directeur technique était un gros nullos mais qui avait réussi à gravir lentement les échelons de la hiérarchie; des comme lui, on en trouve partout et à la pelle. En outre, ils bloquent souvent toute installation jugée, par eux, comme non-nécessaire (par exemple d'un gcc sur un sun ou d'une stl correcte sur un nt). Bref, si tu crois qu'on va te dérouler le tapis rouge en te disant "oh taz, tu manipules les streambufs comme un Dieu, ta parole est d'or", tu risques d'être fort déçu...

n°750253
Joel F
Real men use unique_ptr
Posté le 03-06-2004 à 10:36:14  profilanswer
 

bon ok, on est bien d'accord que les industriels sont des gros boulets. C'est pas une raison pour déblatarer des conneries sur tout et n'importequoi.

n°750267
docmaboul
Posté le 03-06-2004 à 10:40:32  profilanswer
 

Taz a écrit :

moi j'aime bien les mecs comme vivelec et doc maboule qui se réfugit derrière les arguments ad hominem.


Comme quand tu écris, je ne sais plus où, que la taille de la stack dépend du système? Manque de pot, c'est encore une question de runtime...

n°750284
Taz
bisounours-codeur
Posté le 03-06-2004 à 10:46:30  profilanswer
 

DocMaboul a écrit :

Comme quand tu écris, je ne sais plus où, que la taille de la stack dépend du système? Manque de pot, c'est encore une question de runtime...

oui, je me suis mal exprimé effectivement.
 
EDIT : non d'ailleurs, j'ai rien de tel. j'ai juste répondu à  
 
« Comment je la connais, la limite de ma pile ?  »
 
par
 
« ça dépend de ton système »


Message édité par Taz le 03-06-2004 à 10:48:31
n°750288
docmaboul
Posté le 03-06-2004 à 10:49:34  profilanswer
 

Joel F a écrit :

bon ok, on est bien d'accord que les industriels sont des gros boulets. C'est pas une raison pour déblatarer des conneries sur tout et n'importequoi.


 
Pas tous mais beaucoup, oui, on est d'accord. Après raconter n'importe quoi en info, c'est bien ce qui est commun à tout le monde. En clair, je n'ai jamais rencontré personne qui ne raconte pas un jour ou l'autre n'importe quoi. Un muet pourrait peut-être y arriver...

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4

Aller à :
Ajouter une réponse
 

Sujets relatifs
Parcourir un tableau à colonnes variablessauver un tableau de short dans un format d'image
Pointeurs je comprends plus rienefacer les caractere d'un tableau de char
[C] obtenir une adresse de broadcast[HTML & PHP] Passage variable en adresse
Récupérer une adresse mac[perl] conversion d'hexa vers decimal
conversion CString à intProblème de tableau dynamique
Plus de sujets relatifs à : conversion adresse de tableau de pointeurs


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR