informations sur les fichiers

James Kanze

05/10/2003 à 17:00

"Frédéri MIAILLE" writes:

|> Je sais pas, c'est HS.
|> findfirst(), findnext() etc.

|> Mais là, James va revenir et m'engueuler parce que je répond
|> à un truc HS.

Et quand est-ce que j'ai engueulé quelqu'un pour une réponse HS ?
Ou même pour une question HS ? Je crois que je suis probablement le
plus tolérant des réguliers à cet égard, et je ne dis
quelque chose que quand quelqu'un insiste que c'est son droit, et qu'il
a raison de poster HS.

D'ailleurs, je ne considère pas HS une réponse qui dit que ce
n'est pas standard, mais que, par exemple, sous système X on
trouve... J'ai même cité ces fonctions dans ma propre réponse
(ainsi que opendir/readdir, vue que je n'ai pas le moindre idée s'il
est sous Windows ou sous Unix ou Linux).

|> > j'ai l'impression que, come pour le graphisme, il existe assez peu
|> > de truc normalise pour gerer une arborescence .. peut etre je me
|> > trompe ...

|> Hein ? En graphisme ? une arborescence ? Normalisé ? Ah oui la
|> normale est le vecteur perpendiculaire.

|> Tu veux dire, il existe peu de choses standard. C'est normal, il
|> n'existe rien de standard pour faire ça. Les langages ne sont pas
|> prévus pour gérer ça !

Ça dépend ce qu'il y entend, et quels langages.

|> C'est vrai, un langage est fait pour fonctionner sur un processeur
|> et voilà bien tout. Alors ils n'ont pas prévus de support pour
|> les disques durs ni les cartes vidéos, ni les cartes réseaux.
|> Tout ça, ce sont d'autres gens comme ceux de chez Microsoft par
|> exemple qui ont fait leurs petits trucs, donc des choses, comme tu
|> le dis : pas "très normalisée" qui sont spécifique aux
|> contextes.

Sois pas de mauvaise langue. Le C++ admit l'existance des fichiers,
quand même. Et des entrées/sorties « interactives » (en
laissant la définition exacte au système).

Le C++, aussi, part du principe qu'il n'est pas seul, qu'il ne
définit pas la machine (à l'encontre de Java, par exemple). Et que
des bibliothèques tièrces ne sont pas forcement une mauvaise
chose. On peut ne pas être d'accord (je trouve qu'il va trop loin
dans cette direction moi-même), mais c'est comme ça.

|> Donc une version pour Windows, une version pour Xwindow, une version
|> pour mac os, une pour BeOS, une version pour PALM et j'en passe des
|> millions.

Il y a aussi des bibliothèques portables, du genre wxwindows ou ILog
Views.

