Discussion :

[kendras]

Je voudrais savoir s'il existe une fonction pour supprimer un fichier ?
Ou dois executer la commande "rm" depuis la fonction execute(buf_command) ?

Idem pour le déplacement de fichier

[gnto]

Je voudrais savoir s'il existe une fonction pour supprimer un fichier ?
Ou dois executer la commande "rm" depuis la fonction execute(buf_command) ?

Idem pour le déplacement de fichier

Unlink

[Médinoc]

remove()

[Foobar1329]

Hello,

Je voudrais savoir s'il existe une fonction pour supprimer un fichier ?
Ou dois executer la commande "rm" depuis la fonction execute(buf_command) ?

Idem pour le déplacement de fichier

Oui pour enlever,

int remove(const char *filename); <dans stdio.h>

Renvoie 0 si succès. Attention à ce que le fichier ne soit pas ouvert.

Pour changer de place au fichier, tu n'as pas de fonction toute faite.
Au choix,
=> system("commande de deplacement de ton system <args>");
=> Une fonction spécifique de ton système
=> mieux, tu l'implémentes toi même via les fonctions disponibles de <stdio.h>
fopen(), fclose(), et remove() peuvent suffire. Un cp est possible aussi.


A+

[Emmanuel Delahaye]

Unlink

Pas portable.
remove().

[gnto]

Pas portable.
remove().

Oui mais la question était de remplacer "rm" et la commande "rm" est une commande unix/linux donc pour la portabilité ce n'est pas une question de priorité.

Est-ce mal de développer des applications non-portables ?

[Emmanuel Delahaye]

Est-ce mal de développer des applications non-portables ?

Oui, surtout quand une alternative portable existe.

(Gorétisation de niveau 4)

Utilisation injustifiée d'élements non standard (constantes, types, fonctions).

[kendras]

dans mon cas, la non portabilité n'est pas un problème

Déjà si l'application tourne, ce sera un miracle

[gnto]

Haha je vais écrire à tous les malheureux qui écrivent des applications non-portables

[gnto]

(Gorétisation de niveau 4)

Utilisation injustifiée d'élements non standard (constantes, types, fonctions).

Unlink conformité SVID, POSIX, X/OPEN, BSD 4.3
Quelle niveau de standardisation ? POSIX n'est pas un standard?

[Emmanuel Delahaye]

Unlink conformité SVID, POSIX, X/OPEN, BSD 4.3
Quelle niveau de standardisation ? POSIX n'est pas un standard?

Dans le cadre du langage C, non.

Elle s'applique en priorité au code 'applicatif' ecrit en C.

[kendras]

En même temps, s'il était question de portabilité dans mon cas, j'aurais opté pour du .net et non du C ...

[gnto]

Dans le cadre du langage C, non.

Portabilité => La portabilité désigne pour un programme informatique sa capacité à fonctionner plus ou moins facilement dans différents environnements d'exécution (qui correspondent généralement à un système d'exploitation (Windows, GNU/Linux, ...)).

Or POSIX => C'est un acronyme de Portable Operating System Interface, dont le X exprime l'héritage UNIX de l'API.Windows NT est conforme à POSIX.1.

Je ne vois pas de probleme de portabilité ? Biensur ce n'est pas de l'ansi C

[Foobar1329]

Hello,

En même temps, s'il était question de portabilité dans mon cas, j'aurais opté pour du .net et non du C ...

et pourtant, "Quand programmeur C ilè bon, li programme ila écrit lè portable".

Et plutôt que .NET, pour la portabilité, il y a aussi Java, qui a plus d'expérience. Je connais encore pas mal de systèmes Unix sur lesquels le CLR n'a pas été porté. Du C bien écrit est largement plus portable que du code supervisé par .NET.

A+

[Foobar1329]

Hello,

