Newsgroup: it.comp.lang.c++
Titolo: [REQ]Passare una enum come parametro a un metodo

Ciao a tutti,
non riesco a passare ad un metodo una enum, ovvero, non riesco a
capire quale sia
la forma corretta. Ho cercato su google, sui manuali, ma non trovo
nulla che spiaghi
esattamente come fare... vi illustro il codice sperando possiate
aiutarmi, devo passare
al costuttore un parametro enum (left, right,up,down), ma ho provato
in tutti i modi,
con typedef,etc...ho messo XXX dove il compilatore mi segnala
l'errore, al posto di XXX
ho provato a mettere direction_type, Nodo::direction_type, enum, enum
direction_type...ma nulla:
class Nodo{
public:
  Nodo(int,int, XXX)
private:
   enum {left,right,up,down} direction_type;
   direction_type direction;
}
Nodo::Nodo(int x,int y, XXX)

 
class Nodo {
     typedef enum {left,right,up,down} direction_type;
     direction_type direction;
public:
     Nodo(int, int, direction_type);
};
Nodo::Nodo(int, int, direction_type) {}
int main()
{
     Nodo n(1, 2, Nodo::left);		// !
}
Kiuhnm

   enum {left,right,up,down} direction_type;
l'enum va dichirata in questo modo:
enum direction_type {left,right,up,down};
E al posto di XXX metti direction_type;
Infatti in tal modo stai definendo un nuovo *tipo* (direction_type)
se invece usi la sintassi da te scritta stai dichiarando un *identificatore* 
(direction_type) di tipo enum.
In pratica nel secondo caso definisci il tipo per direction_type e puoi 
usare solo tale identificatore, mentre nel primo caso hai definito un nuovo 
tipo mediante il quale puoi definire altri identificatori di quel tipo.
Ciao 

 Kiuhnm
Non compila, l'enum deve essere public. Inoltre mi sembra più
comprensibile scrivere l'enum così:
enum direction_type {left,right,up,down};
Gianni

 Kiuhnm
Grazie,
ma non capisco come mai la definizione della enum
vada adirittura fuori dalla parte "public"...
Blob

 vada adirittura fuori dalla parte "public"...
Se vuoi metterla in public puoi farlo. 

 Non compila, l'enum deve essere public.
Il commento cosa credi che l'abbia messo a fare?
L'idea era che il nostro amico ci arrivasse da solo.
Kiuhnm

 enum direction_type {left,right,up,down};
Interessante: nel mio progetto ho usato entrambe le forme con una 
leggera preferenza verso quello senza typedef.
Kiuhnm

 leggera preferenza verso quello senza typedef.
quella
Kiuhnm


Tanti anni fa ho letto un fortune, di cui non trovo al momento un
riferimento, che diceva piu' o meno cosi': "L'auto di Steve Johnson
(*) ha come unica spia sul cruscotto un singolo, grosso punto
esclamativo rosso. Un buon guidatore, secondo Steve, sa che cosa non
va."
Ciao,
Nicola
(*) 
http://en.wikipedia.org/wiki/Stephen_C._Johnson

 va."
Se poi non basta, c'č il compilatore!
Kiuhnm

 Se poi non basta, c'è il compilatore!
Il fortune di cui sopra si riferiva proprio alla diagnostica del
Portable C Compiler, notoriamente stringatissima.
Ciao,
Nicola

 Portable C Compiler, notoriamente stringatissima.
Su dei sorgenti che sto convertendo da visualc di recente ho dovuto fare 
molte modifiche perche' il gcc non accetta le seguenti sintassi ridondanti:
class A {
public:
   enum C {qui, quo, qua};
   void A::func(); // errore su GCC, ok su VC
};
int main()
{
	int a = A::C::qui; // Errore su GCC, ok su VC
}

 ridondanti:
Non mi sembrano sintassi contemplate dallo Standard.
Secondo me le accetta solo VC.
Max

  }
Sono entrambe nonstandard extension di VC. Nel compilatore c'e' un
flag per disabilitarle, e anche VC ti dara' un errore =)
--*PaN!*
 
-- 
I'm using an evaluation license of nemo since 40 days.
You should really try it!
http://www.malcom-mac.com/nemo

 Portable C Compiler, notoriamente stringatissima.
BTW, hai visto che sta ritornando in auge (forse perchč una buona parte
della comunitą si sta preoccupando per la deriva estremista di fsf con
GPL 3).
La domanda legata č: idea di un buon compilatore C++ relativamente
portabile per sostituire g++?
Ho dato un occhio al Comeau e devo dire che ha condizioni di licenza
abbastanza peculiari. Tipo io per portatile, fisso + un paio di OS
emulati mi dovrei prendere 4 licenze [ e il timore per il futuro del gcc
non č sufficiente ]. Ah, se poi facessi sviluppare qualcuno sul fisso,
nuove licenze. Sigh.
Microsoft e Borland hanno solo Windows, Intel costa una barca (anche se
li vale tutti... solo per fare uno static verifier per buffer overflows
io ci ho lavorato un anno, li lo avrei built-in, e scommetto che
funziona pure meglio del mio :( ). Beh, insomma, anche qui diciamo 500
euro di licenza sono, per motivi di 'paranoia', eccessivi. Dovrei
trovare qualcuno che si fa sviluppare dal sottoscritto un'applicazione
computazionalmente intensiva e fargli pagare la licenza, sigh, peccato
che faccio altro.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 nuove licenze. Sigh.
E' anche vero che per quattro licenze spenderesti *solo* 200 dollari...
Ciao,
Nicola
-- 
Nicola.Musatti <at> gmail <dot> com
Home: 
http://nicola.musatti.googlepages.com/home
Blog: 
http://wthwdik.wordpress.com/

 E' anche vero che per quattro licenze spenderesti *solo* 200 dollari...
Si. Questo è vero, non è che non me lo potrei permettere. Ammesso che
abbiano supporto per OS X, chiaramente. Diciamo che il gcc mi ha
abituato bene.
Inoltre non ho idea di come ragionerebbero librerie compilate con i due
compilatori diversi. Nel senso che per dire l'Intel garantisce ABI
compatibile con gcc.


 abituato bene.
In effetti il fatto che si appoggi ad una toolchain C pre-esistente mi 
lascia un po' perplesso rispetto al suo uso in un ambiente di 
produzione, specie su sistemi comuni. Forse nel mondo embedded e' diverso...