|> Et puis les updates (changement de Win95 à Win2000 par exemple
|> d'ou ma mise en garde avec stat) engendrent d'autres versions qui ne
|> sont plus compatibles avec d'autres trucs d'autres version
|> différentes. C'est un VERITABLE CAUCHEMARD !

Tout à fait. C'est pourquoi je crois qu'aucun professionnel
écrirait une application à ce niveau. C'est un problème pour
les auteurs de la bibliothèque, évidemment, mais le problème
s'arrête là.

|> > pourtant des progres enormes avaient ete faits sur les chaines et
|> > autres trucs utiles !

|> Oui, mais des progrès dans un sens. Chez Microsoft, ils ont fait
|> ce dont ils avaient besoin.

Je l'espère. Comme chez Sun, chez Linux, chez ...

Ce qui est beau, c'est qu'avec des bibliothèques, tu ne vois pas tout
ça.

|> Alors toi, tu va devoir faire ce dont tu as besoin.

Pourquoi est-ce qu'il doit le faire lui-même, vue que ça existe
tout fait déjà.

|> Par exemple, pour gérer les fichiers en c++, théoriquement, tu
|> es obligé de fabriquer un driver pour ton disque dur et faire toi
|> même tout de A à Z.

Pour gérer les fichiers en C++, il existe fstream, il me semble. Pour
la reste (lire des répertoires, etc.), c'est tellement facile à
faire une classe d'interface portable pour tout ça, que le marché
ne l'a même pas trouvé la peine d'en faire une tout faite.
(Dietmar Kühl y avait commencé, dans le cadre de Boost, mais je ne
crois pas qu'il a eu le temps d'y aller au bout.)

|> MAIS : Des gens sont passés avant toi et ont déjà
|> préparé ces choses. stat en fait partie, findfirst() et
|> findnext() aussi.
|> Ils t'ont laissés des notices d'utilisations. Cool : pas la peine
|> de tout refaire en assembleur !

|> Alors, sous windows, tu vas voir le merveilleux travail qu'ils ont
|> fait : http://msdn.microsoft.com/library/ Ils t'ont tout
|> mâché. Ils ont fabriqué pour toi, tu n'as plus qu'à
|> réutiliser.

|> Et c'est pour ça que nous sommes HS ici, simplement parce que ces
|> choses sont une déviance hérétique du langage C++ qui n'est
|> pas fait pour ça.

Tu n'as pas l'air d'avoir bien compris. C'est vrai qu'on ne peut pas
règler tous les problèmes du monde ici. Et que si tu travailles
sous un OS X, il faut que tu le connaisses, aussi bien que tu connais
C++. Et que si tu veux écrire des applications, il faut que tu
connaisses ton domaine applicatif. Et un tas d'autres choses aussi.

C'est comme ça, la vie. Tout n'est pas simple.

|> Et les gens ici parlent de ce pour quoi le langage est fait de
|> nature.

Ici, les gens parlent du langage. Ce qui n'est effectivement qu'une
petite partie de ce qu'il faut que tu saches. Moi, j'ai actuellement des
problèmes à développer mon programme parce que je ne connais
pas les règles de règlement des marchés boursiers. Mais je
reconnais que ce n'est pas ici l'endroit à en parler.

|> Et les gens qui ont ajoutés ces choses au C++, qui ont
|> développé tellement de choses ne sont PAS les créateurs du
|> langage. Ils l'ont fait que l'utiliser. Et ici, tout le monde se
|> fout de cette utilisation qu'on en fait, ce qui nous intéresse,
|> c'est comment on l'utilise, tu saisis la nuance ?

J'ai l'impression que c'est toi qui n'as pas saisi la nuance. Ici, on
parle des problèmes qu'on a à utiliser le langage. Et un des
problèmes, tout à fait, c'est l'absence d'un support portable pour
certaines fonctionalités importantes. En revanche, quand j'ai un
problème qui a rapport au système d'exploitation, je me rapporte
à fr.comp.os.unix ; je n'en parle pas ici.

Pour être plus clair : des questions sur comment gérer des
fenêtres dans un programme C++ portable sont tout à fait
acceptable ici. Des questions sur des subtilités Windows ou X-Window,
en revanche, non -- il y a des groupes spécialisés pour ça.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

"Frédéri MIAILLE" <bobranger@wanadoo.fr> writes:

|> Je sais pas, c'est HS.
|> findfirst(), findnext() etc.

|> Mais là, James va revenir et m'engueuler parce que je répond
|> à un truc HS.

Et quand est-ce que j'ai engueulé quelqu'un pour une réponse HS ?
Ou même pour une question HS ? Je crois que je suis probablement le
plus tolérant des réguliers à cet égard, et je ne dis
quelque chose que quand quelqu'un insiste que c'est son droit, et qu'il
a raison de poster HS.

D'ailleurs, je ne considère pas HS une réponse qui dit que ce
n'est pas standard, mais que, par exemple, sous système X on
trouve... J'ai même cité ces fonctions dans ma propre réponse
(ainsi que opendir/readdir, vue que je n'ai pas le moindre idée s'il
est sous Windows ou sous Unix ou Linux).

|> > j'ai l'impression que, come pour le graphisme, il existe assez peu
|> > de truc normalise pour gerer une arborescence .. peut etre je me
|> > trompe ...

|> Hein ? En graphisme ? une arborescence ? Normalisé ? Ah oui la
|> normale est le vecteur perpendiculaire.

|> Tu veux dire, il existe peu de choses standard. C'est normal, il
|> n'existe rien de standard pour faire ça. Les langages ne sont pas
|> prévus pour gérer ça !

Ça dépend ce qu'il y entend, et quels langages.

|> C'est vrai, un langage est fait pour fonctionner sur un processeur
|> et voilà bien tout. Alors ils n'ont pas prévus de support pour
|> les disques durs ni les cartes vidéos, ni les cartes réseaux.
|> Tout ça, ce sont d'autres gens comme ceux de chez Microsoft par
|> exemple qui ont fait leurs petits trucs, donc des choses, comme tu
|> le dis : pas "très normalisée" qui sont spécifique aux
|> contextes.

Sois pas de mauvaise langue. Le C++ admit l'existance des fichiers,
quand même. Et des entrées/sorties « interactives » (en
laissant la définition exacte au système).

Le C++, aussi, part du principe qu'il n'est pas seul, qu'il ne
définit pas la machine (à l'encontre de Java, par exemple). Et que
des bibliothèques tièrces ne sont pas forcement une mauvaise
chose. On peut ne pas être d'accord (je trouve qu'il va trop loin
dans cette direction moi-même), mais c'est comme ça.

|> Donc une version pour Windows, une version pour Xwindow, une version
|> pour mac os, une pour BeOS, une version pour PALM et j'en passe des
|> millions.

Il y a aussi des bibliothèques portables, du genre wxwindows ou ILog
Views.

|> Et puis les updates (changement de Win95 à Win2000 par exemple
|> d'ou ma mise en garde avec stat) engendrent d'autres versions qui ne
|> sont plus compatibles avec d'autres trucs d'autres version
|> différentes. C'est un VERITABLE CAUCHEMARD !

Tout à fait. C'est pourquoi je crois qu'aucun professionnel
écrirait une application à ce niveau. C'est un problème pour
les auteurs de la bibliothèque, évidemment, mais le problème
s'arrête là.

|> > pourtant des progres enormes avaient ete faits sur les chaines et
|> > autres trucs utiles !

|> Oui, mais des progrès dans un sens. Chez Microsoft, ils ont fait
|> ce dont ils avaient besoin.

Je l'espère. Comme chez Sun, chez Linux, chez ...

Ce qui est beau, c'est qu'avec des bibliothèques, tu ne vois pas tout
ça.

|> Alors toi, tu va devoir faire ce dont tu as besoin.

Pourquoi est-ce qu'il doit le faire lui-même, vue que ça existe
tout fait déjà.

|> Par exemple, pour gérer les fichiers en c++, théoriquement, tu
|> es obligé de fabriquer un driver pour ton disque dur et faire toi
|> même tout de A à Z.

Pour gérer les fichiers en C++, il existe fstream, il me semble. Pour
la reste (lire des répertoires, etc.), c'est tellement facile à
faire une classe d'interface portable pour tout ça, que le marché
ne l'a même pas trouvé la peine d'en faire une tout faite.
(Dietmar Kühl y avait commencé, dans le cadre de Boost, mais je ne
crois pas qu'il a eu le temps d'y aller au bout.)

|> MAIS : Des gens sont passés avant toi et ont déjà
|> préparé ces choses. stat en fait partie, findfirst() et
|> findnext() aussi.
|> Ils t'ont laissés des notices d'utilisations. Cool : pas la peine
|> de tout refaire en assembleur !

|> Alors, sous windows, tu vas voir le merveilleux travail qu'ils ont
|> fait : http://msdn.microsoft.com/library/ Ils t'ont tout
|> mâché. Ils ont fabriqué pour toi, tu n'as plus qu'à
|> réutiliser.

|> Et c'est pour ça que nous sommes HS ici, simplement parce que ces
|> choses sont une déviance hérétique du langage C++ qui n'est
|> pas fait pour ça.

Tu n'as pas l'air d'avoir bien compris. C'est vrai qu'on ne peut pas
règler tous les problèmes du monde ici. Et que si tu travailles
sous un OS X, il faut que tu le connaisses, aussi bien que tu connais
C++. Et que si tu veux écrire des applications, il faut que tu
connaisses ton domaine applicatif. Et un tas d'autres choses aussi.

C'est comme ça, la vie. Tout n'est pas simple.

|> Et les gens ici parlent de ce pour quoi le langage est fait de
|> nature.

Ici, les gens parlent du langage. Ce qui n'est effectivement qu'une
petite partie de ce qu'il faut que tu saches. Moi, j'ai actuellement des
problèmes à développer mon programme parce que je ne connais
pas les règles de règlement des marchés boursiers. Mais je
reconnais que ce n'est pas ici l'endroit à en parler.

|> Et les gens qui ont ajoutés ces choses au C++, qui ont
|> développé tellement de choses ne sont PAS les créateurs du
|> langage. Ils l'ont fait que l'utiliser. Et ici, tout le monde se
|> fout de cette utilisation qu'on en fait, ce qui nous intéresse,
|> c'est comment on l'utilise, tu saisis la nuance ?

J'ai l'impression que c'est toi qui n'as pas saisi la nuance. Ici, on
parle des problèmes qu'on a à utiliser le langage. Et un des
problèmes, tout à fait, c'est l'absence d'un support portable pour
certaines fonctionalités importantes. En revanche, quand j'ai un
problème qui a rapport au système d'exploitation, je me rapporte
à fr.comp.os.unix ; je n'en parle pas ici.

Pour être plus clair : des questions sur comment gérer des
fenêtres dans un programme C++ portable sont tout à fait
acceptable ici. Des questions sur des subtilités Windows ou X-Window,
en revanche, non -- il y a des groupes spécialisés pour ça.

--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Vous avez filtré cet utilisateur ! Consultez son message

"Frédéri MIAILLE" writes:

|> Je sais pas, c'est HS.
|> findfirst(), findnext() etc.

|> Mais là, James va revenir et m'engueuler parce que je répond
|> à un truc HS.

Et quand est-ce que j'ai engueulé quelqu'un pour une réponse HS ?
Ou même pour une question HS ? Je crois que je suis probablement le
plus tolérant des réguliers à cet égard, et je ne dis
quelque chose que quand quelqu'un insiste que c'est son droit, et qu'il
a raison de poster HS.

D'ailleurs, je ne considère pas HS une réponse qui dit que ce
n'est pas standard, mais que, par exemple, sous système X on
trouve... J'ai même cité ces fonctions dans ma propre réponse
(ainsi que opendir/readdir, vue que je n'ai pas le moindre idée s'il
est sous Windows ou sous Unix ou Linux).

|> > j'ai l'impression que, come pour le graphisme, il existe assez peu
|> > de truc normalise pour gerer une arborescence .. peut etre je me
|> > trompe ...

|> Hein ? En graphisme ? une arborescence ? Normalisé ? Ah oui la
|> normale est le vecteur perpendiculaire.

|> Tu veux dire, il existe peu de choses standard. C'est normal, il
|> n'existe rien de standard pour faire ça. Les langages ne sont pas
|> prévus pour gérer ça !

Ça dépend ce qu'il y entend, et quels langages.

|> C'est vrai, un langage est fait pour fonctionner sur un processeur
|> et voilà bien tout. Alors ils n'ont pas prévus de support pour
|> les disques durs ni les cartes vidéos, ni les cartes réseaux.
|> Tout ça, ce sont d'autres gens comme ceux de chez Microsoft par
|> exemple qui ont fait leurs petits trucs, donc des choses, comme tu
|> le dis : pas "très normalisée" qui sont spécifique aux
|> contextes.

Sois pas de mauvaise langue. Le C++ admit l'existance des fichiers,
quand même. Et des entrées/sorties « interactives » (en
laissant la définition exacte au système).

Le C++, aussi, part du principe qu'il n'est pas seul, qu'il ne
définit pas la machine (à l'encontre de Java, par exemple). Et que
des bibliothèques tièrces ne sont pas forcement une mauvaise
chose. On peut ne pas être d'accord (je trouve qu'il va trop loin
dans cette direction moi-même), mais c'est comme ça.

|> Donc une version pour Windows, une version pour Xwindow, une version
|> pour mac os, une pour BeOS, une version pour PALM et j'en passe des
|> millions.

Il y a aussi des bibliothèques portables, du genre wxwindows ou ILog
Views.

|> Et puis les updates (changement de Win95 à Win2000 par exemple
|> d'ou ma mise en garde avec stat) engendrent d'autres versions qui ne
|> sont plus compatibles avec d'autres trucs d'autres version
|> différentes. C'est un VERITABLE CAUCHEMARD !

Tout à fait. C'est pourquoi je crois qu'aucun professionnel
écrirait une application à ce niveau. C'est un problème pour
les auteurs de la bibliothèque, évidemment, mais le problème
s'arrête là.

|> > pourtant des progres enormes avaient ete faits sur les chaines et
|> > autres trucs utiles !

|> Oui, mais des progrès dans un sens. Chez Microsoft, ils ont fait
|> ce dont ils avaient besoin.

Je l'espère. Comme chez Sun, chez Linux, chez ...

Ce qui est beau, c'est qu'avec des bibliothèques, tu ne vois pas tout
ça.

|> Alors toi, tu va devoir faire ce dont tu as besoin.

Pourquoi est-ce qu'il doit le faire lui-même, vue que ça existe
tout fait déjà.

|> Par exemple, pour gérer les fichiers en c++, théoriquement, tu
|> es obligé de fabriquer un driver pour ton disque dur et faire toi
|> même tout de A à Z.

Pour gérer les fichiers en C++, il existe fstream, il me semble. Pour
la reste (lire des répertoires, etc.), c'est tellement facile à
faire une classe d'interface portable pour tout ça, que le marché
ne l'a même pas trouvé la peine d'en faire une tout faite.
(Dietmar Kühl y avait commencé, dans le cadre de Boost, mais je ne
crois pas qu'il a eu le temps d'y aller au bout.)

|> MAIS : Des gens sont passés avant toi et ont déjà
|> préparé ces choses. stat en fait partie, findfirst() et
|> findnext() aussi.
|> Ils t'ont laissés des notices d'utilisations. Cool : pas la peine
|> de tout refaire en assembleur !

|> Alors, sous windows, tu vas voir le merveilleux travail qu'ils ont
|> fait : http://msdn.microsoft.com/library/ Ils t'ont tout
|> mâché. Ils ont fabriqué pour toi, tu n'as plus qu'à
|> réutiliser.

|> Et c'est pour ça que nous sommes HS ici, simplement parce que ces
|> choses sont une déviance hérétique du langage C++ qui n'est
|> pas fait pour ça.

Tu n'as pas l'air d'avoir bien compris. C'est vrai qu'on ne peut pas
règler tous les problèmes du monde ici. Et que si tu travailles
sous un OS X, il faut que tu le connaisses, aussi bien que tu connais
C++. Et que si tu veux écrire des applications, il faut que tu
connaisses ton domaine applicatif. Et un tas d'autres choses aussi.

C'est comme ça, la vie. Tout n'est pas simple.

|> Et les gens ici parlent de ce pour quoi le langage est fait de
|> nature.

Ici, les gens parlent du langage. Ce qui n'est effectivement qu'une
petite partie de ce qu'il faut que tu saches. Moi, j'ai actuellement des
problèmes à développer mon programme parce que je ne connais
pas les règles de règlement des marchés boursiers. Mais je
reconnais que ce n'est pas ici l'endroit à en parler.

|> Et les gens qui ont ajoutés ces choses au C++, qui ont
|> développé tellement de choses ne sont PAS les créateurs du
|> langage. Ils l'ont fait que l'utiliser. Et ici, tout le monde se
|> fout de cette utilisation qu'on en fait, ce qui nous intéresse,
|> c'est comment on l'utilise, tu saisis la nuance ?

J'ai l'impression que c'est toi qui n'as pas saisi la nuance. Ici, on
parle des problèmes qu'on a à utiliser le langage. Et un des
problèmes, tout à fait, c'est l'absence d'un support portable pour
certaines fonctionalités importantes. En revanche, quand j'ai un
problème qui a rapport au système d'exploitation, je me rapporte
à fr.comp.os.unix ; je n'en parle pas ici.

Pour être plus clair : des questions sur comment gérer des
fenêtres dans un programme C++ portable sont tout à fait
acceptable ici. Des questions sur des subtilités Windows ou X-Window,
en revanche, non -- il y a des groupes spécialisés pour ça.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

James Kanze

05/10/2003 à 17:04

"Frédéri MIAILLE" writes:

|> Et bien seekg()/seekp() peuvent placer le pointeur à la fin du
|> fichier et on peut utiliser tellg()/tellp() par la suite. Ce n'est
|> pas fiable ?

Non. Régarde le type de retour de tellg()/tellp(). Ce n'est pas un
type entier.

Sous Unix et sous Windows, c'est un type qui a une conversion
automatique en entier. Et le résultat pourrait convenir pour
certaines définitions de taille de fichier. Mais au fond, avant de
lui répondre, il serait bien à savoir ce qu'il entend par
« taille de fichier ». Parce que l'interprétation intuitive,
ça serait ou bien la place que le fichier occupe sur la disque, ou
bien le nombre de caractères que je pourrais en lire. Et en
l'occurance, ni Unix, ni (je crois) Windows, n'ont aucun moyen de savoir
la place occupée sur disque, et le nombre de caractères que je
pourrais lire dépend du locale.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Samuel Krempp

05/10/2003 à 18:57

le Saturday 04 October 2003 17:24, écrivit :

j'en profite pour une nouvelle question : peut on avoir la liste des
fichiers d'un repertoire avec une fonctionalite de la stl ?

de la stl : non. mais à la façon de la stl, c'est possible.
va voir si boost::filesystem de Beman Dawes
http://www.boost.org/libs/filesystem/doc/index.htm
fait ce que tu veux.

--
Sam

ricky

05/10/2003 à 20:34

bonjour

d'abord mes excuses a ceux qui m'ont repondus, dont toi et james .. je
viens de prendre un bonne lecon et de comprendre ce qu'etait une
question vague ...
j'avoue que je suis habitue a coder des "codes de calculs", ce qui ne me
pose pas de probleme...
je m'attaque recement, pour mon plaisir et cessser d'etre vexer, a
essayer de rendre plus "ihm" mes applications... de fait je suis dans le
flou le plus complet dans ce domaine : gerer des fichiers, le graphisme,
etc et j'ai ete un peu decu qu'il n'y ai rien dans la stl de normer a ce
sujet.?..

je ne comprend d'ailleurs pas trop pourquoi .. on va me dire : ben ca
depend du systeme...
je repondrais : pour moi, une chaine de caractere ou la notion de
pointeur depend aussi completement du systeme, un cout aussi...
alors pourquoi ne pas pousser un peu le bouchin et metre au moins des
bases pratiques dans la stl, comme celle ci a integrer des notions de
string ou de recherche dans un fichier...

Te fâche pas :)

j ai oublie le smiley !!

Je dis ça parce que moi j'ai compris très tard, mais très très tard que je
pouvais utiliser fstream et ifstream/ofstream pour trouver la taille de mes
fichiers.

oui je viens de le decouvrir

"je cherche desesperemet a ecrire un programme en c++ qui me donne pour
un fichier donné sa taille et sa date de modification...".
Tu n'avais pas donné de condition.
J'ai planifié avec ça.

je m'en excuse , et tout comme james l'a fait remarque : je n'ai pas ete
precis dans ma question , mea culpa

Fais gaffe avec stat. 1, c'est HS

pourquoi HS ?
j'ai trouve stat dans un include fourni avec cygwin.
je pensais que cela faisait donc parti du langage "etendu" (je considere
effectivement par extension le c++ comme le langage c++ ET ce que
fourni la stl de maniere standard)

J'exagère à peine. D'ailleurs rien que d'y penser, ça m'énerve.
Je vais aller boire un coca moi, ça va me soulager...

oui ca m'inquiete un peu poiur faire du portable

alors qu'en tcl/tk, j'ai pas de probleme d'ihm :-)
en fait je cherchais a faire en c++ un truc proche de ce que fait le
tcl/tk pour la gestion des fichiers ...

Je sais pas, c'est HS.

j'en suis desole donc je ne continurais pas mais cela aurait pu faire
parti du langage "etendu" (je pense a stl)

findfirst(), findnext() etc.
Mais là, James va revenir et m'engueuler parce que je répond à un truc HS.
Tu auras la réponse à coup sûr sur fr.comp.os.ms-windows.programmation

pourquoi forcement windows :-) ? je comptais sur du multiplateforme :-)
en fait j'essaye de ruser un peu : cygwin + gcc sous windows, et gcc
sous linux...
et essayer d'avoir le moins de package en dehors de la stl de base

