Newsgroup: it.comp.lang.c++
Titolo: Perché definire costanti pubbliche all'interno di una classe?

Ho trovato una classe che contiene al suo interno la dichiarazione di 
costanti pubbliche, come potete vedere sotto. A me non sembra una buona 
idea, avrei definito CmpRes fuori dalla classe. Voi cosa ne dite?
Oppure c'è un motivo preciso per fare ciò che io non conosco?
 
 
#include "NumberlikeArray.hh"
 
class BigUnsigned : protected NumberlikeArray<unsigned long> {
 
public:
	enum CmpRes { less = -1, equal = 0, greater = 1 };
 
protected:
 
	// ecc. ecc...

 	// ecc. ecc...
 
Io lo trovo non solo giusto, ma anche abbastanza comune: se l'enum è usato solo nella (per la) classe è logico che stia all'interno (sia anche solo per non riempire lo spazio dei nomi).
Ciao!


Information hiding / Incapsulamento / Evitare di arricchire inutilmente 
il namespace globale.
 
Maurus
 
 

 Ciao!
 
Già... se uno ha bisogno di quel tipo nella classe e lo definisce nel 
file .c invece che nell'header, poi non potrebbe più dichiarare la 
classe :-)

 classe :-)
 
Yup, ma faccio una considerazione più profonda.
Al contrario di altri linugaggi (tipo ada) non è possibile in C (da cui il C++ deriva) definire un tipo nativo che abbia un range ristretto di valori (mettiamo, da 0 a 26, ma anche da 2 a 5, 3 escluso) _eccetto_ per gli enum. Sono molti i casi in cui questo però è necessario per rafforzare i controlli di tipo sulle chiamate a funzione in maniera che il compilatore si prenda carico di check che altrimenti occorrerebbe fare a runtime (esempio banale: una funzione prende come parametro un mese, da 0 a 11 compresi, ma il processore mi permette al minimo di passare un uchar (0/255) o un int (-??/??); perché devo far controllare alla funzione se il numero va da 0 a 11 quando posso dire al compilatore che la funzione accetta solo quel range?).
Gli enum quindi "sarebbero da usare" in tutti i quei casi in cui il valore passato è differente dal massimo consentito dagli int (a cui gli enum decadono al cast, mi si perdoni la frase al limite della correttezza, spero si capisca).
Facendo un passo avanti, a questo punto in C++ entra il concetto di incapsulamento: così come se una classe o una struttura è usata _solo_ in una classe la definisco internamente e privata, così faro con un enumeratore. Volevo fare qualche esempio ma sono così banali che me ne sono vergonato dall'ovvietà di quello che mi veniva in mente. Forse, per i programmatori C++ risulta facile quest'altro ragionamento: gli enum sono allo stessa stregua di strutture e classi; quando l'enum, se fosse una classe, la mettereste come membro privato ecco, allora anche l'enum. :)
Prolisso come al solito, spero di non aver annoiato nessuno ;)
Ciao!

 quando l'enum, se fosse una classe, la mettereste come membro privato ecco, allora anche l'enum. :)
 
Certe volte ho la netta impressione che il C e il C++ facciano a 
cazzotti. Non a livello di sintassi (per quanto...) ma proprio perché 
per esempio il C++ accetterebbe volentieri dei tipi ranged come in ADA e 
pascal, a livello di filosofia, mentre il C li rifiuta proprio per 
filosofia.


Questa non l'ho capita... perché? Non è che ci sia tutta questa differenza tra enumeratori in C e in C++ :-|
Ciao!

 Questa non l&#39;ho capita... perché? Non è che ci sia tutta questa differenza tra enumeratori in C e in C++ :-|
 
Se non sbaglio una differenza c'e': il c++ e' piu' rigido e controlla
che vengano usati solo elementi dell'enum, mentre il c e' piu'
di bocca buona e ti lascia usare anche degli interi. Una roba del genere:
 
#include <stdio.h>
 
typedef enum { a=1, b=2, c=4 } valore;
 
void f( valore v ) {...}
...
f( a );
f( b );
f( c );
f( 3 ); // qui per c++ e' un errore, in c invece no.
 
Questa differenza e' proprio filosofica: in c gli enum sono
solo un modo pratico per rappresentare dei numeri interi 
mentre in c++ sono proprio un "tipo" a parte.
 
ciao
Giacomo

 Giacomo
 
Sì, infatti è l'unica differenza. Magari non è poco, in effetti :)
Ciao!


