Discussion :

[David55]

Bonjour à tous!
J'ouvre cette discussion afin que chacun d'entre vous nous montre comment reprogrammer une fonction de son choix en C !

Ceci pourrait être intéressant pour chacun d'entre nous et on pourrait en apprendre beaucoup sur les fonctions C.

Alors à vos claviers et montrez nous comment programmer ces fameuses fonctions comme printf, scanf, random, memset ...

[David55]

mmmm... Vous n'êtes pas très inspiré!

Que pensez vous de la fonction malloc?

[DaZumba]

On trouve facilement differentes sources de la libc sur le web. Un exemple pour memset() ici.
Le probleme, c'est que certaines fonctions de la libc ne peuvent pas etre implementees en C standard - il faut faire appel a des fonctions systemes. C'est typiquement le cas pour malloc() ou vfprintf(). Donc l'interet de re-inventer la roue est faible.

[sloshy]

Bonsoir,
J'ai du recoder pas mal de fonction de la lib C pendant mon apprentissage de ce langage.
Je trouve que c'est bénéfique, je crois que le meilleur était de recoder malloc/realloc/free qui m'a appris beaucoup sur l'architecture système.
Recoder printf m'a permis de voir l'usine a gaz que c'etait et preferer faire un write pour un hello world

Si tu veux t'y mettre tu dois definir un OS precis.

tient, just for fun (en 3.5 secondes sans avoir teste ni meme compile )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
int    strlen2(char *str)
{
    int    count;
 
    count = 0;
    while (*str && ++str && ++count)
        ;
    return (count);
}

[Franck.H]

T'as qu'à regarder ici http://franckh.developpez.com/articl...si/libcstring/

[Invité]

Oui, cela pourrait être amusant en phase d'apprentissage du C, mais à moins d'avoir un correcteur parfaitement fiable, on a toutes les chances de réinventer la roue, mais je doute que celle qu'on inventera aura les mêmes performances que celle qu'on utilise habituellement.
D'autre part, à mon avis, il y a quelques fonctions de base comme malloc, read, open qui dépendent de tas de choses et qui je pense sont écrites en assembleur.

Tout le monde connait la fonction itoa(). Par contre ftoa() n'existe pas. J'ai bien été obligé de l'écrire moi-même.

[sloshy]

Oui, cela pourrait être amusant en phase d'apprentissage du C, mais à moins d'avoir un correcteur parfaitement fiable, on a toutes les chances de réinventer la roue, mais je doute que celle qu'on inventera aura les mêmes performances que celle qu'on utilise habituellement.
D'autre part, à mon avis, il y a quelques fonctions de base comme malloc, read, open qui dépendent de tas de choses et qui je pense sont écrites en assembleur.

Tout le monde connait la fonction itoa(). Par contre ftoa() n'existe pas. J'ai bien été obligé de l'écrire moi-même.

malloc est ecrit en C comme l'ensemble de la lib C, il est basé sur brk, l'appel systeme

[gl]

malloc est ecrit en C comme l'ensemble de la lib C, il est basé sur brk, l'appel systeme

Sur ton implémentation peut être. Mais ce n'est pas vrai partout.

[sloshy]

Il n'y a aucune spécificité d'architecture hardware.
L'ensemble de la lib C se base au mieux sur les appels systèmes.

Sur ton implémentation peut être. Mais ce n'est pas vrai partout.

sur tous les systemes posix?

[Invité]

Bonjour,
Oui, mais je vais prendre un exemple : quand on écrit (syntaxe non vérifiée)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
char tab[32];
char *ptr=tab;
strcpy(ptr,"Bonjour monde");
int i=4;
printf("%d ème caractère = %c\n",i,*(ptr+i));

Je suppose qu'il y a bien quelques fonctions assembleur, non?
Il faut bien avoir défini les termes "char", '[]' '=' '+' '\n' etc.

Recoder printf m'a permis de voir l'usine a gaz que c'etait et preferer faire un write pour un hello world

C'est justement à mon avis l'avantage d'un langage, une fonction très utilisée comme printf et ses dérivés a été développée très soigneusement, comme scanf qui est la fonction inverse, pour que les utilisateurs puissent s'en servir.
Cela a d'ailleurs conduit à ce que je considère comme des abus, la philosophie actuelle du C++. On préfère écrire 10 lignes aussi larges que l'écran, plutôt qu'utiliser l'arithmétique des pointeurs, parce qu'on n'imagine pas écrire une instruction si elle ne commence pas par str:: ou boost:: , (ou les mettre en namespace).