Tu veux dire, il existe peu de choses standard. C'est normal, il n'existe
rien de standard pour faire ça. Les langages ne sont pas prévus pour gérer
ça !

pas plus que les string et autres ...
bref quasiment rien mais on les rajoute ., et on pourrait les normer, ie
leur donner la meme signification sous tout os

C'est vrai, un langage est fait pour fonctionner sur un processeur et voilà
bien tout. Alors ils n'ont pas prévus de support pour les disques durs ni
les cartes vidéos, ni les cartes réseaux. Tout ça, ce sont d'autres gens
comme ceux de chez Microsoft par exemple qui ont fait leurs petits trucs,
donc des choses, comme tu le dis : pas "très normalisée" qui sont spécifique
aux contextes.

pas ok la dessus mais c'est mon point de vue... rien de ce que fait la
stl n'est fait par billou ou torval et pourtant cela fonctionne sur les
principaux os ou gcc (par exemple) est distribue...
rien n'interdirait donc de mettre les bases de la gestion de fichier
comme cela existe sous tcl/tk (quelque soit l'os) ou python

Donc une version pour Windows, une version pour Xwindow, une
version pour mac os, une pour BeOS, une version pour PALM et j'en passe des
millions.

comme le font tcl/tk, python etc
et alors ?

Et puis les updates (changement de Win95 à Win2000 par exemple
d'ou ma mise en garde avec stat) engendrent d'autres versions qui ne sont
plus compatibles avec d'autres trucs d'autres version différentes. C'est un
VERITABLE CAUCHEMARD !

d'autres langages (en etendu) le font, y compris java ... donc pourquoi
pas c++

Et le moteur en consommant tout ton réservoir servirait juste à alimenter le
clignotant pour qu'il s'allume une fois.
Et bien, en C++, on te demande de faire la même chose : adapter.

oui mais il fait des bases
je demande juste a avoir de bons crochetrs sur ma voiture et des
morceaux pour faire ma tourelle... pas rien du tout
meme ton char d'assaut utilise des technologies venant de la voiture...
il n'a pas ete invente de zero
pour la gestion de fichier, le c++ me demande de tout faire de zero, nuance

Oui, mais des progrès dans un sens. Chez Microsoft, ils ont fait ce dont ils
avaient besoin.

je ne parle pas de billou
les string ne dependent pas de lui

Par exemple, pour gérer les fichiers en c++, théoriquement, tu es obligé de
fabriquer un driver pour ton disque dur et faire toi même tout de A à Z.
MAIS : Des gens sont passés avant toi et ont déjà préparé ces choses. stat
en fait partie, findfirst() et findnext() aussi.

oui

Ils t'ont laissés des notices d'utilisations. Cool : pas la peine de tout
refaire en assembleur !

oui et meme mieux : c'est dans le stl souvent

Et c'est pour ça que nous sommes HS ici, simplement parce que ces choses
sont une déviance hérétique du langage C++ qui n'est pas fait pour ça.

il n'est fait pour quasiment rien à la base ... donc toutes vos
discussions sont HS par defaut :-)))

