Newsgroup: it.comp.lang.c++
Titolo: problemi con bitset

Potreste dirmi qual'č l'errore che non mi fa compilare questo file?
#include <iostream>
#include <string>
#include <bitset>
string s ("0000000000000000");
bitset <32> bitvec (s, 2, 1);    <--- ma questa instruzione comincia ad 
accendere bit da destra? (i meno significativi?) 
int main () {
        std::cout << bitvec.to_string() << std::endl;
        return 0;
}
quando scrivo bitset <32> bitvec (s, 2, 1)  il valore tra < e > deve essere 
uguale al numero di caratteri di s?
Grazie
--
Luigi

 uguale al numero di caratteri di s?
No, come puoi dedurre da quanto sopra.
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

Allora perché non compila?
Puoi dirmi dov'č l'errore?
Ciao
-- 
Posted from 
smtp1.libero.it
 [193.70.192.51] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Ciao
Non ti compila per vari motivi.
La prima parte (le dichiarazioni) perche' manca lo std::
La seconda parte (la chiamata a to_string) perche' non gli hai specificato che
tipo di stringa deve creare.
Questo dovrebbe compilare:
#include <iostream>
#include <string>
#include <bitset>
std::string s ("0000000000000000");
std::bitset<32> b(s, 2, 1);
int main () {
 std::cout
  << b.template to_string<char,std::char_traits<char>,std::allocator<char> >()
  << std::endl;
}
--



Mi chiedo come mai non sia possibile scrivere semplicemente:
    b.template to_string<char>()
visto che gli altri argomenti hanno dei valori di default.
Saluti   Manlio Perillo

 wrote in message
news:i7YC6.12710$lu5.3...@news1.tin.it...

Se nella tua implementazione hanno valori di default allora puoi farlo (salvo
problemi di portabilità su una implementazione che non li ha). Ma nello standard
non e' richiesto che abbiano dei valori di default.



Strano.
Nell'ultimo draft dello Standard è riportato:
// 21.3, basic_string:
template<class charT, class traits = char_traits<charT>,
        class Allocator = allocator<charT> >
class basic_string;
Manlio Perillo

 class basic_string;
Quello e' per l'istanziazione della stringa! Ma il membro to_string del bitset
e' un'altra cosa. Puoi benissimo istanziare una stringa specificando solo il
charT. Ma non puoi istanziare (o se preferisci specializzare)
bitset<int>::to_string, che e' una templated member function specificando solo
charT perche' in quel template i default non ci sono.
Prova a guardare in 23.3.5 [lib.template.bitset]



Saluti Manlio Perillo


No. E' parte dello standard: 14.1 sub 9



A questo punto la domanda sorge spontanea.
Perchè quelli del comitato non hanno inserito dei
parametri di default?
Sempre in tema di template, qualcuno sa perchè non sono ammesse
variabili membro template di tipo puntatore:
class foo
{
    template<class T> T* p;
    // ...
};
Non riesco ad immaginare le problematiche che potrebbe portare.
Saluti  Manlio Perillo

 Non riesco ad immaginare le problematiche che potrebbe portare.
Perche' si possono definire solo template di classi e di funzioni.
Ciao,
Nicola

 };
Aggiungerei che quanto sopra e' equivalente a:
template <typename T> class foo {
  T * p;
};
Che e' perfettamente valido.
Ciao,
Nicola

 Non riesco ad immaginare le problematiche che potrebbe portare.
Io non riesco a immaginare che tipo di costrutto sarebbe in pratica.
Se l'idea č quella che la stessa classe foo possa contenere piů membri
p<T>, allora le problematiche che questo comporterebbe sono chiare, dato
che la dimensione di foo dipenderebbe dal numero di diverse instanziazioni
di p<T> che vengono richieste.
Max

 Perche' si possono definire solo template di classi e di funzioni.
Infatti. E in piu' l'esempio di Manlio non ha senso! Nel suo esempio esiste una
ed una sola classe foo. Quali e quanti membri di nome "p" dovrebbero essere
generati? Non e' chiaro. La soluzione a quello che lui voleva fare, come tu hai
detto in un altro post, e' rendere template tutta la classe.
--


 > > parametri di default?
                                                     ^
concordo su tutto, salvo che ho interpretato questo "dei" come riferito
al caso specifico della funzione membro del bitset.
Ciao,
Nicola

 wrote in message
news:3ADEE085...@divalsim.it...

Infatti tu avevi capito bene quello che aveva scritto. Ma non sempre quello che
scriviamo corrisponde a quello che vogliamo scrivere.
I wnat a keyboard that enters what I'm entering, not what I'm typing.


 I wnat a keyboard that enters what I'm entering, not what I'm typing.
     ^