Pour mémoire, et mon cas personnel : lorsque j'ai découvert le C++, c'est la notion de classe, avec tout ce que cela comporte, qui m'a paru nouvelle et intéressante.
Puis j'ai été voir les classes ios et ses copines. J'ai essayé de les utiliser dans mes programmes et j'ai trouvé (ou constaté, comme on voudra) que ça ne m'apportait rien. En particulier, le formatage, la relecture, c'est à dire l'utilisation était moins intéressantes.
Donc, j'utilise le C++, mais pas les bibliothèques qui en ont résulté. Eh oui, j'en suis toujours au new et delete, mais ça ne m'empêche pas d'utiliser aussi malloc et free. Pour les liste, si les performances constituent un point important, je fais une liste chainée, sinon, j'utilise une classe toute faite.

[sloshy]

Bonjour,

Je suppose qu'il y a bien quelques fonctions assembleur, non?
Il faut bien avoir défini les termes "char", '[]' '=' '+' '\n' etc.

Tu dois confondre entre les fonctions de la lib C et le langage C.
Tout ce que tu décris est pris en charge par le compilateur (qui fourni un code assembleur).
Pour le passage sur le C++ ça sors du débat initial je trouve.

[Invité]

Pour le passage sur le C++ ça sors du débat initial je trouve.

Oui, sauf que j'ai éprouvé le besoin de donner un exemple pour expliquer ce que j'attendais d'un langage, quelque soit son nom. Autrement dit, que C++ soit issu du C constitue ici une coïncidence.

Tu dois confondre entre les fonctions de la lib C et le langage C.

Oui et non. En fait, j'aurais du limiter mon exemple à READ et WRITE.

[gl]

Il n'y a aucune spécificité d'architecture hardware.
L'ensemble de la lib C se base au mieux sur les appels systèmes.

Rien de tel n'est garanti par la norme.

Il existe bel et bien des implémentations où une partie de la bibliothèque standard est implémenté en pilotant directement les périphériques sans passer par des appels systèmes. Ne serait-ce que les implémentations tournant sur du matériel sans OS.

sur tous les systemes posix?

Il me semble bien que certains systèmes POSIX implémente malloc et consort à l'aide de mmap et non de brk.
D'ailleurs brk est-il POSIX, je n'en suis pas du tout certain?

[Franck.H]

Il me semble bien que certains systèmes POSIX implémente malloc et consort à l'aide de mmap et non de brk.
D'ailleurs brk est-il POSIX, je n'en suis pas du tout certain?

Effectivement et pour répondre à la question, non ce n'est pas POSIX:

BSD 4.3
brk et sbrk ne sont pas définis dans le C Standard, et sont volontairement exclus des standards POSIX.1 (paragraphes B.1.1.1.3 et B.8.3.3).

Etant des fonctions standard comme malloc, printf, etc... les fonctions de la libc sont écrites par rapport aux spécificités et appels-système de chaque système sur laquelle elle est développée. Si demain quelqu'un écrit même un petit système il faut tout refaire, y compris la libc ou tout du moins en partie. Il existe nombre d'exemples crédibles et tout à fait correct comme SOS http://sos.enix.org/fr/PagePrincipal...iki=index.html... un très bon exemple d'après mon expérience pour s'initier sans trop de difficulté à ce genre de programmation !

[David55]

Merci pour vos réponses

[Shadew]

Bonjour,

Je profite de ce topic que je trouve fort utile dans ma situation : je porte une application écrite en C++ sur GPU, et, à l'exception des GPU fermi, ces derniers n'acceptent que le C pur.

J'ai un petit soucis avec ma version de la fonction push_back de la classe std::vector. J'explique : tout d'abord, je transpose le vector dans une structure C qui contient la taille du vecteur et un pointeur vers le premier élément (je ne touche pas à la capacité du vector car je réserve la place nécessaire en C++, avant de passer au passage qui sera porté sur le GPU) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
struct vector_c{
        ElementClass * ptr;
        size_t size;
};
 
vector_c.size = vector_cpp.size();
vector_c.ptr = &(*(vector_cpp.begin()));

