de la TI au PC moi aussi - Page 1

j'ai fais de la programmation en C sur TI, et je voudrais passer au PC, histoire de faire qqes progs sympas

quel langage me conseillez vous ? le C ?

j'aimerais par exemple pour commencer faire un ptit prog qui affiche la temperature du proco, de la motherboard, la ram restante, le %age du CPU utilisé, la batterie restante...
le C peut le faire sans pb ?

je suis ouvert a tt langage (enfin quasiment) a apprendre, mais je prefererais un qui soit assez rapide a apprendre

je ne cherche pas a faire des prog ultra optimisé (jeux par exemple...) donc pas besoin d'un langage qui soit super rapide

merci

c / c++ sur pc c pas mal

Le C++ est nettement plus facile pour programmer des applications tournant sous windows ... (ca permet de bien utiliser toutes les classes pratiques)
Maintenant, pour afficher la température de ta carte mère bonne chance ... ca doit bien se faire une fois que t'as trouver le truc

Je conseille le C.

Je conseille le C++.

Pourquoi?
* Obza_Fazer connaît déjà le C.
* Pourquoi utiliser un langage inefficace (C++) plutôt qu'un langage efficace (C)?
Bref, à moins de vouloir travailler avec un IDE de style QT Designer qui favorise clairement le C++ (et ce n'est pas le cas de la plupart des IDEs), je ne vois pas l'intérêt d'utiliser du C++ quand on est habitué au C.

Comme le dit nEUrOO, programmer des applications graphiques en C++ est beaucoup plus simple. De plus le C++ permet de passer plus de temps à programmer les choses utiles, au lieu de se prendre la tete sur des problemes bas niveaux qui sont source de bugs. Pourquoi recoder une gestion de listes chainées en C alors qu'en C++ un std::list le fait automatiquement de manière efficace, sans avoir besoin de lib externe.

> Obza_Fazer connaît déjà le C
il a dit "je suis ouvert a tt langage (enfin quasiment) a apprendre, mais je prefererais un qui soit assez rapide a apprendre" et le C++ est une évolution logique lorsqu'on connait le C.

> Pourquoi utiliser un langage inefficace (C++) plutôt qu'un langage efficace (C)?
il a dit "pas besoin d'un langage qui soit super rapide" et d'une manière générale le C++ réduit le temps de développement et débuggage, et c'est une très bonne raison pour l'utiliser.

Bah, pour les listes chaînées en C, il y a list.h dans les sources de ld-tigcc (donc sous GPL) qui est très pratique.

De tte facon, C++ est plus pratique et sera bien souvent plus efficace, par exemple tous les algos de la STL sont assurément mieux programmés que ce que l'on pourrait faire

Pfff... n'importe quoi! Rien que le simple fait que ça utilise les templates fait que c'est inefficace!

Kevin Kofler
: Pfff... n'importe quoi! Rien que le simple fait que ça utilise les templates fait que c'est inefficace!

N'importe quoi... encore un qui ne sait pas de quoi il parle.
Allez un exemple concret : http://theory.stanford.edu/~amitp/rants/c++-vs-c/

Bah, son problème était que la fonction de comparaison n'était pas inlinable dans la fonction qsort parce qu'elles étaient dans des "translation units" différentes, d'où les appels de fonction inutiles qui ralentissaient tout. Ça ne sera plus un problème avec les compilateurs en développement (en partant de GCC 3.4, qui sait déjà faire de l'inlining à travers plusieurs "translation units" - cela dit, ça ne marche pas encore avec des librairies, donc il faut linker directement avec qsort.c). Et puis, rien n'empêche la librairie C de faire la même chose que la STL et de mettre toute la fonction de tri dans le header, permettant ainsi l'inlining.
Quant à la différence entre les routines spécialisées (la sienne et celle de Numerical Recipes) et la STL, c'est tout simplement que les routines spécialisées étaient mal codées (il avoue lui-même que la sienne était mal fichue, et il passe son temps à critiquer l'autre).

Ouais, ben le résultat est ce qu'il est.

En C++, les templates permettent d'écrire du code à la fois typé (donc moins de bugs), générique (on écrit une fois l'algorithme et il tourne avec tous les types de données), et efficace (le compilateur génère du code spécialisé donc optimisé). En C il n'y a pas de mécanisme permettant de réunir les 3 avantages.

