[Dwelfigor]

Citation :

Provient du message de poolet
Ok je comprends que ca pose problème pour la programmation système, mais pour les noms de fonctions et de prototypes, c'est bien une question de librarie non ? ça n'a rien à voir avec l'OS je crois..

printf --> stdio.h
std::cout --> iostream.h

pour windows et Linux c'est pareil non ? (j'ai jamais tapé une ligne de code sous windows)

windows ou linux le langage reste le meme. a part les librairies developpées par le constructeur.

Mais stdio.h
et iostream.h font partie des plus classics toujours utilisées dans un prog.

[Lwevin Myan]

Citation :

Provient du message de poolet
Ok je comprends que ca pose problème pour la programmation système, mais pour les noms de fonctions et de prototypes, c'est bien une question de librarie non ? ça n'a rien à voir avec l'OS je crois..

printf --> stdio.h
std::cout --> iostream.h

pour windows et Linux c'est pareil non ? (j'ai jamais tapé une ligne de code sous windows)

C'est sûr que "Hello World" est multi-plateforme

Ce que je voulais dire, c'est que le C est un langage qui n'est pas si haut niveau que cela. Il y a des choses qui passent sans (trop de) douleur, et d'autres beaucoup moins bien. Et en vertu de la loi de Murphy, la deuxième catégorie est beaucoup plus importante