les gens ici parlent de ce pour quoi le langage est fait de nature.

au sens strcit non .. au sens plus etendu oui :-)

gens qui ont ajoutés ces choses au C++, qui ont développé tellement de
choses ne sont PAS les créateurs du langage.

la stl doit bcp aux createurs
ensuite, le c++ a evolue aussi en dehors de ses createurs de base

Et ici, tout le monde se fout de cette utilisation qu'on en fait, ce qui
nous intéresse, c'est comment on l'utilise, tu saisis la nuance ?

oui et ce qui m'interesse est commen on l'utilise pour faire un travail
de gestion de fichier
la question n'est pas hs, la reponse se devait donc d'etre : on ne peut
pas par defaut ...
il n'y a pas hs, il y a impossibilite de le faire, tu vois la nuance ?

Je précise que si personne explique, même si je le fais à ma manière, tu
peux pas savoir.

merci :-PPP

Pour n'ennuyer personne, va plutôt du côté du news group que je t'ai donné
précédemment, ici, nous sommes hors sujet.

je ne suis pas en accord avec le HS toutefois :-)
par contre j'ai ma reponse : le c++ ne le fait pas en standard ... donc
d'autres questions sur le mem sujet seraient HS en effet , mais pas la
premiere :-)

@+
ricky

bonjour

d'abord mes excuses a ceux qui m'ont repondus, dont toi et james .. je
viens de prendre un bonne lecon et de comprendre ce qu'etait une
question vague ...
j'avoue que je suis habitue a coder des "codes de calculs", ce qui ne me
pose pas de probleme...
je m'attaque recement, pour mon plaisir et cessser d'etre vexer, a
essayer de rendre plus "ihm" mes applications... de fait je suis dans le
flou le plus complet dans ce domaine : gerer des fichiers, le graphisme,
etc et j'ai ete un peu decu qu'il n'y ai rien dans la stl de normer a ce
sujet.?..

je ne comprend d'ailleurs pas trop pourquoi .. on va me dire : ben ca
depend du systeme...
je repondrais : pour moi, une chaine de caractere ou la notion de
pointeur depend aussi completement du systeme, un cout aussi...
alors pourquoi ne pas pousser un peu le bouchin et metre au moins des
bases pratiques dans la stl, comme celle ci a integrer des notions de
string ou de recherche dans un fichier...

Te fâche pas :)

j ai oublie le smiley !!

Je dis ça parce que moi j'ai compris très tard, mais très très tard que je
pouvais utiliser fstream et ifstream/ofstream pour trouver la taille de mes
fichiers.

oui je viens de le decouvrir

"je cherche desesperemet a ecrire un programme en c++ qui me donne pour
un fichier donné sa taille et sa date de modification...".
Tu n'avais pas donné de condition.
J'ai planifié avec ça.

je m'en excuse , et tout comme james l'a fait remarque : je n'ai pas ete
precis dans ma question , mea culpa

Fais gaffe avec stat. 1, c'est HS

pourquoi HS ?
j'ai trouve stat dans un include fourni avec cygwin.
je pensais que cela faisait donc parti du langage "etendu" (je considere
effectivement par extension le c++ comme le langage c++ ET ce que
fourni la stl de maniere standard)

J'exagère à peine. D'ailleurs rien que d'y penser, ça m'énerve.
Je vais aller boire un coca moi, ça va me soulager...

oui ca m'inquiete un peu poiur faire du portable

alors qu'en tcl/tk, j'ai pas de probleme d'ihm :-)
en fait je cherchais a faire en c++ un truc proche de ce que fait le
tcl/tk pour la gestion des fichiers ...

Je sais pas, c'est HS.

j'en suis desole donc je ne continurais pas mais cela aurait pu faire
parti du langage "etendu" (je pense a stl)

findfirst(), findnext() etc.
Mais là, James va revenir et m'engueuler parce que je répond à un truc HS.
Tu auras la réponse à coup sûr sur fr.comp.os.ms-windows.programmation

pourquoi forcement windows :-) ? je comptais sur du multiplateforme :-)
en fait j'essaye de ruser un peu : cygwin + gcc sous windows, et gcc
sous linux...
et essayer d'avoir le moins de package en dehors de la stl de base

Tu veux dire, il existe peu de choses standard. C'est normal, il n'existe
rien de standard pour faire ça. Les langages ne sont pas prévus pour gérer
ça !

pas plus que les string et autres ...
bref quasiment rien mais on les rajoute ., et on pourrait les normer, ie
leur donner la meme signification sous tout os

C'est vrai, un langage est fait pour fonctionner sur un processeur et voilà
bien tout. Alors ils n'ont pas prévus de support pour les disques durs ni
les cartes vidéos, ni les cartes réseaux. Tout ça, ce sont d'autres gens
comme ceux de chez Microsoft par exemple qui ont fait leurs petits trucs,
donc des choses, comme tu le dis : pas "très normalisée" qui sont spécifique
aux contextes.

pas ok la dessus mais c'est mon point de vue... rien de ce que fait la
stl n'est fait par billou ou torval et pourtant cela fonctionne sur les
principaux os ou gcc (par exemple) est distribue...
rien n'interdirait donc de mettre les bases de la gestion de fichier
comme cela existe sous tcl/tk (quelque soit l'os) ou python

Donc une version pour Windows, une version pour Xwindow, une
version pour mac os, une pour BeOS, une version pour PALM et j'en passe des
millions.

comme le font tcl/tk, python etc
et alors ?

Et puis les updates (changement de Win95 à Win2000 par exemple
d'ou ma mise en garde avec stat) engendrent d'autres versions qui ne sont
plus compatibles avec d'autres trucs d'autres version différentes. C'est un
VERITABLE CAUCHEMARD !

d'autres langages (en etendu) le font, y compris java ... donc pourquoi
pas c++

Et le moteur en consommant tout ton réservoir servirait juste à alimenter le
clignotant pour qu'il s'allume une fois.
Et bien, en C++, on te demande de faire la même chose : adapter.

oui mais il fait des bases
je demande juste a avoir de bons crochetrs sur ma voiture et des
morceaux pour faire ma tourelle... pas rien du tout
meme ton char d'assaut utilise des technologies venant de la voiture...
il n'a pas ete invente de zero
pour la gestion de fichier, le c++ me demande de tout faire de zero, nuance

Oui, mais des progrès dans un sens. Chez Microsoft, ils ont fait ce dont ils
avaient besoin.

je ne parle pas de billou
les string ne dependent pas de lui

Par exemple, pour gérer les fichiers en c++, théoriquement, tu es obligé de
fabriquer un driver pour ton disque dur et faire toi même tout de A à Z.
MAIS : Des gens sont passés avant toi et ont déjà préparé ces choses. stat
en fait partie, findfirst() et findnext() aussi.

oui

Ils t'ont laissés des notices d'utilisations. Cool : pas la peine de tout
refaire en assembleur !

oui et meme mieux : c'est dans le stl souvent

Et c'est pour ça que nous sommes HS ici, simplement parce que ces choses
sont une déviance hérétique du langage C++ qui n'est pas fait pour ça.

il n'est fait pour quasiment rien à la base ... donc toutes vos
discussions sont HS par defaut :-)))

les gens ici parlent de ce pour quoi le langage est fait de nature.

au sens strcit non .. au sens plus etendu oui :-)

gens qui ont ajoutés ces choses au C++, qui ont développé tellement de
choses ne sont PAS les créateurs du langage.

la stl doit bcp aux createurs
ensuite, le c++ a evolue aussi en dehors de ses createurs de base

Et ici, tout le monde se fout de cette utilisation qu'on en fait, ce qui
nous intéresse, c'est comment on l'utilise, tu saisis la nuance ?

oui et ce qui m'interesse est commen on l'utilise pour faire un travail
de gestion de fichier
la question n'est pas hs, la reponse se devait donc d'etre : on ne peut
pas par defaut ...
il n'y a pas hs, il y a impossibilite de le faire, tu vois la nuance ?

Je précise que si personne explique, même si je le fais à ma manière, tu
peux pas savoir.

merci :-PPP

Pour n'ennuyer personne, va plutôt du côté du news group que je t'ai donné
précédemment, ici, nous sommes hors sujet.

je ne suis pas en accord avec le HS toutefois :-)
par contre j'ai ma reponse : le c++ ne le fait pas en standard ... donc
d'autres questions sur le mem sujet seraient HS en effet , mais pas la
premiere :-)

@+
ricky

Vous avez filtré cet utilisateur ! Consultez son message

bonjour

d'abord mes excuses a ceux qui m'ont repondus, dont toi et james .. je
viens de prendre un bonne lecon et de comprendre ce qu'etait une
question vague ...
j'avoue que je suis habitue a coder des "codes de calculs", ce qui ne me
pose pas de probleme...
je m'attaque recement, pour mon plaisir et cessser d'etre vexer, a
essayer de rendre plus "ihm" mes applications... de fait je suis dans le
flou le plus complet dans ce domaine : gerer des fichiers, le graphisme,
etc et j'ai ete un peu decu qu'il n'y ai rien dans la stl de normer a ce
sujet.?..