Et la bibliothèque standard décharge le programmeur de la gestion mémoire bas niveau pour les types de données de base (listes, chaines de caractères, tables de hachage, tableaux dynamiques, ...), d'où une réduction significative du temps de débuggage. Et moins de temps passé à débugger, c'est plus de temps à écrire du code utile.

Personnellement, je ne comprends pas pourquoi tout le monde a tellement peur de la gestion mémoire. Je me débrouille en général très bien avec realloc. C'est quand on essaye d'"optimiser" en réduisant le nombre de realloc (chose qui est assez ridicule parce qu'avec une bonne implémentation de realloc (qui ne déplace le bloc que quand il n'y a pas de place libre juste après), la plupart des appels à realloc sont en O(1)) que ça se complique. Si on réalloue à chaque fois que la taille change (ce qui, comme je viens d'expliquer, ne devrait pas être un problème en pratique, ou alors c'est la libc et/ou le système d'exploitation qui est/sont mal foutu(e)(s)), c'est facile.

Par exemple, concaténer 2 chaînes de caractères C sans problèmes de buffers est facile:

__attribute__((noreturn)) static void outofmem(void)
{
  fprintf(stderr,"Fatal error: not enough free memory\n");
  exit(-1);
}

static char *dynstrcat(char *s, const char *t)
{
  char *p;
  size_t l = strlen(s) + strlen(t) + 1;
  p = realloc(s,l);
  if (p) {
    strcat(p,t);
    return p;    
  } else {
    free(s);
    outofmem();
  }
}

Et cette fonction peut être utilisé presque comme strcat, la seule différence est que la valeur de retour ne peut pas être négligée. Donc s=dynstrcat(s,t);.

Kevin Kofler :
Personnellement, je ne comprends pas pourquoi tout le monde a tellement peur de la gestion mémoire. Je me débrouille en général très bien avec realloc.

Le simple fait d'écrire du code qui manipule de la mémoire est risqué, et est source de bugs graves et subtils à découvrir car non déterministes dans le cas général. Maintenant, même si toi tu te débrouilles très bien, ce n'est pas le cas de tout le monde. Et comme de toute façon ce code est déjà écrit et déjà débuggé dans la STL, le fait de l'utiliser apporte à la fois la sécurité, et un gain de temps.

Et puis, Obza, c'est bcp plus jouissif de coder C++ que C (rien que ds la forme du code, le C++ est magnifique)

euh Kevin, j'ai toujours code en C, et maintenant que je fais un _gros_ proj (par gros, je veux vraiment dire gros, sans doute pas comparable avec ce que toi tu fais), je regrette enormement de pas m'etre mis au C++ avant, vu que je le code en C. et la devine quoi? je me retrouve a emuler des features C++ en C pour avoir le niveau de flexibilite et d'abstraction que je veux. le C est tres bien pour certains trucs, certes.. tu peux meme tout faire en C... presque aussi simplement qu'en C++... du moment que tu fais rien d'autre de plus complexe que des "listes chainees" arrive un moment ou tu as besoin d'un niveau d'abstraction que tu ne _peux_pas_ avoir avec le C...

C'est quand on essaye d'"optimiser" en réduisant le nombre de realloc (chose qui est assez ridicule parce qu'avec une bonne implémentation de realloc (qui ne déplace le bloc que quand il n'y a pas de place libre juste après), la plupart des appels à realloc sont en O(1)) que ça se complique. Si on réalloue à chaque fois que la taille change (ce qui, comme je viens d'expliquer, ne devrait pas être un problème en pratique, ou alors c'est la libc et/ou le système d'exploitation qui est/sont mal foutu(e)(s)), c'est facile.

tu raconte n'importe quoi... tu veux parler de "performance"?
c'est pas le fait d'utiliser realloc qui est bon ou mauvais, c'est comment tu l'utilise, et la facon dont tu suggere de s'en servir est completement immonde...
je parle de ca: "Si on réalloue à chaque fois que la taille change (ce qui, comme je viens d'expliquer, ne devrait pas être un problème en pratique, ou alors c'est la libc et/ou le système d'exploitation qui est/sont mal foutu(e)(s)), c'est facile."

t'es tellement sur de toi que tu dis des trucs qui sont aberrants point de vue "performance", et rejeter la faute sur l'implementation de la libc c'est sans doute le truc le plus debile que tu peux faire dans ce cas. petite anecdote (pour realloc, et juste pour demonter ton affirmation d'au dessus... oui je sais j'ai rien d'autre a foutre):
l'annee derniere, pour un de mes projs, j'avais (entre autres), un repertoire a scanner pour des fichiers contenant des scripts de shaders (graphiques). le repertoire de test contenait plus de 100 fichiers .shader, avec en moyenne plus de 30 shaders par fichier.
le premier truc que j'ai fait etait pour chaque fichier de parser tous les shaders qu'il contenait, et a chaque shader valide, reallouer le tableau de shaders dans lequel ils etaient stockes.
ca marchait tres bien, hormis que le temps de loading de l'application etait passe de 2-3 secondes a quasiment 1 minute... tres bien, on sort gprof, et oh surprise...
memcpy: 97/98%
mais comme c'est bizarre j'utlisais quasiment aucun memcpy
or realloc, comme tu le sais, quand il n'a plus de place pour etendre la zone memoire a reallouer, il realloue la nouvelle ailleurs, et recopie le contenu de l'ancienne dans la nouvelle, a coups de... memcpy.
en inserant quelques lignes de debug, il est apparu que les 1000-1500 premiers appels a realloc etaient faits en un laps de temps relativement court, mais qu'au fur et a mesure que la taille du tableau augmentait, il devenait de plus en plus difficile d'etendre la memoire a la suite de la zone allouee courante (sans doute pke le heap se faisait fragmenter du a quelques strdup et autres allocations mineures entre deux realloc, j'ai pas approfondi ca), du coup les derniers appels a realloc avaient lieu quasiment a plusieurs secondes d'intervalle, ce qui signifie que c'etait la fonction realloc qui bouffait ces secondes a elle toute seule...

donc deja ton "Si on réalloue à chaque fois que la taille change (ce qui, comme je viens d'expliquer, ne devrait pas être un problème en pratique, ou alors c'est la libc et/ou le système d'exploitation qui est/sont mal foutu(e)(s))" est completement foireux...

ensuite, au lieu de reallouer "à chaque fois que la taille change" ©, j'ai essaye de reallouer par "blocs" de 128 cases a la fois... deja bcp mieux, c'est descendu en dessous de 10 secondes (mais ca va pas te plaire de toute facons, vu que oooh ca fait perdre tout plein d'octets inutiles )

alors biensur, ca aurait pu etre un tableau de pointeurs au lieu d'un tableau de grosses structures, mais le pbl n'est pas la...

finalement, j'ai laisse tomber realloc, et j'ai plutot "parse" deux fois chaque fichiers, ou plutot, deux passes: la premiere pour compter le nombre de shaders (tres rapide, juste un comptage d'accollades avec 2-3 autres check), malloc a la bonne taille du tableau, et vrai parsing apres.
et la miracle, redescendu a 3-4 secondes.
donc quand tu veux parler d'un truc, histoire d'etre un minimum credible, par pitie evite de sortir des conneries pareilles...

ah oui, au fait, dans l'exemple ci dessus, je n'ai pas utilise de tableau de pointeurs parceque ca aurait fait perdre beaucoup de memoire, meme compare au realloc de 128 cases d'un coup...

je precise: dans l'exemple ci dessus, ou ma structure faisait 132 octets... ca depend des cas, et c'est pour ca que tu ne peux pas te permettre d'affirmer des trucs comme tu l'as fait, en les presentant comme des verites universelles en etant aussi sur de toi...

faudrait que tu songe a evoluer un peu... tu me fais penser a un gars avec sa regle a calculer qui s'obstine a l'utiliser alors que des calculatrices arrivent sur le marche...
(aucun rapport je sais, c juste une image...)

edit: pour repondre au topic: C++

Je répète que si ton realloc place tes blocs d'une manière que le prochain realloc aura à les redéplacer encore une fois, c'est ta libc qui est mal foutue. C'est du M$ (auquel cas ça ne m'étonne pas) ou du GNU? Dans ce dernier cas, envoie un bug report.

non c'est pas du "M$"...
c'etait sous NetBSD 1.6 Beta

et je ne pense pas que ca soit un bug non
en fait ca marche tres bien et c'est comme ca que c'est cense marcher selon le man. un realloc ne peut pas deviner a l'avance quelle sera la taille du buffer apres de multiples reallocations.
ton implementation ideale de realloc fonctionnerait comment cher kevin? (explique autrement que par un truc du genre "allouer le buffer la ou y a assez de place devant pour les prochaines allocations" )

Je conseille le caml

lol

sBibi
: c'etait sous NetBSD 1.6 Beta

Bug report...

et je ne pense pas que ca soit un bug non
en fait ca marche tres bien et c'est comme ca que c'est cense marcher selon le man. un realloc ne peut pas deviner a l'avance quelle sera la taille du buffer apres de multiples reallocations. ton implementation ideale de realloc fonctionnerait comment cher kevin? (explique autrement que par un truc du genre "allouer le buffer la ou y a assez de place devant pour les prochaines allocations"

"allouer le buffer la ou y a assez de place après pour les prochaines allocations"
Pourquoi "devant"?
Et pour "assez de place", ben n'importe quel minimum. Toute valeur strictement positive est bonne pour éviter de devoir déplacer un bloc à chaque fois.

Et au fait, j'ai comparé les sources de realloc version GNU et version NetBSD, et la version GNU m'a l'air beaucoup plus intelligente. La version NetBSD:
* copie le bloc même si c'est pour le rendre plus petit. C'est idiot. On peut libérer l'espace économisé sans tout recopier.
* passe au recopiage dès que la page de RAM est finie. Elle ne va même pas voir à la page d'après si elle est libre. Ce n'est pas malin.

Et pour les gros tableaux (>128K), il y a ça dans la version GNU:

  Large chunks that were internally obtained via mmap will always
  be reallocated using malloc-copy-free sequences unless
  the system supports MREMAP (currently only linux).

Bref, avec un système d'exploitation intelligent et une libc intelligente, tout passe mieux.

pour l'interface graphique:
C++ et wxWindows(ou Qt sous linux, j'ai utilisé Qt dans un prog énorme qu'on m'avait commandé, c'est vraiment très facile et la doc ben faite)
ou
C et Gtk

je trouve ces toolkits très faciles à programmer et Gtk est nettement mieux fini, pensé, et moderne que l'ui par defaut de windows (sauf la boite dialogue de selection de fichier mais bon, il parait que ça va changer dans les prochaines versions ...)

attention je te parle de l'apoque de gtk1 pour la facilité (pasque gtk2 a changé le codenj'ai pas encore essayé, mais il parait que c'est pas plus difficile)

j'ai essayé wx très récemment j'ai pas encore programmé de gros prog avec.

sous linuxe pour la T° tu proc et tt ça doit être assez facile, moi j'avais fait très vite un indicateur de batterie léger en Gtk (c'etait l'époque ou je bossais sous blackbox ) rien qu'avec un fopen de /proc/acpi/(...)/


exemples de progs:
en Gtk: gimp , gaim
en wxwindows: videolan client , audacity


quand à la différence entre C et C++ :
tu dois apprendre les deux, ils te serviront autant

"allouer le buffer la ou y a assez de place après pour les prochaines allocations" Pourquoi "devant"?

... pke de la place "derriere" ne sert a rien pour etendre le bloc... mais on a peut etre pas la meme definition de devant/derriere, pour moi si la memoire est representee de droite a gauche de sorte que les addresses sont plus elevees a droite qu'a gauche, alors devant c'est a droite et derriere a gauche...

Et pour "assez de place", ben n'importe quel minimum. Toute valeur strictement positive est bonne pour éviter de devoir déplacer un bloc à chaque fois."

non... si tu realloue de 1000 octets a la fois et que ta valeur strictement positive c'est 32, ta notion de "suffisemment de place" est completement inutile.
et heu, ca m'etonne vraiment beaucoup le comportement de realloc que tu decris... c'est assez pourri comme implementation oue c'est quelles sources que t'es alle voir? (et si c'est vraiment implemente comme ca, ca n'a rien a voir avec un "bug")

ouais gtk est très pratique, surtout sous caml : c'est du pur bonheur de programmer avec ça

sBibi :
et heu, ca m'etonne vraiment beaucoup le comportement de realloc que tu decris... c'est assez pourri comme implementation oue c'est quelles sources que t'es alle voir? (et si c'est vraiment implemente comme ca, ca n'a rien a voir avec un "bug")

Le CVS actuel.
GNU: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/malloc/malloc.c?rev=1.118&content-type=text/x-cvsweb-markup&cvsroot=glibc
NetBSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/stdlib/malloc.c?rev=1.43&content-type=text/x-cvsweb-markup

On m'a dit que GTK etait plus compliqué que Qt à utiliser, mais par rapport à l'API de win, ca donne koi ?