je pensais que dans ce cadre, l un etait l equivalent exact de l autre ?
Cf <news: et <http://www.gotw.ca/gotw/001.htm>.
James Kanze
Fabien LE LEZ wrote:
On 10 Jan 2007 00:15:13 -0800, "James Kanze" :
Et ni l'un ni l'autre ne doit marcher. Mais dans la passée, certaines implémentations des iostream supportaient bien l'affectation et la copie.
Note qu'ici, on ne parle pas forcément de std::ostream. Logiquement (et avec un compilo raisonnablement récent), rien ne m'empêche de définir ma propre classe "ostream" dans le namespace global, avec les propriétés qui m'arrangent.
Même pas le bon sens ? Sachant que le lecteur qui voit ostream va automatiquement supposer std::ostream ? Ou que certains vont faire un « using namespace std », et du coup il aurait plein des appels ambigus ?
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 10 Jan 2007 00:15:13 -0800, "James Kanze" <james.kanze@gmail.com>:
Et ni l'un ni l'autre ne doit marcher. Mais dans la passée,
certaines implémentations des iostream supportaient bien
l'affectation et la copie.
Note qu'ici, on ne parle pas forcément de std::ostream.
Logiquement (et avec un compilo raisonnablement récent), rien ne
m'empêche de définir ma propre classe "ostream" dans le namespace
global, avec les propriétés qui m'arrangent.
Même pas le bon sens ? Sachant que le lecteur qui voit ostream
va automatiquement supposer std::ostream ? Ou que certains vont
faire un « using namespace std », et du coup il aurait plein
des appels ambigus ?
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Et ni l'un ni l'autre ne doit marcher. Mais dans la passée, certaines implémentations des iostream supportaient bien l'affectation et la copie.
Note qu'ici, on ne parle pas forcément de std::ostream. Logiquement (et avec un compilo raisonnablement récent), rien ne m'empêche de définir ma propre classe "ostream" dans le namespace global, avec les propriétés qui m'arrangent.
Même pas le bon sens ? Sachant que le lecteur qui voit ostream va automatiquement supposer std::ostream ? Ou que certains vont faire un « using namespace std », et du coup il aurait plein des appels ambigus ?
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ
On 11 Jan 2007 06:47:40 -0800, "James Kanze" :
Note qu'ici, on ne parle pas forcément de std::ostream. Logiquement (et avec un compilo raisonnablement récent), rien ne m'empêche de définir ma propre classe "ostream" dans le namespace global, avec les propriétés qui m'arrangent.
Même pas le bon sens ?
Je ne le ferais bien sûr pas dans un code de production. Mais dans une discussion théorique sur fclc++, c'est acceptable.
On 11 Jan 2007 06:47:40 -0800, "James Kanze" <james.kanze@gmail.com>:
Note qu'ici, on ne parle pas forcément de std::ostream.
Logiquement (et avec un compilo raisonnablement récent), rien ne
m'empêche de définir ma propre classe "ostream" dans le namespace
global, avec les propriétés qui m'arrangent.
Même pas le bon sens ?
Je ne le ferais bien sûr pas dans un code de production.
Mais dans une discussion théorique sur fclc++, c'est acceptable.
Note qu'ici, on ne parle pas forcément de std::ostream. Logiquement (et avec un compilo raisonnablement récent), rien ne m'empêche de définir ma propre classe "ostream" dans le namespace global, avec les propriétés qui m'arrangent.
Même pas le bon sens ?
Je ne le ferais bien sûr pas dans un code de production. Mais dans une discussion théorique sur fclc++, c'est acceptable.