je ne comprend d'ailleurs pas trop pourquoi .. on va me dire : ben ca
depend du systeme...
je repondrais : pour moi, une chaine de caractere ou la notion de
pointeur depend aussi completement du systeme, un cout aussi...
alors pourquoi ne pas pousser un peu le bouchin et metre au moins des
bases pratiques dans la stl, comme celle ci a integrer des notions de
string ou de recherche dans un fichier...

Te fâche pas :)

j ai oublie le smiley !!

Je dis ça parce que moi j'ai compris très tard, mais très très tard que je
pouvais utiliser fstream et ifstream/ofstream pour trouver la taille de mes
fichiers.

oui je viens de le decouvrir

"je cherche desesperemet a ecrire un programme en c++ qui me donne pour
un fichier donné sa taille et sa date de modification...".
Tu n'avais pas donné de condition.
J'ai planifié avec ça.

je m'en excuse , et tout comme james l'a fait remarque : je n'ai pas ete
precis dans ma question , mea culpa

Fais gaffe avec stat. 1, c'est HS

pourquoi HS ?
j'ai trouve stat dans un include fourni avec cygwin.
je pensais que cela faisait donc parti du langage "etendu" (je considere
effectivement par extension le c++ comme le langage c++ ET ce que
fourni la stl de maniere standard)

J'exagère à peine. D'ailleurs rien que d'y penser, ça m'énerve.
Je vais aller boire un coca moi, ça va me soulager...

oui ca m'inquiete un peu poiur faire du portable

alors qu'en tcl/tk, j'ai pas de probleme d'ihm :-)
en fait je cherchais a faire en c++ un truc proche de ce que fait le
tcl/tk pour la gestion des fichiers ...

Je sais pas, c'est HS.

j'en suis desole donc je ne continurais pas mais cela aurait pu faire
parti du langage "etendu" (je pense a stl)

findfirst(), findnext() etc.
Mais là, James va revenir et m'engueuler parce que je répond à un truc HS.
Tu auras la réponse à coup sûr sur fr.comp.os.ms-windows.programmation

pourquoi forcement windows :-) ? je comptais sur du multiplateforme :-)
en fait j'essaye de ruser un peu : cygwin + gcc sous windows, et gcc
sous linux...
et essayer d'avoir le moins de package en dehors de la stl de base

Tu veux dire, il existe peu de choses standard. C'est normal, il n'existe
rien de standard pour faire ça. Les langages ne sont pas prévus pour gérer
ça !

pas plus que les string et autres ...
bref quasiment rien mais on les rajoute ., et on pourrait les normer, ie
leur donner la meme signification sous tout os

C'est vrai, un langage est fait pour fonctionner sur un processeur et voilà
bien tout. Alors ils n'ont pas prévus de support pour les disques durs ni
les cartes vidéos, ni les cartes réseaux. Tout ça, ce sont d'autres gens
comme ceux de chez Microsoft par exemple qui ont fait leurs petits trucs,
donc des choses, comme tu le dis : pas "très normalisée" qui sont spécifique
aux contextes.

pas ok la dessus mais c'est mon point de vue... rien de ce que fait la
stl n'est fait par billou ou torval et pourtant cela fonctionne sur les
principaux os ou gcc (par exemple) est distribue...
rien n'interdirait donc de mettre les bases de la gestion de fichier
comme cela existe sous tcl/tk (quelque soit l'os) ou python

Donc une version pour Windows, une version pour Xwindow, une
version pour mac os, une pour BeOS, une version pour PALM et j'en passe des
millions.

comme le font tcl/tk, python etc
et alors ?

Et puis les updates (changement de Win95 à Win2000 par exemple
d'ou ma mise en garde avec stat) engendrent d'autres versions qui ne sont
plus compatibles avec d'autres trucs d'autres version différentes. C'est un
VERITABLE CAUCHEMARD !

d'autres langages (en etendu) le font, y compris java ... donc pourquoi
pas c++

Et le moteur en consommant tout ton réservoir servirait juste à alimenter le
clignotant pour qu'il s'allume une fois.
Et bien, en C++, on te demande de faire la même chose : adapter.

oui mais il fait des bases
je demande juste a avoir de bons crochetrs sur ma voiture et des
morceaux pour faire ma tourelle... pas rien du tout
meme ton char d'assaut utilise des technologies venant de la voiture...
il n'a pas ete invente de zero
pour la gestion de fichier, le c++ me demande de tout faire de zero, nuance

Oui, mais des progrès dans un sens. Chez Microsoft, ils ont fait ce dont ils
avaient besoin.

je ne parle pas de billou
les string ne dependent pas de lui

Par exemple, pour gérer les fichiers en c++, théoriquement, tu es obligé de
fabriquer un driver pour ton disque dur et faire toi même tout de A à Z.
MAIS : Des gens sont passés avant toi et ont déjà préparé ces choses. stat
en fait partie, findfirst() et findnext() aussi.

oui

Ils t'ont laissés des notices d'utilisations. Cool : pas la peine de tout
refaire en assembleur !

oui et meme mieux : c'est dans le stl souvent

Et c'est pour ça que nous sommes HS ici, simplement parce que ces choses
sont une déviance hérétique du langage C++ qui n'est pas fait pour ça.

il n'est fait pour quasiment rien à la base ... donc toutes vos
discussions sont HS par defaut :-)))

les gens ici parlent de ce pour quoi le langage est fait de nature.

au sens strcit non .. au sens plus etendu oui :-)

gens qui ont ajoutés ces choses au C++, qui ont développé tellement de
choses ne sont PAS les créateurs du langage.

la stl doit bcp aux createurs
ensuite, le c++ a evolue aussi en dehors de ses createurs de base

Et ici, tout le monde se fout de cette utilisation qu'on en fait, ce qui
nous intéresse, c'est comment on l'utilise, tu saisis la nuance ?

oui et ce qui m'interesse est commen on l'utilise pour faire un travail
de gestion de fichier
la question n'est pas hs, la reponse se devait donc d'etre : on ne peut
pas par defaut ...
il n'y a pas hs, il y a impossibilite de le faire, tu vois la nuance ?

Je précise que si personne explique, même si je le fais à ma manière, tu
peux pas savoir.

merci :-PPP

Pour n'ennuyer personne, va plutôt du côté du news group que je t'ai donné
précédemment, ici, nous sommes hors sujet.

je ne suis pas en accord avec le HS toutefois :-)
par contre j'ai ma reponse : le c++ ne le fait pas en standard ... donc
d'autres questions sur le mem sujet seraient HS en effet , mais pas la
premiere :-)

@+
ricky

ricky

05/10/2003 à 20:38

bonjour

Ni sur la longueur, sauf cas particulier.

ouich

Attention, en revanche. La fonction stat ne fait pas partie de la norme,
et n'est pas présente partout. (Je crois que sous Windows, elle
s'appelle _stat, ou __stat, par exemple.)

j'avoue utiliser gcc sous tout environnement (justement parceque je le
trouve sous tout environnement :-) )
donc cela me donne une autre reponse : c'est sur un newsgroup sur gcc
que je doit aller en fait :-)

Non. Le C++ standard ne connaît même pas le concepte des
répertoires. Une fois de plus, il faudrait se rebattre sur des
fonctions propre au système : opendir/readdir sous Unix,
findFirst/findNext (je crois) sous Windows.

merci a toi

Tu te trompes. Avec le C++ pûrement standard, on ne peut pas faire
grand chose.

c'est pour cela que j'englobe en fait la stl dans les discussions sur le
c++ (a tort d'apres les reponses)

Selon ce que tu entends par graphisme, il faudrait se
rebattre sur des bibliothèques tierces ou sur des fonctions propre au
système.

oui
je pensais que la stl pourrait evoluer et fournir des solutions de plus
en plus generales comme elle l'a fait pour les string et bcp d'autres
problemes divers...
et surtout sur la gestion de repertoire ...
mais effectivement a chacun son job, je comprend cela ...

merci de vos reponses qui me seront tres utiles ...

@+
ricky

ricky

05/10/2003 à 20:39

bonjour

de la stl : non. mais à la façon de la stl, c'est possible.
va voir si boost::filesystem de Beman Dawes
http://www.boost.org/libs/filesystem/doc/index.htm
fait ce que tu veux.

merci :-)

je sens quelque chose qui me convient dans le coin, je vais aller voir !

@+
ricky

Christophe Lephay

05/10/2003 à 21:00

"ricky" a écrit dans le message de
news:3f80640c$0$27575$

je ne comprend d'ailleurs pas trop pourquoi .. on va me dire : ben ca
depend du systeme...
je repondrais : pour moi, une chaine de caractere ou la notion de
pointeur depend aussi completement du systeme, un cout aussi...
alors pourquoi ne pas pousser un peu le bouchin et metre au moins des
bases pratiques dans la stl, comme celle ci a integrer des notions de
string ou de recherche dans un fichier...

Je ne connais pas la position précise du comité à ce sujet, néanmoins...

Pour une structure aussi complexe qu'une interface graphique, c'est dur de
définir précisément les fonctionnalités que tu y mets et celle que tu ne
mets pas. Si tu en mets tropn tu vas rendre beaucoup de systèmes
incompatibles avec le standard. Si tu n'en mets pas assez, tu obliges
l'utilisateur à passer par d'autres moyens pour bien exploiter son système.

