Newsgroup: it.comp.lang.c++
Titolo: namespace & template

 &)' being compiled
cioe' ho un errore quando compilo l'operator >> su page (sistetico per "
touch::socket_stream &operator >> (touch::socket_stream &s, page &m)" )
questa funzione usa il template operator >> su vector che e' definita nel
namespace touch la quale va a usare (o almeno nelle mie intenzioni dovrebbe)
l'operator >> su identifier * definito nel namespace lg_parser, ma non lo
trova perche' vede solo gli operator >> definiti nel namespace touch.
la domanda e' (anzi sono):
1. e' un comportamento corretto (quello del visualc 6) o no?
2. se lo e', come si risolve la situazione? cioe' se i template risolvono i
nomi solo nel namespace in cui sono definiti, come e' possibile estendere un
operatore in + namespace?
grazie a tutti (spero di essere stato chiaro... anche se ne dubito)
bye
Touch

 operatore in + namespace?
Non ho verificato bene il codice, ma posso dirti questo: il VC non
supporta del tutto il Koenig lookup. Questo dovrebbe essere il tuo
problema. E se è così la risposta alla domanda 1 è NO. La risposta alla
domanda 2 è che di solito la cosa si risolve, anche in mancanza di
Koenig lookup introducendo delle direttive di using (il che diventa un
problema se hai tipi diversi definiti in namespace diversi ma aventi lo
stesso nome non qualificato) oppure specificando (più precisamente
qualificando) tutti gli operatori e le chiamate a funzione.
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 qualificando) tutti gli operatori e le chiamate a funzione.
il problema in questo caso e' che il namespace touch non sa niente del
namespace lg_parser
(ie. touch e' una libreria general purpose usata qua e la', mentre lg_parser
e' un'applicazione:
non posso mica mettere in touch degli using che riferiscono lg_parser...
sarebbe a dire che ogni volta che uso touch in una nuova libreria mi tocca
mettere mano alle sue sorgenti)
quello che mi sfugge (oltre al koenig lookup ^___^;) e': lo standard
qual'e'?
bye
Touch

 ha scritto nel messaggio
news:9stbs8$484o$1...@stargate1.inet.it...


 qual'e'?
quello pubblicato dall'ISO come C++ International Standard

> Non  puoi definire gli operatori fuori dai namespace?
potrebbe anche farsi. mi chiedo dunque: uno che sviluppa una libreria che
sara' poi usata da tanta altra gente, deve lasciar fuori dall'eventuale
namespace che raccoglie i simboli della libreria stessa, l'overloading degli
operatori?
(e in std:: le cose come stanno?)

 qual'e'?
Lo standard č che il koenig lookup deve funzionare, ovviamente.


 qual'e'?
Dicesi koenig lookup : (dicesi e' molto fantozziano :-) )
- Un piatto regiornale abruzzese[1]
- La regola secondo la quale puoi non specificare il namespace della 
funzione se uno dei suoi parametri e' definito nel namespace della funzione 
stessa.
Esempio :
namespace WipeoutFusion
{
	class DadoRulez{};
	int Paripampum( const DadoRulez& eccomi_qua) { return eccomi_qua*2; }
}
WipeoutFusion::DadoRulez ma_chi_lo_sa;
...
Paripampum( ma_chi_lo_sa ); [2]
In questo caso il lookup "looka" proprio a WipeoutFusion::Paripampum(), 
perche' uno degli argomenti della funzione e' dichiarato nello stesso 
namespace.
[1] Per i puristi fantozziani la domanda era : 
"Che cos'e' la punzonatura?", chiesta da Cobram, l' appassionato di 
ciclismo, a Fantozzi.
[2] Lo sanno babbo mamma e toshio...
btw: non l' ho compilato :-) e la seconda parte della tua domanda non l' ho 
capita bene, c'e' solo uno standard del C++, scaricabile per il modico 
prezzo di 18 dollarones... (Non ho il link, ma qualcun altro lo postera' 
sicuramente, e poi adesso mi si e' anche crashato explorer :-) )
-- 
FUSION (fyu zh & n) n: 
1) the Act or Process of Fusing or Melting Together... 
2) the State of being Fused... 
3) to Join or become Combined...

 "separation of concern", vi ricordate come si chiama? io no...
Nessuna quastione di design, è una "semplice" questione di compilatore
non conforme.


 wrote in message
news:9su2o1$1fvk$1...@stargate1.inet.it...

Vedi mio altro post. In teoria non č cosě. Ma se il compilatore non
supporta koenig ...


 non conforme.
d'accordo sul koenig e i template, ma Simone Pierazzini dice 
   "non posso mica mettere in touch degli using che riferiscono 
    lg_parser... sarebbe a dire che ogni volta che uso touch in una 
    nuova libreria mi tocca mettere mano alle sue sorgenti"
se questi riferimenti ricorrono spesso, vuol dire che le cose sono 
abbastanza interdipendenti da dover avere riferimenti espliciti
Tornando al koenig lookup per i template, la tecnica di riaprire il 
namespace e aggiungere l'operatore come dovrebbe comportarsi nel 
seguente caso?
namespace A {
 template <typename T>
 class mystream{
  /* qui ci sono i miei operatori << e >>
 };
};
/* altro file */
namespace B {
 class classe {...};
};
namespace A {
 template <B::classe>
 mystream<T>& operator<<(mystream& s, const classe& C) {...};
};
essendo B nello stesso scope padre di A, dovrebbe risolverlo, giusto?

  mystream<T>& operator<<(mystream& s, const classe& C) {...};
sostituire la riga con 
mystream<classe>& operator<<(mystream<classe>& s, const classe& C) 
{...};

 supporta koenig ...
infatti: ho compilato con gcc e non ho avuto problemi! dunque e' una non
conformita' del vc...
tra l'altro: per rispondere anche ad aloha: il namespace touch NON dipende
da lg_parser... (e' corretta infatti la risposta che ti ha dato Ferro, thx!)
comunque la cosa e' frustrante: avevo evitato di usare i namespace finora
non fidandomi dei compilatori... e avevo ragione!! mi chiedo quanti anni
dovremo aspettare prima di avere un supporto stabile per il C++ standard
bye & grazie di nuovo
Touch