I see what you mean :-)
Io vorrei un window manager che desse il focus alla finestra che sto
guardando...
Ciao,
Nicola


Veramente sono io ad aver capito male Andrea.
Manlio Perillo

 guardando...
Mi sembra proprio che esista tra gli ausili ai disabili.
EMG



Che basta*do 8)
Luc.

 Che basta*do 8)
No, non credo che Enrico lo intendesse come cattiveria, e' sempre molto
cortese.
Spero, almeno... :-)
Ciao,
Nicola

 Che basta*do 8)
No, no, non stavo scherzando. Ricordo perfettamente di aver visto una
cosa del genere diversi anni fa.
EMG

 Spero, almeno... :-)
Infatti.
EMG

 wrote in message
news:3ADEEE5D...@divalsim.it...

Allora sei messo meglio di me. Per quanto costosa la tua idea di progetto e'
realizzabile.


 Veramente sono io ad aver capito male Andrea.
Niente di grave. Dopotutto una domanda simile l'aveva posta in un altro thread
il nostro olimpionico amico di Genova!


};
vuoi forse dire che il costrutto di Manlio č legale? Sarei molto
sorpreso. E poi secondo me non sono logicamente la stessa cosa:
infatti nella scrittura di Manlio secondo me ci si potrebbe aspettarsi
di fare una cosa del genere:
foo f;
f.p<int>;
che č simile a quello che succede con le funzioni membro template
Anto
--
Antonio Cuni, 18 anni, studente
Brainbench Certification: 
Master C++: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688

il nostro olimpionico amico di Genova!
visto che sono stato tirato in ballo, ne approffitto per salutarvi
tutti e annunciarvi che sono tornato a tediarvi con le mie idiozie...
che adesso diventeranno ancora maggiori dopo essermi fuso il cervello
10 ore al giorni per 5 giorni... :-)


 che č simile a quello che succede con le funzioni membro template
Non legale. Prova a pensarci e ti renderai conto che non sarebbe neppure
implementabile una cosa del genere. Cosa sarebbe sizeof(f) ovvero sizeof(foo) se
fosse legale ? Una classe deve avere una dimensione definita. Sono ammessi i
template member solo come funzioni *non virtual* proprio perche' oltra a dover
essere staticamente definita la size della classe deve esserlo anche la "size"
della v-table.
Se ti serve una classe foo in cui tutto e' prefissato tranne che il tipo del
membro dati "p" devi fare come suggerito: rendere l'intera classe un template.
--


Non legale. Prova a pensarci e ti renderai conto che non sarebbe neppure
si, infatti il mio post aveva un tono esplicitamente interrogativo,
causato dal fatto che avevo mal interpretato il messaggio di Nicola  


 fosse legale ? Una classe deve avere una dimensione definita.
Giusto, ma è per questo che p può solo essere un puntatore.
Non vorrei prendere un grosso abbaglio, ma non è vero che
sizeof(T*) == sizeof(U*) per ogni T ed U?
L'unico problema che vedo è come allocare una istanza di una
tale classe sullo stack, dato che non è noto a compile-time
quanti puntatori ci sono (e quindi la dimensione 'fisica').
Saluti
Manlio Perillo

 sizeof(T*) == sizeof(U*) per ogni T ed U?
no, per quel che ne so!
c'era un esempio poco tempo fa su _non ricordo che ng_ di un s.o. dove
il char * ha dimensioni diverse rispetto agli altri puntatori.

il char * ha dimensioni diverse rispetto agli altri puntatori.
mi sembra alquanto strano; non conosco la programmazione a basso
livello, ma almeno sugli i386 non vedo come possano essere di
dimensioni diverse. Che poi il fatto che i puntatori abbiano tutti la
stessa dimensione sia garantito dallo standard è un altro discorso...
Anto
--
Antonio Cuni, 19 anni, studente


 stessa dimensione sia garantito dallo standard è un altro discorso...
Piu' esattamente, il C++ mutua per queste cose i constraints dal C.
Il quale C richiede che:
1) un pointer ad un oggetto puo' essere sempre convertito in un
   pointer ad un oggetto differente, e da qui riconvertito in un
   pointer al tipo originale in modo da riottenere lo stesso valore
   (6.3.2.3.7 - e questo implica che tutti i puntatori ad oggetti
   hanno la stessa dimensione); e che
2) tutti i puntatori a funzione godano della stessa proprieta'
   (6.3.2.3.8 - stessa conclusione).
Pero' un puntatore ad un oggetto puo' essere rappresentato
differentemente da un puntatore a funzione; ed infine un null pointer
ad un oggetto e/o a funzione puo' essere rappresentato in modo ancora
differente da questi.
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it
The instructions said to use Windows 98 or better - so I installed FreeBSD.

    hanno la stessa dimensione); e che