Le fait de pouvoir accéder aux pointeurs, donc la mémoire comme on veut (quitte à aller chercher à l'indice -1 d'un tableau tant "qu'on sait ce qu'on fait", je sais plus dans quel bouquin j'avais lu ça... je me demande si ce n'était pas dans le K&R, d'ailleurs) est d'ailleurs révélateur du caractère hautement bidouillatoire de ce langage (ce n'est nullement une critique, et le C est de très loin le langage impératif que je préfère).

[Dwelfigor]

Citation :

Provient du message de Lwevin Myan
Le fait de pouvoir accéder aux pointeurs, donc la mémoire comme on veut (quitte à aller chercher à l'indice -1 d'un tableau tant "qu'on sait ce qu'on fait", je sais plus dans quel bouquin j'avais lu ça... je me demande si ce n'était pas dans le K&R, d'ailleurs) est d'ailleurs révélateur du caractère hautement bidouillatoire de ce langage (ce n'est nullement une critique, et le C est de très loin le langage impératif que je préfère).

C'est vrai que ça c'est cho. Mais quand on maitrise c'est overbon !

C'est l'avantage du C sur un max d'autres langages.

[powleT]

mais non lol, ce que j'veux dire c'est que pour les fonctions du système, ok ca pose problème pour le portage, mais ça c'est facilement arrangeable, mais ça pose pas d'autres problèmes, à la compilation notamment ?

par exemple un code (qui est portable et utilise les libraries standard, hello world avec stdio), ne marchera pas s'il à été compilé sous Linux et lancé sous windows, et inversement ? ou ça marchera nickel ?

le portage, ça coince juste au niveau des fonctions de l'OS, ou ya d'autres trucs ??

si c'est juste pour les fonctions système, moi je trouve pas ça difficile à modifier

enfin, je suis pas un boss de la prog hein lol

[BustaK]

Je suis assez noob dans ce milieu qu'est la programmation, mais j'ai un logiciel (3D game creator/directx 7), il existe aussi une version pro/directx 9.
Donc c'est pour créer des jeux, mais peut tout à fait servir à faire des programmes 2D et autres.
Le langage c'est du DarkBasic. Par rapport à du C j'ai lu en comparaison, 400 lignes de prog en DB = 10 000 lignes de prog en C pour une fonction similaire.

Enfin c'est un bon petit logiciel avec plein de tutoriels, pour les noobz comme moi.

Plus d'informations ici.

[Kathar - Alleria - Lango]

Bon il faut bien quelqu'un pour défendre caml...

Alors déjà je ne vois pas ce qu'il y a de drole à lui proposer ce langage, il est certainement beaucoup plus simple à utiliser que la majorité des langages proposés ici.

Caml est un langage très structuré, très logique. La manière de programmer usuelle en caml, c'est d'utiliser au maximum la récursivité terminale. C'est un peu déroutant pour quelqu'un qui n'a pas l'habitude, mais

1. quand on en prend l'habitude sur certaines structures de données c'est beaucoup plus logique, rapide, simple
2. il existe aussi des boucles en caml si vous voulez vraiment pas

Voilà, sinon le gros avantage de caml est qu'il permet de créer et manipuler très facilement des structures de données complexes (listes, arbres, tables de haschage, ...) sans avoir à se soucier de la mémoire allouée et autres trucs chiants du c.

Pour finir, je dirais que le seul inconvénient du caml, c'est qu'une fois que tu y auras gouté, tu ne voudras plus jamais utiliser les autres langages

[Lwevin Myan]

Citation :

Provient du message de poolet
mais non lol, ce que j'veux dire c'est que pour les fonctions du système, ok ca pose problème pour le portage, mais ça c'est facilement arrangeable, mais ça pose pas d'autres problèmes, à la compilation notamment ?

Facilement arrangeable ?
Si tu as des choses simples à code, oui, c'est facile.
Si ton programme doit être interruptible ou multi-thread, par exemple, tu n'as pas fini de t'amuser.
Parce que les librairies standard, c'est bien gentil, mais si tu veux faire quoique ce soit d'un tant soi peu évolué, il faut utiliser des appels spécifiques au constructeur, et là, les ennuis commencent.
Sans parler des problèmes de compilation dûs au compilateur lui-même, et à l'interprétation du langage : dernier exemple de ce matin : xlC sous aix (je ne connais pas les versions j'ai juste dépanné ) ne reconnait pas la déclaration d'une union contenant un struct anonyme, ce qui tournait parfaitement sous dec. Il faut nommer le struct en dehors de la déclaration de l'union, et créer un champ de l'union référençant la nouvelle structure.
Comme il y a un nouveau champ, cela impacte tous les endroits où l'on faisait référence à la structure anonyme.
D'ailleurs, si quelqu'un connait une solution moins coûteuse, mon collègue serait fort heureux de la connaître et de ne pas avoir à modifier quelques milliers de lignes de code

Citation :

par exemple un code (qui est portable et utilise les libraries standard, hello world avec stdio), ne marchera pas s'il à été compilé sous Linux et lancé sous windows, et inversement ? ou ça marchera nickel ?

Non. Un code compilé sous Linux n'est pas un exécutable Win32, et inversement. Et c'est encore pire pour les librairies (.dll / .so) qui ne sont pas du tout générées de la même manière.
Par contre, si le source ne contient que du code standard C, en théorie, c'est censé compiler sur les deux plate-formes sans la moindre modification. Enfin, ça, c'est la théorie. Dans la pratique, je n'ai jamais vu de code "portable" sans #ifdef WIN32.

Citation :

le portage, ça coince juste au niveau des fonctions de l'OS, ou ya d'autres trucs ??

si c'est juste pour les fonctions système, moi je trouve pas ça difficile à modifier

Ben, portes un programme professionnel (j'entends à la différence d'un programme pour particulier, qui ne servira qu'à celui qui l'a développé), et on en reparle
Parce que les fonctions constructeurs, ça englobe tout et n'importe quoi (surtout du n'importe quoi, d'ailleurs), et à un moment, il faut y passer.

Pour Lango : je suis un fanatique des langages fonctionnels, mais force est de reconnaître que ce n'est pas la chose la plus simple à appréhender au départ. Et je me rappelle très clairement que dans les cours que j'ai eu, il n'y avait pas 5% des étudiants qui comprenaient le sujet => quasiment tout le monde codait en Caml ou en Scheme comme ils auraient codé en C, ce qui donnait évidemment lieu à des résultats lamentables.
Par ailleurs, ces langages sont réellement de haut niveau, et ne donnent plus accès à la mémoire. Or, c'était une particularité signalée dans le post de départ

[Dwelfigor]

Ha ça finie en manif pour les langages !

Bon OK !

LE FORTRANT VAINCRA

[Kathandro Jourgensen]

Citation :

Provient du message de Dwelfigor
Ha ça finie en manif pour les langages !

Bon OK !

LE FORTRANT VAINCRA

COBOL FOREVER!!

Bon, plus sérieusement, ça ressemble à quoi le Basic???
Sinon, on s'éloigne un peu du sujet originel qui est pas un concours de b... pissage de lignes, mais une solution pour monsieur qui sait programmer en Basic...