[
Je ne vois pas de probleme de portabilité ? Biensur ce n'est pas de l'ansi C

De l'ISO C , c'est de la norme internationale qu'il s'agit, même si ANSI (comité des ricains) est à l'origine de la norme.

A+

[gnto]

En 1983, l'Institut national américain de normalisation (ANSI) a formé un comité de normalisation du langage qui a abouti en 1989 à l'approbation de la norme dite ANSI C ou C89 (formellement ANSI X3.159-1989). En 1990, cette norme a également été adoptée par l'Organisation internationale de normalisation (formellement ISO/CEI 9899:1990). ANSI C est une évolution du K&R C qui reste extrêmement compatible. Elle reprend quelques idées de C++.

En 1999, une nouvelle évolution du langage est normalisée par l'ISO : C99 (ISO 9899). Parmi les ajouts, on notera des fonctionnalités déjà présentes dans certains compilateurs comme GCC, ainsi que des fonctionnalités (types complexes, mot-clef « restrict », directives agissant sur la simplification des instructions arithmétiques) souhaitables pour les calculs numériques intensifs, domaine habituel de FORTRAN.

man gcc

[Emmanuel Delahaye]

Windows NT est conforme à POSIX.1.

Dans tes rêves seulement... Regarde select(), par exemple...

D'autre part, la norme qui définit le langage C n'est pas liée à POSIX. C'est même plutôt le contraire...

http://emmanuel-delahaye.developpez.com/notes.htm#posix

[gnto]

Dans tes rêves seulement... Regarde select(), par exemple...

D'autre part, la norme qui définit le langage C n'est pas liée à POSIX. C'est même plutôt le contraire...

http://emmanuel-delahaye.developpez.com/notes.htm#posix

Tiens jette un oeuil la dessus
http://www.microsoft.com/technet/arc....mspx?mfr=true

Select() est du POSIX1.g ou sinon du BSD 4.4
man select

Peut-etre que je me trompe mais
POSIX1 est sortie en 1990 1003.1-1990 (POSIX.1)
POSIX1.g est sortie en 2001 1003.1-2001 (POSIX.1.g)

[Médinoc]

Le select() de Windows n'est pas compatible avec les autres, car les sockets de Windows sont des HANDLEs et non des descripteurs.

Par conséquent, sous Windows, tu ne peux pas faire un select() sur entrée standard+socket().

De plus, les sockets ne sont pas dans la liste des objets que peut attendre [Msg]WaitForXxxxxObject[s](), donc on se retrouve forcé d'alterner entre select() (ou WSAWaitForMultipleEvents()) et [Msg]WaitForXxxxxObject[s]()...



Et puis, je ne sais pas comment faire une application qui repose directement sur le sous-système POSIX au lieu du sous-système Win32...



Sans compter que ce document date de Windows NT 3.51...

Windows NT 4.0 will begin testing soon.

On parle encore de sous-système POSIX dans un livre sur Win2000, mais le fameux psxss.exe, je ne le vois jamais tourner... Je ne sais même pas si cygwin s'en sert...

Edit: Je viens de faire une recherche sous mon WinXP pro, en incluant les fichiers système et cachés : Plus aucune trace de psxss.exe...
EditEx: Je viens de trouver un truc intéressant:
http://msdn2.microsoft.com/en-us/library/y23kc048.aspx

[Foobar1329]

Hello,

Wikipédia a écrit :
En 1983, l'Institut national américain de normalisation (ANSI) a formé un comité de normalisation du langage qui a abouti en 1989 à l'approbation de la norme dite ANSI C ou C89 (formellement ANSI X3.159-1989). En 1990, cette norme a également été adoptée par l'Organisation internationale de normalisation (formellement ISO/CEI 9899:1990). ANSI C est une évolution du K&R C qui reste extrêmement compatible. Elle reprend quelques idées de C++.

En 1999, une nouvelle évolution du langage est normalisée par l'ISO : C99 (ISO 9899). Parmi les ajouts, on notera des fonctionnalités déjà présentes dans certains compilateurs comme GCC, ainsi que des fonctionnalités (types complexes, mot-clef « restrict », directives agissant sur la simplification des instructions arithmétiques) souhaitables pour les calculs numériques intensifs, domaine habituel de FORTRAN.

La phrase "Elle reprend quelques idées de C++" n'est pas idéalement placée. On pourrait comprendre qu'il s'agit de ANSI C en lieu et place de C99. Il serait souhaitable de la mettre plutôt en fin du second paragraphe, ou avant la phrase "ANSI C est une évol..." .

ANSI C 89 = ISO C 90, donc, justement, maintenant, qu'il s'agit de norme internationale, parler d'ISO C est plus convenable, d'autant plus que c'est désormais l'ISO qui effectue les modifs du langage C, à l'image de la dernière norme C99. Autre raison, ISO, 3 lettres, c'est plus court à écrire que ANSI qui en fait 4 .

A+