uhm ... forse mi sbaglio io, ma pensavo che "ranged" 
significasse : i cui valori ammissibili cadono in un certo 
intervallo.
Una enum non mi pare strettamente ranged, perché non è 
necessariamente un set compatto, ma ha anche un numero 
arbitrario di buchi (valori illegali). Quindi non credo sarà 
mai possibile risolvere con una mera strategia di 
impaccamento di bit o cmq con due controlli in croce (V>=min 
&& V<=max), ma (fortunatamente a design time) ci vorrà 
sempre un esteso controllo "stile lista". Ossia se una enum 
ammette 50 valori, saranno necessari 50 controlli per compilare.
Poi per quanto capisco la questione di diversa filosofia, 
anche io non so se ci sia alcuna differenza concreta 
nell'implementazione delle enum in C o C++.
Sono memorizzati come integral (non so se in una word di 
macchina o anche meno ... in .NET si può scegliere 
l'ampiezza di tale word, byte, short, int, long, pur 
restando negli integral). Ma il punto è che mi sembra non 
esistano scappatoie ad una scansione sistematica di tutti i 
valori contro la lista di ammissibili, proprio per la non 
compattezza di questi integral a macchia di leopardo.
ciao
CCCP
 
 
-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
 

 Ciao!
 
 


 Al contrario di altri linugaggi (tipo ada) non � possibile in C (da cui il C++ deriva) definire un tipo nativo che abbia un range ristretto di valori (mettiamo, da 0 a 26, ma anche da 2 a 5, 3 escluso) _eccetto_ per gli enum. Sono molti i casi in cui questo per� � necessario per rafforzare i controlli di tipo sulle chiamate a funzione in maniera che il compilatore si prenda carico di check che altrimenti occorrerebbe fare a runtime (esempio banale: una funzione prende come parametro un mese, da 0 a 11 compresi, ma il processore mi permette al minimo di passare un uchar (0/255) o un int (-??/??); perch� devo far controllare alla funzione se il numero va da 0 a 11 quando posso dire al compilatore che la funzione accetta solo quel range?).
 
Probabilmente nella prossima release del C++, che dovrebbe avvenire 
verso il 2020 vedremo alcune cose di ada ed eiffel
Queste sono:
Definizione di nuovi tipi a partire dai tipi semplici, quello che in ada 
� il costrutto new type, da non confondere con typedef il quale � solo 
un alias di un tipo
Definizione di subtype, il caso di cui tu accenni
E, per finire l' introduzione dei contratti sui metodi; questo � preso 
da eiffel ed � stato introdotto anche  in ada 2012
Il design  by contract il comitato voleva introdurlo gi� in C++11, ma 
non se ne fatto nulla.
 

 CCCP
 
Non e' esattamente quello il problema. Il fatto e' che la *grammatica*
di C++ e' un incubo da riconoscere.
 
-- 
-riko
http://www.enrico-franchi.org/
 
http://rik0-techtemple.blogspot.com/
 

_eccetto_ per gli enum.
 
la tua considerazione � sbagliata, ho fatto un tipo che, se raggiunto dai
suoi operatori si comporta in modo plausibile come se ci fosse un range...
 
#include <iostream.h>
#define  ooo  cout
#define  R    return
 
class tipo245{
public:
tipo245(){j=2;}
tipo245(int  k)
    {j=k%6;
     if(j==0||j==1||j==3)
       {ooo<<"Errore di inizializzazione\n";
        exit(1);
       }
    }
tipo245  operator++(){++j;
                      if(j== 6)  j=2;
                      if(j== 3)  ++j;
                      R *this;
                     }
tipo245  operator--(){--j;
                      if(j==1)  j=5;
                      if(j== 3)  --j;
                      R *this;
                     }
friend ostream&  operator<<(ostream&  o, tipo245  b)
{o<<b.j; R  o;}
 
int   j;
};
 
int main(void)
{tipo245  a, b(5), c(4);
 ooo<<"a, b, c=" <<a<<", " <<b<<", " <<c<<"\n";
 --a; ++b; --c;
 ooo<<"--a, ++b, --c=" <<a<<", " <<b<<", " <<c<<"\n";
 R 0;
}
 
 
 
 

 
 
Questo però Dio mio è insensato.
 
Ciao!

 ha scritto nel messaggio 
news:b9f94885-fb05-4e2d...@googlegroups.com...

#meglio insensato, che come te... 
 
 


 
Ciao! Felice di rileggerti dopo tanto tempo :)
Non farci caso, ignora questo io_x, ormai � un noto troll che si
diverte da anni a sporcare usenet, specialmente i gruppi sul C/Assembly.
I suoi programmi non devono essere piaciuti a qualcuno e se non lo
evitiamo tutti dovremo portarcelo dietro per ancora un bel po'.
 
 
-- 
Vincenzo Mercuri

 
 
Carissimo! Chi si risente! ;)
Sì, il personaggio lo conosco dai suoi post su c.l.c, ma quando qualcuno ha ragione bisogna dirlo, per cui ho risposto. :-)
Allo stesso tempo, visto che c'ero, non ho potuto trattenermi dall'esprimere un parere sulle due #define :D
Ciao!


 
Grande :) dai speriamo di riportare in vita i.c.l.c che lo vedo un po' 
spento. A presto.
 
 
-- 
Vincenzo Mercuri

 
"io_x" <a...@b.c.invalid> ha scritto nel messaggio
news:501fde4f$0$17945$4faf...@reader1.news.tin.it...

nel senso: meglio insensato che insultante...