Cela semble être correct car je l'ai fait pour deux-trois vecteurs et tout fonctionne bien en lecture. Lorsque je dois ajouter un élément, je l'ajoute simplement dans mon tableau et j'incrémente sa taille :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
vector_c.ptr[srce->vector_c.size] = tmp;
vector_c.size ++;

tmp est une structure qui contient les membres de la classe cpp qui se trouve normalement dans le vector (j'ai fait hérité la classe de la structure). A la fin de mes ajouts, je resize le vector pour qu'il soit de la bonne taille :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
vector_cpp.resize(vector_c.size);

Normalement le vecteur devrait donc contenir les éléments et être de la bonne taille, mais j'obtiens des différences de résultats. Je pense que ça doit être dû à la fonction resize qui ne fait peut-être pas que mettre à jour les variables indiquant la taille du vector.

Il y a moyen de faire ce que je désire ou dois-je utiliser ma structure vector dans tout le programme ? Quelqu'un pourrait me conseiller svp ?

[kiluak]

Il me semble bien que certains systèmes POSIX implémente malloc et consort à l'aide de mmap et non de brk.

Salut,

Et certaines implémentations se basent sur brk et mmap (la taille de la zone demandée est discriminante pour le choix). Pour preuve, le p'tit linux qui tourne sur ma machine avec glibc 2.11.1

[kiluak]

Bonjour,

Je profite de ce topic que je trouve fort utile dans ma situation : je porte une application écrite en C++ sur GPU, et, à l'exception des GPU fermi, ces derniers n'acceptent que le C pur.

Nuance : le C++ est mieux supporté sur les Fermi ! Perso je fais tourner du code CUDA avec des features du C++ (notamment des templates) sur des vieilles cartes 1.1. Le truc discriminant est aussi la version de NVCC et du driver.

J'ai un petit soucis avec ma version de la fonction push_back de la classe std::vector. J'explique : tout d'abord, je transpose le vector dans une structure C qui contient la taille du vecteur et un pointeur vers le premier élément (je ne touche pas à la capacité du vector car je réserve la place nécessaire en C++, avant de passer au passage qui sera porté sur le GPU) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
struct vector_c{
        ElementClass * ptr;
        size_t size;
};
 
vector_c.size = vector_cpp.size();
vector_c.ptr = &(*(vector_cpp.begin()));

Cela semble être correct car je l'ai fait pour deux-trois vecteurs et tout fonctionne bien en lecture. Lorsque je dois ajouter un élément, je l'ajoute simplement dans mon tableau et j'incrémente sa taille :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
vector_c.ptr[srce->vector_c.size] = tmp;
vector_c.size ++;

vector_c est une structure, tu ne peux pas accéder à un hypothétique membre, donc, à priori ce code ne peut pas compiler, mais j'ai compris l'idée!

tmp est une structure qui contient les membres de la classe cpp qui se trouve normalement dans le vector (j'ai fait hérité la classe de la structure). A la fin de mes ajouts, je resize le vector pour qu'il soit de la bonne taille :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
vector_cpp.resize(vector_c.size);

Tu as un débordement mémoire potentiel : tu ajoutes des éléments dans ton vecteur qui a été alloué par la classe vector_cpp, alors qu'à priori le vecteur peut pointer vers une zone mémoire trop petite pour les contenir.
Il faut que tu fasses ton resize côté c++ AVANT de recopier tes éléments
Le fait que tu aies des valeurs différentes vient simplement du fait que lorsque tu fais ton resize, vector_cpp ne sait pas que tu lui a "ajouté" (potentiellement avec un dépassement mémoire!) des éléments. Donc quand tu resize, dans le cas ou il ne peut pas agrandir la zone mémoire actuelle, il va se déplacer dans une autre zone, et ce sans recopier les nouvelles valeurs, puisqu'il ne peut pas savoir qu'elles sont là.

[Vincent Rogier]

malloc est ecrit en C comme l'ensemble de la lib C, il est basé sur brk, l'appel systeme

faux ! example de base pour les windowiens (pour ne prendre qu'un seul exemple) : les versions "debug" de manipulation de chaines du runtime msvc++ sont écrites en C mais les versions release sont en assembleur

[kiluak]

Pour reprendre l'exemple de la lib C GNU, ça représente des milliers de ligne d'assembleur (pour rigoler, on peut regarder la fonction memcpy qui est de mémoire un monstre adaptatif écrit en assembleur)