Peut-être une autre raison se trouve dans le boulot à accomplir...

Chris

Samuel Krempp

06/10/2003 à 01:55

le Sunday 05 October 2003 20:34, écrivit :

Pour n'ennuyer personne, va plutôt du côté du news group que je t'ai
donné précédemment, ici, nous sommes hors sujet.

je ne suis pas en accord avec le HS toutefois :-)

je suis bien de ton avis, demander si il est possible de faire telle ou
telle chose en C++ est bien en thème.

par contre j'ai ma reponse : le c++ ne le fait pas en standard ... donc
d'autres questions sur le mem sujet seraient HS en effet , mais pas la
premiere :-)

même de telles questions peuvent être en thèmes, bien que ça commence à se
rapprocher de la limite. "connaissez vous des librairies portables pour
faire <XXXX> en C++" est en thème si je ne me méprends pas.
Ce n'est pas le cas des moultes questions spécifiques à un OS, ou un
environnement de développement, genre "comment faire un zorglub bleu avec
PowerTruc++ sous windows XP ?"
(et c'est ce genre de questions qui envahirait très vite le forum si rien
n'est fait pour l'éviter. les efforts renouvelés de Fabien sont très utiles
de coté)

--
Sam

kanze

06/10/2003 à 11:20

ricky wrote in message
news:<3f8064e3$0$27575$...

Ni sur la longueur, sauf cas particulier.

ouich

Attention, en revanche. La fonction stat ne fait pas partie de la
norme, et n'est pas présente partout. (Je crois que sous Windows,
elle s'appelle _stat, ou __stat, par exemple.)

j'avoue utiliser gcc sous tout environnement (justement parceque je le
trouve sous tout environnement :-) ) donc cela me donne une autre
reponse : c'est sur un newsgroup sur gcc que je doit aller en fait :-)

Éventuellement. Ça dépend en fait de la bibliothèque utilisée. Sous
Solaris, au moins, j'ai bien opendir/readdir avec g++, mais pas DE g++.
Si ton g++ Windows, c'est celui de CygWin, tu dois avoir la plupart des
fonctionnalités de Unix, je crois, donc peut-être opendir/readdir aussi.
Sinon, il est peut-être plus probable que tu as les appels Windows de
base, c-à-d findFirst/findNext.

En somme g++ implémente le langage C++ de façon portable, mais laisse
apparaître le système sur lequel le programme tourne à travers ses
bibliothèques (c-à-d celles du système).

Non. Le C++ standard ne connaît même pas le concepte des
répertoires. Une fois de plus, il faudrait se rebattre sur des
fonctions propre au système : opendir/readdir sous Unix,
findFirst/findNext (je crois) sous Windows.

merci a toi

Tu te trompes. Avec le C++ pûrement standard, on ne peut pas faire
grand chose.

c'est pour cela que j'englobe en fait la stl dans les discussions sur
le c++ (a tort d'apres les reponses)

La STL a été adopté, avec modifications, en C++ -- elle fait donc partie
du langage. Mais la STL, proprement parlant, est une bibliothèque des
collections, des itérateurs sur ces collections, et des algorithmes qui
travaillent avec de tels itérateurs. Elle ne concerne en rien
l'environement où tourne le programme.

Selon ce que tu entends par graphisme, il faudrait se rebattre sur
des bibliothèques tierces ou sur des fonctions propre au système.

oui je pensais que la stl pourrait evoluer et fournir des solutions de
plus en plus generales comme elle l'a fait pour les string et bcp
d'autres problemes divers...

L'aspect graphique, c'est difficile. Personellement, j'aimerais qu'il y
ait une interface standard. Mais je crois que politiquement, ce n'est
pas faisable -- quelque soit l'interface adoptée, il y en aurait trop
qui ont trop d'intérêts financiels dans une autre interface pour
l'accepter. Un consensus ne me semble pas possible.

En attendant, je ne le connais pas, mais je vois que wxWindows semble se
répandre assez. C'est peut-être une solution pour une interface
portable. Sinon, à
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html, il y a
un embarras du choix.

et surtout sur la gestion de repertoire ...

Là, il y a peut-être d'avantage de chance. Samuel a bien fait de cité la
classe Boost, que j'avais oublié. (Je ne me suis rappelé que d'un effort
antérieur de la part de Dietmar Kühl.) Je n'en ai pas encore eu besoin ;
je ne sais pas donc ce qu'elle supporte, mais si c'est comme la reste de
Boost, c'est assez bien pensé, et très bien implémenté. À condition de
ne pas être coincé avec un compilateur antédiluvien comme moi (Sun CC
mode compat=4, c-à-d pratiquement Sun CC 4.2, de 1994).

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

ricky <eric_nyme@yahoo.fr> wrote in message
news:<3f8064e3$0$27575$626a54ce@news.free.fr>...

Ni sur la longueur, sauf cas particulier.

ouich

Attention, en revanche. La fonction stat ne fait pas partie de la
norme, et n'est pas présente partout. (Je crois que sous Windows,
elle s'appelle _stat, ou __stat, par exemple.)

j'avoue utiliser gcc sous tout environnement (justement parceque je le
trouve sous tout environnement :-) ) donc cela me donne une autre
reponse : c'est sur un newsgroup sur gcc que je doit aller en fait :-)

Éventuellement. Ça dépend en fait de la bibliothèque utilisée. Sous
Solaris, au moins, j'ai bien opendir/readdir avec g++, mais pas DE g++.
Si ton g++ Windows, c'est celui de CygWin, tu dois avoir la plupart des
fonctionnalités de Unix, je crois, donc peut-être opendir/readdir aussi.
Sinon, il est peut-être plus probable que tu as les appels Windows de
base, c-à-d findFirst/findNext.

En somme g++ implémente le langage C++ de façon portable, mais laisse
apparaître le système sur lequel le programme tourne à travers ses
bibliothèques (c-à-d celles du système).

Non. Le C++ standard ne connaît même pas le concepte des
répertoires. Une fois de plus, il faudrait se rebattre sur des
fonctions propre au système : opendir/readdir sous Unix,
findFirst/findNext (je crois) sous Windows.

merci a toi

Tu te trompes. Avec le C++ pûrement standard, on ne peut pas faire
grand chose.

c'est pour cela que j'englobe en fait la stl dans les discussions sur
le c++ (a tort d'apres les reponses)

La STL a été adopté, avec modifications, en C++ -- elle fait donc partie
du langage. Mais la STL, proprement parlant, est une bibliothèque des
collections, des itérateurs sur ces collections, et des algorithmes qui
travaillent avec de tels itérateurs. Elle ne concerne en rien
l'environement où tourne le programme.

Selon ce que tu entends par graphisme, il faudrait se rebattre sur
des bibliothèques tierces ou sur des fonctions propre au système.

oui je pensais que la stl pourrait evoluer et fournir des solutions de
plus en plus generales comme elle l'a fait pour les string et bcp
d'autres problemes divers...

L'aspect graphique, c'est difficile. Personellement, j'aimerais qu'il y
ait une interface standard. Mais je crois que politiquement, ce n'est
pas faisable -- quelque soit l'interface adoptée, il y en aurait trop
qui ont trop d'intérêts financiels dans une autre interface pour
l'accepter. Un consensus ne me semble pas possible.

En attendant, je ne le connais pas, mais je vois que wxWindows semble se
répandre assez. C'est peut-être une solution pour une interface
portable. Sinon, à
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html, il y a
un embarras du choix.

et surtout sur la gestion de repertoire ...

Là, il y a peut-être d'avantage de chance. Samuel a bien fait de cité la
classe Boost, que j'avais oublié. (Je ne me suis rappelé que d'un effort
antérieur de la part de Dietmar Kühl.) Je n'en ai pas encore eu besoin ;
je ne sais pas donc ce qu'elle supporte, mais si c'est comme la reste de
Boost, c'est assez bien pensé, et très bien implémenté. À condition de
ne pas être coincé avec un compilateur antédiluvien comme moi (Sun CC
mode compat=4, c-à-d pratiquement Sun CC 4.2, de 1994).

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Vous avez filtré cet utilisateur ! Consultez son message

ricky wrote in message
news:<3f8064e3$0$27575$...

Ni sur la longueur, sauf cas particulier.

ouich

Attention, en revanche. La fonction stat ne fait pas partie de la
norme, et n'est pas présente partout. (Je crois que sous Windows,
elle s'appelle _stat, ou __stat, par exemple.)

j'avoue utiliser gcc sous tout environnement (justement parceque je le
trouve sous tout environnement :-) ) donc cela me donne une autre
reponse : c'est sur un newsgroup sur gcc que je doit aller en fait :-)

Éventuellement. Ça dépend en fait de la bibliothèque utilisée. Sous
Solaris, au moins, j'ai bien opendir/readdir avec g++, mais pas DE g++.
Si ton g++ Windows, c'est celui de CygWin, tu dois avoir la plupart des
fonctionnalités de Unix, je crois, donc peut-être opendir/readdir aussi.
Sinon, il est peut-être plus probable que tu as les appels Windows de
base, c-à-d findFirst/findNext.

En somme g++ implémente le langage C++ de façon portable, mais laisse
apparaître le système sur lequel le programme tourne à travers ses
bibliothèques (c-à-d celles du système).

