alors que si je laisse dans la déclaration de la classe, ça donne
iterator first_with(cond& c);
Je m'en sort à grands coups de
#define X_TEMPLATE template<class T>
#define X X<T>
#define iterator typename X<T>::iterator
#define cond typename X<T>::cond
mais c'est lourd.
Vous faites comment vous ? Un super éditeur/IDE qui cache tout le sucre ?
Et sinon, pourquoi les classes (enfin, mon compilo) ne permettent elle pas
de faire
class X {
void foo(); // Déclaration
...
void foo(){...}; // Implementation
}
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
"Jean-Marc Bourguet" a écrit dans le message de news:
"K. Ahausse" writes:
Pouvoir dérouler le programme dans ses recoins, évite, parfois, d'attendre qu'un bug ait à se manifester.
Et comment tu mesures ta couverture de code si ces tests que tu fais sont uniquement manuels et au debuggeur?
C'est une des raisons qui me fait dire que cette voie n'est pas la panacée.
K. Ahausse
"Arnaud Meurgues" a écrit dans le message de news:419c5f5e$0$24745$
K. Ahausse wrote:
A ma décharge : à l'époque utiliser, un traitement de texte, en tant qu'éditeur de sources n'avait rien de choquant.
À quelle époque ? Aucun des traitements de texte que j'ai connus ne m'a jamais paru adéquat pour écrire du code.
Epoque : - pré-PC : Prologue, CP/M - MS-DOS dans ces débuts.
Lorsque le graphique n'avait pas envahit les écrans, les premiers traitement de textes étaient plutôt simplistes, il était possible en délaissant certaines fonctionnalités d'éditer un source, assemblable ou compilable par la suite.
"Arnaud Meurgues" <arnaud@meurgues.non.fr.invalid> a écrit dans le message
de news:419c5f5e$0$24745$626a14ce@news.free.fr...
K. Ahausse wrote:
A ma décharge : à l'époque utiliser, un traitement de texte, en tant
qu'éditeur de sources n'avait rien de choquant.
À quelle époque ? Aucun des traitements de texte que j'ai connus ne m'a
jamais paru adéquat pour écrire du code.
Epoque :
- pré-PC : Prologue, CP/M
- MS-DOS dans ces débuts.
Lorsque le graphique n'avait pas envahit les écrans, les premiers traitement
de textes étaient plutôt simplistes, il était possible en délaissant
certaines fonctionnalités d'éditer un source, assemblable ou compilable par
la suite.
"Arnaud Meurgues" a écrit dans le message de news:419c5f5e$0$24745$
K. Ahausse wrote:
A ma décharge : à l'époque utiliser, un traitement de texte, en tant qu'éditeur de sources n'avait rien de choquant.
À quelle époque ? Aucun des traitements de texte que j'ai connus ne m'a jamais paru adéquat pour écrire du code.
Epoque : - pré-PC : Prologue, CP/M - MS-DOS dans ces débuts.
Lorsque le graphique n'avait pas envahit les écrans, les premiers traitement de textes étaient plutôt simplistes, il était possible en délaissant certaines fonctionnalités d'éditer un source, assemblable ou compilable par la suite.
K. Ahausse
a écrit dans le message de news:
Pourquoi ? D'abord, évidemment, il faut une édition de liens là-dedans quelque part. Or, des deux choses une :
Bon, par déformation je n'ai parlé que de la compilation, mais après avoir éditer les sources, l'appuie d'une touche lance la compilation des sources impactés et lance automatiquement l'édition de lien.
- L'édition de liens et le code que tu déboggues, c'est le test unitaire. Mais dans ce cas-là, tu as mis assez de sorties d'état pour que l'erreur soit évidente, sans le déboggueur.
- Tu parles de l'application. Mais dans ce cas-là, typiquement, tu ne peux pas faire l'édition de liens, parce qu'il en dépend d'autres modules auquels tu n'as pas réelement accès. (C'est pour ça qu'il y a une équipe d'integration.)
Là, il y a un problème d'échelle, je parlais en mon nom, développeur d'applis non-gigantesques. Que cela ne puisse pas s'appliquer partout, était implicite.
Dans la pratique, je me sers du déboggueur prèsqu'uniquement pour l'analyse des core dumps : surtout pour le stack walkback après l'échec d'une assertion. Sinon, assez rarement, pour l'analyse du dynamique d'un code que je n'ai pas écrit.
Dans le professionnel, je réfuse d'essuyer les plâtres ; je ne considère
Je n'ai pas cette chance, il m'arrive, encore, aujourd'hui, des faire avec des brics et des brocs.
que des produits « établis » avec assez d'utilisateurs pour qu'on puisse être sûr que les grosses erreurs ont été déjà éradiquées. Mais même sans essuyer les plâtres, il y a un coût énorme pour simplement évaluer. Alors, à moins que la nouvelle technologie m'apporte quelque chose, ce n'est pas la peine. Et quand on m'annonce que l'amélioration apportée par un IDE, c'est une amélioration de l'ergonomie du cycle edition+compilation+debug, ça ne m'intéresse pas, parce que c'est un cycle qui n'existe pas dans mon développement. C'est un peu comme si on offrait une technologie pour rendre l'utilisation d'une voiture à cheval deux fois plus facile.
De ton point de vue, fort honorable, je ne consterais pas la metaphore de la voiture. De mon point de vue, je dirais : peintre sur soie et peintre en batiment :-)
Et que donc, du coup, du moment qu'on a quelque chose qui marche, même si ce n'est pas optimal, on se contente.
Malheureusement, le risque est de rester coincer, ( comme je peux, quotidiennement, le constater autour de moi ) avec des outils complétements dépassés.
Il faut effectivement rester à l'écoute, pour le cas où une nouvelle technologie apporte quelque chose. Et il y a bien une risque qu'on râte une nouvelle technologie utile, parce que les avocats de la technologie n'ont pas présenté ses avantages correctement. C'est fort possible qu'un bon IDE pourrait apporter quelque chose. Mais jusqu'ici, les avocats en parle de comment il améliore les processus de développement que j'ai abandonné il y a une dizaine d'années. Alors, je n'ai pas pris le temps de les étudier plus en détail.
<kanze@gabi-soft.fr> a écrit dans le message de
news:d6652001.0411180108.2e328949@posting.google.com...
Pourquoi ? D'abord, évidemment, il faut une édition de liens là-dedans
quelque part. Or, des deux choses une :
Bon, par déformation je n'ai parlé que de la compilation, mais après avoir
éditer les sources, l'appuie d'une touche lance la compilation des sources
impactés et lance automatiquement l'édition de lien.
- L'édition de liens et le code que tu déboggues, c'est le test
unitaire. Mais dans ce cas-là, tu as mis assez de sorties d'état
pour que l'erreur soit évidente, sans le déboggueur.
- Tu parles de l'application. Mais dans ce cas-là, typiquement, tu ne
peux pas faire l'édition de liens, parce qu'il en dépend d'autres
modules auquels tu n'as pas réelement accès. (C'est pour ça qu'il y
a une équipe d'integration.)
Là, il y a un problème d'échelle, je parlais en mon nom, développeur
d'applis non-gigantesques.
Que cela ne puisse pas s'appliquer partout, était implicite.
Dans la pratique, je me sers du déboggueur prèsqu'uniquement pour
l'analyse des core dumps : surtout pour le stack walkback après l'échec
d'une assertion. Sinon, assez rarement, pour l'analyse du dynamique d'un
code que je n'ai pas écrit.
Dans le professionnel, je réfuse d'essuyer les plâtres ; je ne considère
Je n'ai pas cette chance, il m'arrive, encore, aujourd'hui, des faire avec
des brics et des brocs.
que des produits « établis » avec assez d'utilisateurs pour qu'on puisse
être sûr que les grosses erreurs ont été déjà éradiquées. Mais même sans
essuyer les plâtres, il y a un coût énorme pour simplement évaluer.
Alors, à moins que la nouvelle technologie m'apporte quelque chose, ce
n'est pas la peine. Et quand on m'annonce que l'amélioration apportée
par un IDE, c'est une amélioration de l'ergonomie du cycle
edition+compilation+debug, ça ne m'intéresse pas, parce que c'est un
cycle qui n'existe pas dans mon développement. C'est un peu comme si on
offrait une technologie pour rendre l'utilisation d'une voiture à cheval
deux fois plus facile.
De ton point de vue, fort honorable, je ne consterais pas la metaphore de
la voiture.
De mon point de vue, je dirais : peintre sur soie et peintre en batiment :-)
Et que donc, du coup, du moment qu'on a quelque chose qui marche,
même si ce n'est pas optimal, on se contente.
Malheureusement, le risque est de rester coincer, ( comme je peux,
quotidiennement, le constater autour de moi ) avec des outils
complétements dépassés.
Il faut effectivement rester à l'écoute, pour le cas où une nouvelle
technologie apporte quelque chose. Et il y a bien une risque qu'on râte
une nouvelle technologie utile, parce que les avocats de la technologie
n'ont pas présenté ses avantages correctement. C'est fort possible qu'un
bon IDE pourrait apporter quelque chose. Mais jusqu'ici, les avocats en
parle de comment il améliore les processus de développement que j'ai
abandonné il y a une dizaine d'années. Alors, je n'ai pas pris le temps
de les étudier plus en détail.
Pourquoi ? D'abord, évidemment, il faut une édition de liens là-dedans quelque part. Or, des deux choses une :
Bon, par déformation je n'ai parlé que de la compilation, mais après avoir éditer les sources, l'appuie d'une touche lance la compilation des sources impactés et lance automatiquement l'édition de lien.
- L'édition de liens et le code que tu déboggues, c'est le test unitaire. Mais dans ce cas-là, tu as mis assez de sorties d'état pour que l'erreur soit évidente, sans le déboggueur.
- Tu parles de l'application. Mais dans ce cas-là, typiquement, tu ne peux pas faire l'édition de liens, parce qu'il en dépend d'autres modules auquels tu n'as pas réelement accès. (C'est pour ça qu'il y a une équipe d'integration.)
Là, il y a un problème d'échelle, je parlais en mon nom, développeur d'applis non-gigantesques. Que cela ne puisse pas s'appliquer partout, était implicite.
Dans la pratique, je me sers du déboggueur prèsqu'uniquement pour l'analyse des core dumps : surtout pour le stack walkback après l'échec d'une assertion. Sinon, assez rarement, pour l'analyse du dynamique d'un code que je n'ai pas écrit.
Dans le professionnel, je réfuse d'essuyer les plâtres ; je ne considère
Je n'ai pas cette chance, il m'arrive, encore, aujourd'hui, des faire avec des brics et des brocs.
que des produits « établis » avec assez d'utilisateurs pour qu'on puisse être sûr que les grosses erreurs ont été déjà éradiquées. Mais même sans essuyer les plâtres, il y a un coût énorme pour simplement évaluer. Alors, à moins que la nouvelle technologie m'apporte quelque chose, ce n'est pas la peine. Et quand on m'annonce que l'amélioration apportée par un IDE, c'est une amélioration de l'ergonomie du cycle edition+compilation+debug, ça ne m'intéresse pas, parce que c'est un cycle qui n'existe pas dans mon développement. C'est un peu comme si on offrait une technologie pour rendre l'utilisation d'une voiture à cheval deux fois plus facile.
De ton point de vue, fort honorable, je ne consterais pas la metaphore de la voiture. De mon point de vue, je dirais : peintre sur soie et peintre en batiment :-)
Et que donc, du coup, du moment qu'on a quelque chose qui marche, même si ce n'est pas optimal, on se contente.
Malheureusement, le risque est de rester coincer, ( comme je peux, quotidiennement, le constater autour de moi ) avec des outils complétements dépassés.
Il faut effectivement rester à l'écoute, pour le cas où une nouvelle technologie apporte quelque chose. Et il y a bien une risque qu'on râte une nouvelle technologie utile, parce que les avocats de la technologie n'ont pas présenté ses avantages correctement. C'est fort possible qu'un bon IDE pourrait apporter quelque chose. Mais jusqu'ici, les avocats en parle de comment il améliore les processus de développement que j'ai abandonné il y a une dizaine d'années. Alors, je n'ai pas pris le temps de les étudier plus en détail.
Arnaud Meurgues
K. Ahausse wrote:
À quelle époque ? Aucun des traitements de texte que j'ai connus ne m'a jamais paru adéquat pour écrire du code. Epoque :
- pré-PC : Prologue, CP/M - MS-DOS dans ces débuts.
Vi. On parlait bien de la même époque. Mais à cette époque, je ne me souviens d'aucun traitement de texte que j'aurais eu l'idée d'utiliser comme éditeur de texte (Apple ][ et MS-DOS).
Lorsque le graphique n'avait pas envahit les écrans, les premiers traitement de textes étaient plutôt simplistes, il était possible en délaissant certaines fonctionnalités d'éditer un source, assemblable ou compilable par la suite.
Mouais. Ben j'ai pas connu. Pourtant, j'y étais... :)
-- Arnaud (Supprimez les geneurs pour me répondre)
K. Ahausse wrote:
À quelle époque ? Aucun des traitements de texte que j'ai connus ne m'a
jamais paru adéquat pour écrire du code.
Epoque :
- pré-PC : Prologue, CP/M
- MS-DOS dans ces débuts.
Vi. On parlait bien de la même époque. Mais à cette époque, je ne me
souviens d'aucun traitement de texte que j'aurais eu l'idée d'utiliser
comme éditeur de texte (Apple ][ et MS-DOS).
Lorsque le graphique n'avait pas envahit les écrans, les premiers traitement
de textes étaient plutôt simplistes, il était possible en délaissant
certaines fonctionnalités d'éditer un source, assemblable ou compilable par
la suite.
Mouais. Ben j'ai pas connu. Pourtant, j'y étais... :)
--
Arnaud
(Supprimez les geneurs pour me répondre)
À quelle époque ? Aucun des traitements de texte que j'ai connus ne m'a jamais paru adéquat pour écrire du code. Epoque :
- pré-PC : Prologue, CP/M - MS-DOS dans ces débuts.
Vi. On parlait bien de la même époque. Mais à cette époque, je ne me souviens d'aucun traitement de texte que j'aurais eu l'idée d'utiliser comme éditeur de texte (Apple ][ et MS-DOS).
Lorsque le graphique n'avait pas envahit les écrans, les premiers traitement de textes étaient plutôt simplistes, il était possible en délaissant certaines fonctionnalités d'éditer un source, assemblable ou compilable par la suite.
Mouais. Ben j'ai pas connu. Pourtant, j'y étais... :)
-- Arnaud (Supprimez les geneurs pour me répondre)
Arnaud Meurgues
Jean-Marc Bourguet wrote:
Meme nos tests unitaires sont fait dans le cadre de l'application (du moins au niveau ou je travaille, dans les infrastructures ce n'est pas toujours le cas) parce que justement on depend de tellement d'autres choses -- infrastructure, passes precedantes,... -- que d'ecrire des tests bench sans tout ca serait difficile. On ajoute parfois de l'instrumentation a l'application pour augmenter l'observabilite de l'etat interne et detecter des problemes plus pres de la source.
Ça fait du bien de lire ça. Mais pourquoi diable tout ceci n'est pas enseigné dans la plupart des écoles ? J'ai l'impression que dans les écoles d'info, seul compte le développement au sens pissage de code, et rien n'est dit sur le test (encore moins sur l'observabilité de l'état interne).
-- Arnaud (Supprimez les geneurs pour me répondre)
Jean-Marc Bourguet wrote:
Meme nos tests unitaires sont fait dans le cadre de l'application (du
moins au niveau ou je travaille, dans les infrastructures ce n'est pas
toujours le cas) parce que justement on depend de tellement d'autres
choses -- infrastructure, passes precedantes,... -- que d'ecrire des
tests bench sans tout ca serait difficile. On ajoute parfois de
l'instrumentation a l'application pour augmenter l'observabilite de
l'etat interne et detecter des problemes plus pres de la source.
Ça fait du bien de lire ça. Mais pourquoi diable tout ceci n'est pas
enseigné dans la plupart des écoles ? J'ai l'impression que dans les
écoles d'info, seul compte le développement au sens pissage de code, et
rien n'est dit sur le test (encore moins sur l'observabilité de l'état
interne).
--
Arnaud
(Supprimez les geneurs pour me répondre)
Meme nos tests unitaires sont fait dans le cadre de l'application (du moins au niveau ou je travaille, dans les infrastructures ce n'est pas toujours le cas) parce que justement on depend de tellement d'autres choses -- infrastructure, passes precedantes,... -- que d'ecrire des tests bench sans tout ca serait difficile. On ajoute parfois de l'instrumentation a l'application pour augmenter l'observabilite de l'etat interne et detecter des problemes plus pres de la source.
Ça fait du bien de lire ça. Mais pourquoi diable tout ceci n'est pas enseigné dans la plupart des écoles ? J'ai l'impression que dans les écoles d'info, seul compte le développement au sens pissage de code, et rien n'est dit sur le test (encore moins sur l'observabilité de l'état interne).
-- Arnaud (Supprimez les geneurs pour me répondre)
Richard Delorme
K. Ahausse wrote:
À quelle époque ? Aucun des traitements de texte que j'ai connus ne m'a jamais paru adéquat pour écrire du code.
Epoque : - pré-PC : Prologue, CP/M - MS-DOS dans ces débuts.
Vi. On parlait bien de la même époque. Mais à cette époque, je ne me souviens d'aucun traitement de texte que j'aurais eu l'idée d'utiliser comme éditeur de texte (Apple ][ et MS-DOS).
Il me semble que Wordstar était un traitement de texte couramment utiliser pour éditer du code. La plupart des raccourcis clavier des éditeurs de Borland viennent de lui. Mais je raconte ça de mémoire et je peux me gourrer.
-- Richard
K. Ahausse wrote:
À quelle époque ? Aucun des traitements de texte que j'ai connus ne m'a
jamais paru adéquat pour écrire du code.
Epoque :
- pré-PC : Prologue, CP/M
- MS-DOS dans ces débuts.
Vi. On parlait bien de la même époque. Mais à cette époque, je ne me
souviens d'aucun traitement de texte que j'aurais eu l'idée d'utiliser
comme éditeur de texte (Apple ][ et MS-DOS).
Il me semble que Wordstar était un traitement de texte couramment
utiliser pour éditer du code. La plupart des raccourcis clavier des
éditeurs de Borland viennent de lui. Mais je raconte ça de mémoire et je
peux me gourrer.
À quelle époque ? Aucun des traitements de texte que j'ai connus ne m'a jamais paru adéquat pour écrire du code.
Epoque : - pré-PC : Prologue, CP/M - MS-DOS dans ces débuts.
Vi. On parlait bien de la même époque. Mais à cette époque, je ne me souviens d'aucun traitement de texte que j'aurais eu l'idée d'utiliser comme éditeur de texte (Apple ][ et MS-DOS).
Il me semble que Wordstar était un traitement de texte couramment utiliser pour éditer du code. La plupart des raccourcis clavier des éditeurs de Borland viennent de lui. Mais je raconte ça de mémoire et je peux me gourrer.
-- Richard
K. Ahausse
"Arnaud Meurgues" a écrit dans le message de news:419c923f$0$4387$
K. Ahausse wrote:
À quelle époque ? Aucun des traitements de texte que j'ai connus ne m'a jamais paru adéquat pour écrire du code. Epoque :
- pré-PC : Prologue, CP/M - MS-DOS dans ces débuts.
Vi. On parlait bien de la même époque. Mais à cette époque, je ne me souviens d'aucun traitement de texte que j'aurais eu l'idée d'utiliser comme éditeur de texte (Apple ][ et MS-DOS).
Lorsque le graphique n'avait pas envahit les écrans, les premiers traitement
de textes étaient plutôt simplistes, il était possible en délaissant certaines fonctionnalités d'éditer un source, assemblable ou compilable par
la suite.
Mouais. Ben j'ai pas connu. Pourtant, j'y étais... :)
Ha ? Apparemment, à un moment ou à un autre tu as loupé quelque chose ... :-)
Regardes la réponse de Richard Delorme ... le traitement de texte qu'il cite, est un de ceux le plus utilisé (enfin, restons humble, dans mon giron) de l'époque et présent sur les 3 OS. Je n'utilisais pas d'Apple, donc je ne serais pas affirmatif, mais je ne serais pas étonné qu'il ait eu une version, aussi, pour Apple.
"Arnaud Meurgues" <arnaud@meurgues.non.fr.invalid> a écrit dans le message
de news:419c923f$0$4387$626a14ce@news.free.fr...
K. Ahausse wrote:
À quelle époque ? Aucun des traitements de texte que j'ai connus ne m'a
jamais paru adéquat pour écrire du code.
Epoque :
- pré-PC : Prologue, CP/M
- MS-DOS dans ces débuts.
Vi. On parlait bien de la même époque. Mais à cette époque, je ne me
souviens d'aucun traitement de texte que j'aurais eu l'idée d'utiliser
comme éditeur de texte (Apple ][ et MS-DOS).
Lorsque le graphique n'avait pas envahit les écrans, les premiers
traitement
de textes étaient plutôt simplistes, il était possible en délaissant
certaines fonctionnalités d'éditer un source, assemblable ou compilable
par
la suite.
Mouais. Ben j'ai pas connu. Pourtant, j'y étais... :)
Ha ? Apparemment, à un moment ou à un autre tu as loupé quelque chose ...
:-)
Regardes la réponse de Richard Delorme ... le traitement de texte qu'il
cite, est un de ceux le plus utilisé (enfin, restons humble, dans mon giron)
de l'époque et présent sur les 3 OS.
Je n'utilisais pas d'Apple, donc je ne serais pas affirmatif, mais je ne
serais pas étonné qu'il ait eu une version, aussi, pour Apple.
"Arnaud Meurgues" a écrit dans le message de news:419c923f$0$4387$
K. Ahausse wrote:
À quelle époque ? Aucun des traitements de texte que j'ai connus ne m'a jamais paru adéquat pour écrire du code. Epoque :
- pré-PC : Prologue, CP/M - MS-DOS dans ces débuts.
Vi. On parlait bien de la même époque. Mais à cette époque, je ne me souviens d'aucun traitement de texte que j'aurais eu l'idée d'utiliser comme éditeur de texte (Apple ][ et MS-DOS).
Lorsque le graphique n'avait pas envahit les écrans, les premiers traitement
de textes étaient plutôt simplistes, il était possible en délaissant certaines fonctionnalités d'éditer un source, assemblable ou compilable par
la suite.
Mouais. Ben j'ai pas connu. Pourtant, j'y étais... :)
Ha ? Apparemment, à un moment ou à un autre tu as loupé quelque chose ... :-)
Regardes la réponse de Richard Delorme ... le traitement de texte qu'il cite, est un de ceux le plus utilisé (enfin, restons humble, dans mon giron) de l'époque et présent sur les 3 OS. Je n'utilisais pas d'Apple, donc je ne serais pas affirmatif, mais je ne serais pas étonné qu'il ait eu une version, aussi, pour Apple.
Arnaud Meurgues
Richard Delorme wrote:
Il me semble que Wordstar était un traitement de texte couramment utiliser pour éditer du code.
Ah bon. Ok, ok.
-- Arnaud (Supprimez les geneurs pour me répondre)
Richard Delorme wrote:
Il me semble que Wordstar était un traitement de texte couramment
utiliser pour éditer du code.
Ah bon. Ok, ok.
--
Arnaud
(Supprimez les geneurs pour me répondre)
Il me semble que Wordstar était un traitement de texte couramment utiliser pour éditer du code.
Ah bon. Ok, ok.
-- Arnaud (Supprimez les geneurs pour me répondre)
Arnaud Meurgues
K. Ahausse wrote:
Ha ? Apparemment, à un moment ou à un autre tu as loupé quelque chose ... :-)
Vi. C'est fort possible. J'étais quand même jeune à l'époque.
Regardes la réponse de Richard Delorme ... le traitement de texte qu'il cite, est un de ceux le plus utilisé (enfin, restons humble, dans mon giron) de l'époque et présent sur les 3 OS.
Effectivement. J'ai dû l'avoir mais ne m'en suis pas servi.
Je n'utilisais pas d'Apple, donc je ne serais pas affirmatif, mais je ne serais pas étonné qu'il ait eu une version, aussi, pour Apple.
À vrai dire, je ne me souviens pas de ce que j'utilisais sur Apple. Je crois qu'il y avait un éditeur intégré pour le basic. Je sais que je n'utilisais pas de traitement de texte (wordstar a effectivement été le premier que j'ai vu passer mais il ne m'est pas venu à l'esprit de l'utiliser pour taper du code).
Mais tout ça remonte...
-- Arnaud (Supprimez les geneurs pour me répondre)
K. Ahausse wrote:
Ha ? Apparemment, à un moment ou à un autre tu as loupé quelque chose ...
:-)
Vi. C'est fort possible. J'étais quand même jeune à l'époque.
Regardes la réponse de Richard Delorme ... le traitement de texte qu'il
cite, est un de ceux le plus utilisé (enfin, restons humble, dans mon giron)
de l'époque et présent sur les 3 OS.
Effectivement. J'ai dû l'avoir mais ne m'en suis pas servi.
Je n'utilisais pas d'Apple, donc je ne serais pas affirmatif, mais je ne
serais pas étonné qu'il ait eu une version, aussi, pour Apple.
À vrai dire, je ne me souviens pas de ce que j'utilisais sur Apple. Je
crois qu'il y avait un éditeur intégré pour le basic. Je sais que je
n'utilisais pas de traitement de texte (wordstar a effectivement été le
premier que j'ai vu passer mais il ne m'est pas venu à l'esprit de
l'utiliser pour taper du code).
Mais tout ça remonte...
--
Arnaud
(Supprimez les geneurs pour me répondre)
Ha ? Apparemment, à un moment ou à un autre tu as loupé quelque chose ... :-)
Vi. C'est fort possible. J'étais quand même jeune à l'époque.
Regardes la réponse de Richard Delorme ... le traitement de texte qu'il cite, est un de ceux le plus utilisé (enfin, restons humble, dans mon giron) de l'époque et présent sur les 3 OS.
Effectivement. J'ai dû l'avoir mais ne m'en suis pas servi.
Je n'utilisais pas d'Apple, donc je ne serais pas affirmatif, mais je ne serais pas étonné qu'il ait eu une version, aussi, pour Apple.
À vrai dire, je ne me souviens pas de ce que j'utilisais sur Apple. Je crois qu'il y avait un éditeur intégré pour le basic. Je sais que je n'utilisais pas de traitement de texte (wordstar a effectivement été le premier que j'ai vu passer mais il ne m'est pas venu à l'esprit de l'utiliser pour taper du code).
Mais tout ça remonte...
-- Arnaud (Supprimez les geneurs pour me répondre)
drkm
Marc Boyer writes:
In article , drkm wrote:
Marc Boyer writes:
Oui, j'essaye de tout mettre dans un .cpp que le .hpp inclut. C'est plus lisible, je retrouve plus vite mes petits, tout ça.
Je suppose que tu parles d'un en-tête .hh, une implémentation des éléments non-template .cc, et une implémentation des templates .tcc.
Non, actuellement, ce sont des .hpp et des .cpp, mais bon, un petit find des familles pourra bouger tout ça...
« find des familles » ?
Ce que je veux dire, c'est qu'il faut veiller à ne pas inclure les élements non template. Ou l'éditeur de lien te le rappellera.
--drkm
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
In article <wk3bz85fwa.fsf@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Oui, j'essaye de tout mettre dans un .cpp que le .hpp inclut.
C'est plus lisible, je retrouve plus vite mes petits, tout ça.
Je suppose que tu parles d'un en-tête .hh, une implémentation des
éléments non-template .cc, et une implémentation des templates .tcc.
Non, actuellement, ce sont des .hpp et des .cpp, mais bon, un
petit find des familles pourra bouger tout ça...
« find des familles » ?
Ce que je veux dire, c'est qu'il faut veiller à ne pas inclure les
élements non template. Ou l'éditeur de lien te le rappellera.