Giusto per spaccare il capello in quattro, non sono sicuro che la
reversibilita' della convertibilita' implichi la stessa dimensione; di
certo implica che il numero di bit compreso nella rappresentazione sia
lo stesso, ma questi non potrebbero essere disposti in modo diverso?
Ciao,
Nicola

 stessa dimensione sia garantito dallo standard è un altro
discorso...
Allora neanche tu ci credi fino in fondo che sizeof( U *) == sizeof( V
*) per ogni U e V! :-)

 differente da questi.
resto convinto della mia posizione finchè non vedo "un pointer avrà le
stesse dimensioni per ogni tipo" scritto da qualche parte sullo
standard :-).

 informazioni, ovvero implica soltanto quello che dice e niente di più!
Per essere esatti, supponendo per assrdo che il numero di bits che
portano informazioni significative sia differente tra i vari tipi si
puo' provare che non l'ipotesi non puo' essere soddisfatta.  Pero' la
struttura puo' effettivamente essere differente; correggi la mia
affermazione in: "questo implica che tutti i puntatori ad oggetti
contengono un sottoinsieme di bits il cui contenuto di informazione e'
sufficiente ad identificare univocamente un indirizzo di memoria e la
cui dimensione e' uguale indipendentemente dal tipo dell'oggetto
puntato".  Soddisfatto?


*) per ogni U e V! :-)
detto proprio sinceramente, non mi sembra cmq una cosa così
importante. Quale conseguenze potrebbe avere sapere che i puntatori
hanno tutti la stessa dimensione?


 comunque non c'entra con la dimensione del dato a cui puntano...
L'accesso a queste funzionalita' e' incompatibile con lo standard del
linguaggio.
Ciao,
Nicola

 puntato".  Soddisfatto?
Scusa, ma non mi pare che questa tua affermazione sia corretta.
Supponi ad esempio che usiamo una macchina con una architettura
a "parole": un indirizzo di macchina identifica una parola di
64 bit.  Un puntatore ad oggetti la cui dimensione e` un numero
intero di parole contiene 64 bit, tutti significativi, per
identificare la parola iniziale dell'oggetto.  OK sin qui?
Supponiamo che il byte usato dal compilatore C sia di 8 bit.
Per indicare un byte entro una parola, occorrono 3 bit in piu`.
Il compilatore, diciamo, rappresenta un puntatore a char in
due parole -- 128 bit, di cui 67 significativi.
67 e 64 sono due numeri differenti.  In cosa, secondo te,
questo compilatore violerebbe lo standard C++?  Nel cast
da (che so) int* a char*, la "parola ausiliaria" del char*
potrebbe venire posta a 0.  Nel cast da char* a int*, si
taglia la parola ausiliaria. Nessuna violazione dello
standard, no?  A norma di standard, l'unico char*
che puo` essere (ri-)castato a int* e` quello che e` stato
ottenuto appunto castando un int* inizialmente... NON
"un char* qualunque"!
Se no, perche` 5.2.10 dello standard, al sottoparagrafo 7,
specificherebbe "where the alignment requirements of T2
are no stricter than those of T1"?  Secondo me queste parole
esistono SPECIFICAMENTE per consentire questa architettura,
che e` stata molto importante in passato (Cray Research,
CDC, ...) e, chissa`, potrebbe tornarlo in futuro.  In
questa architettura, i requisiti di allineamento di un
int SONO piu` stretti di quelli di un char...
Alex (MVP di Brainbench per il C++)

 wrote in message
news:3B02898D...@divalsim.it...

Non necessariamente.  Un compilatore perfettamente compatibile
con lo standard (se ne esistono: al momento, non conosco ancora
alcun compilatore che faccia un claim di compatibilita` al 100%)
puo` comunque offrire accesso a queste funzionalita`, sia via un
costrutto di #pragma (previsto dallo standard), sia con keyword
che iniziano con doppio _ (come previsto dallo standard).
Un *programma* _strettamente_ limitato all'uso dello standard
(se ne esistono: questo programma non potra` avere GUI, non
potra` accedere alla rete, non potra` connettere database,
non potra` sapere quali file ci sono in un directory... mi
chiedo se esista alcun programma commerciale in grado di
vendere qualche copia con tutti questi limiti?-) non potra`
accedere a queste funzionalita`.  Ma questo e` diverso da
dire che l'accesso e` _incompatibile_ con lo standard!
Alex (MVP di Brainbench per il C++).

 hanno tutti la stessa dimensione?
e perchè l'hai chiesto allora? :)

 simone finotti wrote:

non mi sembra corretto. Il fatto che ci siano due tipi di puntatori
non pregiudica il fatto che il codice scritto in conformità con lo
standard non debba essere compilato correttamente! fatto questo, posso
aggiungere ad un compilatore tutte le features che desidero.