Non. Le C++ standard ne connaît même pas le concepte des
répertoires. Une fois de plus, il faudrait se rebattre sur des
fonctions propre au système : opendir/readdir sous Unix,
findFirst/findNext (je crois) sous Windows.

merci a toi

Tu te trompes. Avec le C++ pûrement standard, on ne peut pas faire
grand chose.

c'est pour cela que j'englobe en fait la stl dans les discussions sur
le c++ (a tort d'apres les reponses)

La STL a été adopté, avec modifications, en C++ -- elle fait donc partie
du langage. Mais la STL, proprement parlant, est une bibliothèque des
collections, des itérateurs sur ces collections, et des algorithmes qui
travaillent avec de tels itérateurs. Elle ne concerne en rien
l'environement où tourne le programme.

Selon ce que tu entends par graphisme, il faudrait se rebattre sur
des bibliothèques tierces ou sur des fonctions propre au système.

oui je pensais que la stl pourrait evoluer et fournir des solutions de
plus en plus generales comme elle l'a fait pour les string et bcp
d'autres problemes divers...

L'aspect graphique, c'est difficile. Personellement, j'aimerais qu'il y
ait une interface standard. Mais je crois que politiquement, ce n'est
pas faisable -- quelque soit l'interface adoptée, il y en aurait trop
qui ont trop d'intérêts financiels dans une autre interface pour
l'accepter. Un consensus ne me semble pas possible.

En attendant, je ne le connais pas, mais je vois que wxWindows semble se
répandre assez. C'est peut-être une solution pour une interface
portable. Sinon, à
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html, il y a
un embarras du choix.

et surtout sur la gestion de repertoire ...

Là, il y a peut-être d'avantage de chance. Samuel a bien fait de cité la
classe Boost, que j'avais oublié. (Je ne me suis rappelé que d'un effort
antérieur de la part de Dietmar Kühl.) Je n'en ai pas encore eu besoin ;
je ne sais pas donc ce qu'elle supporte, mais si c'est comme la reste de
Boost, c'est assez bien pensé, et très bien implémenté. À condition de
ne pas être coincé avec un compilateur antédiluvien comme moi (Sun CC
mode compat=4, c-à-d pratiquement Sun CC 4.2, de 1994).

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Gourgouilloult

06/10/2003 à 11:29

ricky wrote:

je ne comprend d'ailleurs pas trop pourquoi .. on va me dire : ben ca
depend du systeme...
je repondrais : pour moi, une chaine de caractere ou la notion de
pointeur depend aussi completement du systeme, un cout aussi...
alors pourquoi ne pas pousser un peu le bouchin et metre au moins des
bases pratiques dans la stl, comme celle ci a integrer des notions de
string ou de recherche dans un fichier...

Les conteneurs linéaires ou les chaînes de caractères font partie des
structures algorithmiques de base. On s'en sert d'une façon ou d'une
autre dans tous les programmes de plus de 10 lignes, et on sait,
indépendamment de tout problème, ce qu'on peut en attendre. Pour les
entrées/sorties, c'est très dépendant du système effectivement, mais là
aussi on va s'en servir très souvent, alors on a fixé une interface pour
tout le monde.

Donc si quelque chose se retrouve dans la SL (qui, si j'ai bien compris,
est la généralisation de la STL aux choses plus dépendantes du système,
comme les entrées-sorties), c'est parce que tout le monde en a besoin, à
un moment ou un autre.

Ce n'est pas vrai par contre pour d'autres choses dont tu parles, comme
la gestion d'IHM, de communications réseau... On peut coder fort
longtemps sans avoir besoin d'approcher ces domaines là. Par exemple,
est-ce que ça t'intéresserait vraiment que la librairie standard propose
des outils de programmation parallèle, crypto, gestion de bases de
données, rendu html...

Non, les gens qui travaillent sur C++ se concentrent vraiment sur
l'essentiel, et ça leur fait déjà pas mal de boulot je crois. Les choses
que j'ai citées recouvrent des domaines complètement disjoints, et tout
mettre ensemble serait artificiel.

Fais gaffe avec stat. 1, c'est HS

pourquoi HS ?
j'ai trouve stat dans un include fourni avec cygwin.
je pensais que cela faisait donc parti du langage "etendu" (je considere
effectivement par extension le c++ comme le langage c++ ET ce que
fourni la stl de maniere standard)

(piqué un peu plus loin)

d'autres langages (en etendu) le font, y compris java ... donc pourquoi
pas c++

(piqué encore plus loin)

Et c'est pour ça que nous sommes HS ici, simplement parce que ces choses
sont une déviance hérétique du langage C++ qui n'est pas fait pour ça.

il n'est fait pour quasiment rien à la base ... donc toutes vos
discussions sont HS par defaut :-)))

Il y a dans ce que tu dis là une ambiguïté, que j'ai moi-même eu un peu
de difficulté à percer quand j'ai débarqué. S'il y a effectivement une
distinction entre le langage et sa librairie standard, les deux sont
idéalement indisociables. L'élément liant, c'est la norme, qui définit
ce qu'est C++, et qui comprend l'un et l'autre.

Donc parler de la SL, ce n'est pas parler d'un «C++ étendu». C'est, à la
rigueur, ne pas se limiter au coeur du langage. En particulier, ça n'est
pas HS de causer de la SL, comme indiqué dans la charte :
<extrait>
Ce groupe est dédié aux discussions autour du langage C++ uniquement.
On y trouvera par exemple :
* des informations sur les bibliothèques standards (STL, String, etc...)
</extrait>

Pour ce qui est de java, je crois que sa bibliothèque n'en est pas plus
dissociée. Par contre c'est vrai qu'elle «fait plus de choses». D'un
autre côté, le langage fait nettement moins en lui-même. C'est une
question de choix, très certainement (et donc sujet à trolls, je ne
développe donc pas sur mes sentiments personnels ;).

gens qui ont ajoutés ces choses au C++, qui ont développé tellement de
choses ne sont PAS les créateurs du langage.

la stl doit bcp aux createurs
ensuite, le c++ a evolue aussi en dehors de ses createurs de base

C'est dans la continuité de cette ambiguïté, sur laquelle je me cassais
un peu les dents moi-même quand je n'avais pas de notion de
fonctionnement du comité de standardisation. Mais le fait est que l'on
peut distinguer des «créateurs» de C++ (ou de la SL) à différents
niveaux et que, quelque soit le niveau que tu considères, oui, C++
continue à évoluer.

Pour faire schématique, on peut distinguer la base : Stroustrup,
quelques collègues d'AT&T et autres, qui ont commencé par jeter les
bases du langage (les principes comme les éléments importants).

Sur ce premier groupe sont venus se rajouter une foule d'utilisateurs
(qui faisaient et font toujours évoluer le langage, d'une certaine
manière, par l'utilisation qu'ils en font, en rajoutant leurs libs
maisons... c'est un peu tiré par les cheuveux, mais je pense que c'est
ce dont tu voulais parler).

Pis au début des années 90, le comité de standardisation s'est formé,
pour formaliser un peu le langage, décider de ce qu'il fallait garder ou
jeter... et on produit un document, auquel on fait familièrement
référence sous le terme «la norme».

Tel que je comprends ton propos, les «créateurs de base de C++», ce
serait le comité. Seulement il faut savoir que le C++ continue à évoluer
à _leur_ niveau. Voir les fils de discussion sur la réunion à Kona dans
15 jours.

@+
ricky

Désolé si c'était un peu long. J'espère juste que ça pourra lever
quelques doutes. Si ça t'intéresse, je ne saurais que trop te conseiller
«The Design and Evolution of C++» de Stroustrup...

Gourgouilloult du Clapotis

ricky wrote:

je ne comprend d'ailleurs pas trop pourquoi .. on va me dire : ben ca
depend du systeme...
je repondrais : pour moi, une chaine de caractere ou la notion de
pointeur depend aussi completement du systeme, un cout aussi...
alors pourquoi ne pas pousser un peu le bouchin et metre au moins des
bases pratiques dans la stl, comme celle ci a integrer des notions de
string ou de recherche dans un fichier...

Les conteneurs linéaires ou les chaînes de caractères font partie des
structures algorithmiques de base. On s'en sert d'une façon ou d'une
autre dans tous les programmes de plus de 10 lignes, et on sait,
indépendamment de tout problème, ce qu'on peut en attendre. Pour les
entrées/sorties, c'est très dépendant du système effectivement, mais là
aussi on va s'en servir très souvent, alors on a fixé une interface pour
tout le monde.

Donc si quelque chose se retrouve dans la SL (qui, si j'ai bien compris,
est la généralisation de la STL aux choses plus dépendantes du système,
comme les entrées-sorties), c'est parce que tout le monde en a besoin, à
un moment ou un autre.

Ce n'est pas vrai par contre pour d'autres choses dont tu parles, comme
la gestion d'IHM, de communications réseau... On peut coder fort
longtemps sans avoir besoin d'approcher ces domaines là. Par exemple,
est-ce que ça t'intéresserait vraiment que la librairie standard propose
des outils de programmation parallèle, crypto, gestion de bases de
données, rendu html...

Non, les gens qui travaillent sur C++ se concentrent vraiment sur
l'essentiel, et ça leur fait déjà pas mal de boulot je crois. Les choses
que j'ai citées recouvrent des domaines complètement disjoints, et tout
mettre ensemble serait artificiel.

Fais gaffe avec stat. 1, c'est HS

pourquoi HS ?
j'ai trouve stat dans un include fourni avec cygwin.
je pensais que cela faisait donc parti du langage "etendu" (je considere
effectivement par extension le c++ comme le langage c++ ET ce que
fourni la stl de maniere standard)

(piqué un peu plus loin)

d'autres langages (en etendu) le font, y compris java ... donc pourquoi
pas c++

(piqué encore plus loin)

Et c'est pour ça que nous sommes HS ici, simplement parce que ces choses
sont une déviance hérétique du langage C++ qui n'est pas fait pour ça.

il n'est fait pour quasiment rien à la base ... donc toutes vos
discussions sont HS par defaut :-)))

Il y a dans ce que tu dis là une ambiguïté, que j'ai moi-même eu un peu
de difficulté à percer quand j'ai débarqué. S'il y a effectivement une
distinction entre le langage et sa librairie standard, les deux sont
idéalement indisociables. L'élément liant, c'est la norme, qui définit
ce qu'est C++, et qui comprend l'un et l'autre.

Donc parler de la SL, ce n'est pas parler d'un «C++ étendu». C'est, à la
rigueur, ne pas se limiter au coeur du langage. En particulier, ça n'est
pas HS de causer de la SL, comme indiqué dans la charte :
<extrait>
Ce groupe est dédié aux discussions autour du langage C++ uniquement.
On y trouvera par exemple :
* des informations sur les bibliothèques standards (STL, String, etc...)
</extrait>

Pour ce qui est de java, je crois que sa bibliothèque n'en est pas plus
dissociée. Par contre c'est vrai qu'elle «fait plus de choses». D'un
autre côté, le langage fait nettement moins en lui-même. C'est une
question de choix, très certainement (et donc sujet à trolls, je ne
développe donc pas sur mes sentiments personnels ;).

gens qui ont ajoutés ces choses au C++, qui ont développé tellement de
choses ne sont PAS les créateurs du langage.

la stl doit bcp aux createurs
ensuite, le c++ a evolue aussi en dehors de ses createurs de base

C'est dans la continuité de cette ambiguïté, sur laquelle je me cassais
un peu les dents moi-même quand je n'avais pas de notion de
fonctionnement du comité de standardisation. Mais le fait est que l'on
peut distinguer des «créateurs» de C++ (ou de la SL) à différents
niveaux et que, quelque soit le niveau que tu considères, oui, C++
continue à évoluer.

Pour faire schématique, on peut distinguer la base : Stroustrup,
quelques collègues d'AT&T et autres, qui ont commencé par jeter les
bases du langage (les principes comme les éléments importants).

Sur ce premier groupe sont venus se rajouter une foule d'utilisateurs
(qui faisaient et font toujours évoluer le langage, d'une certaine
manière, par l'utilisation qu'ils en font, en rajoutant leurs libs
maisons... c'est un peu tiré par les cheuveux, mais je pense que c'est
ce dont tu voulais parler).

Pis au début des années 90, le comité de standardisation s'est formé,
pour formaliser un peu le langage, décider de ce qu'il fallait garder ou
jeter... et on produit un document, auquel on fait familièrement
référence sous le terme «la norme».

Tel que je comprends ton propos, les «créateurs de base de C++», ce
serait le comité. Seulement il faut savoir que le C++ continue à évoluer
à _leur_ niveau. Voir les fils de discussion sur la réunion à Kona dans
15 jours.

@+
ricky

Désolé si c'était un peu long. J'espère juste que ça pourra lever
quelques doutes. Si ça t'intéresse, je ne saurais que trop te conseiller
«The Design and Evolution of C++» de Stroustrup...

Gourgouilloult du Clapotis

Vous avez filtré cet utilisateur ! Consultez son message

ricky wrote:

je ne comprend d'ailleurs pas trop pourquoi .. on va me dire : ben ca
depend du systeme...
je repondrais : pour moi, une chaine de caractere ou la notion de
pointeur depend aussi completement du systeme, un cout aussi...
alors pourquoi ne pas pousser un peu le bouchin et metre au moins des
bases pratiques dans la stl, comme celle ci a integrer des notions de
string ou de recherche dans un fichier...

Les conteneurs linéaires ou les chaînes de caractères font partie des
structures algorithmiques de base. On s'en sert d'une façon ou d'une
autre dans tous les programmes de plus de 10 lignes, et on sait,
indépendamment de tout problème, ce qu'on peut en attendre. Pour les
entrées/sorties, c'est très dépendant du système effectivement, mais là
aussi on va s'en servir très souvent, alors on a fixé une interface pour
tout le monde.

Donc si quelque chose se retrouve dans la SL (qui, si j'ai bien compris,
est la généralisation de la STL aux choses plus dépendantes du système,
comme les entrées-sorties), c'est parce que tout le monde en a besoin, à
un moment ou un autre.

Ce n'est pas vrai par contre pour d'autres choses dont tu parles, comme
la gestion d'IHM, de communications réseau... On peut coder fort
longtemps sans avoir besoin d'approcher ces domaines là. Par exemple,
est-ce que ça t'intéresserait vraiment que la librairie standard propose
des outils de programmation parallèle, crypto, gestion de bases de
données, rendu html...

Non, les gens qui travaillent sur C++ se concentrent vraiment sur
l'essentiel, et ça leur fait déjà pas mal de boulot je crois. Les choses
que j'ai citées recouvrent des domaines complètement disjoints, et tout
mettre ensemble serait artificiel.

Fais gaffe avec stat. 1, c'est HS

pourquoi HS ?
j'ai trouve stat dans un include fourni avec cygwin.
je pensais que cela faisait donc parti du langage "etendu" (je considere
effectivement par extension le c++ comme le langage c++ ET ce que
fourni la stl de maniere standard)

(piqué un peu plus loin)

d'autres langages (en etendu) le font, y compris java ... donc pourquoi
pas c++

(piqué encore plus loin)

Et c'est pour ça que nous sommes HS ici, simplement parce que ces choses
sont une déviance hérétique du langage C++ qui n'est pas fait pour ça.

il n'est fait pour quasiment rien à la base ... donc toutes vos
discussions sont HS par defaut :-)))

Il y a dans ce que tu dis là une ambiguïté, que j'ai moi-même eu un peu
de difficulté à percer quand j'ai débarqué. S'il y a effectivement une
distinction entre le langage et sa librairie standard, les deux sont
idéalement indisociables. L'élément liant, c'est la norme, qui définit
ce qu'est C++, et qui comprend l'un et l'autre.

Donc parler de la SL, ce n'est pas parler d'un «C++ étendu». C'est, à la
rigueur, ne pas se limiter au coeur du langage. En particulier, ça n'est
pas HS de causer de la SL, comme indiqué dans la charte :
<extrait>
Ce groupe est dédié aux discussions autour du langage C++ uniquement.
On y trouvera par exemple :
* des informations sur les bibliothèques standards (STL, String, etc...)
</extrait>

Pour ce qui est de java, je crois que sa bibliothèque n'en est pas plus
dissociée. Par contre c'est vrai qu'elle «fait plus de choses». D'un
autre côté, le langage fait nettement moins en lui-même. C'est une
question de choix, très certainement (et donc sujet à trolls, je ne
développe donc pas sur mes sentiments personnels ;).

gens qui ont ajoutés ces choses au C++, qui ont développé tellement de
choses ne sont PAS les créateurs du langage.

la stl doit bcp aux createurs
ensuite, le c++ a evolue aussi en dehors de ses createurs de base

C'est dans la continuité de cette ambiguïté, sur laquelle je me cassais
un peu les dents moi-même quand je n'avais pas de notion de
fonctionnement du comité de standardisation. Mais le fait est que l'on
peut distinguer des «créateurs» de C++ (ou de la SL) à différents
niveaux et que, quelque soit le niveau que tu considères, oui, C++
continue à évoluer.

Pour faire schématique, on peut distinguer la base : Stroustrup,
quelques collègues d'AT&T et autres, qui ont commencé par jeter les
bases du langage (les principes comme les éléments importants).

Sur ce premier groupe sont venus se rajouter une foule d'utilisateurs
(qui faisaient et font toujours évoluer le langage, d'une certaine
manière, par l'utilisation qu'ils en font, en rajoutant leurs libs
maisons... c'est un peu tiré par les cheuveux, mais je pense que c'est
ce dont tu voulais parler).

Pis au début des années 90, le comité de standardisation s'est formé,
pour formaliser un peu le langage, décider de ce qu'il fallait garder ou
jeter... et on produit un document, auquel on fait familièrement
référence sous le terme «la norme».

Tel que je comprends ton propos, les «créateurs de base de C++», ce
serait le comité. Seulement il faut savoir que le C++ continue à évoluer
à _leur_ niveau. Voir les fils de discussion sur la réunion à Kona dans
15 jours.

@+
ricky

Désolé si c'était un peu long. J'espère juste que ça pourra lever
quelques doutes. Si ça t'intéresse, je ne saurais que trop te conseiller
«The Design and Evolution of C++» de Stroustrup...

Gourgouilloult du Clapotis

informations sur les fichiers

10 réponses

Veuillez sélectionner un problème