Newsgroup: it.comp.lang.c++
Titolo: dimensioni area puntata con malloc

Spero di non essere ot come nel precedente post... cmq il problema è
questo.
Vorrei sapere come posso fare a sapere quanta memoria e' stata
allocata in seguito ad una malloc.
mi spiego meglio , ammettiamo che scriva
char *p;
p=malloc(100);
a questo punto se ho capito la malloc mi riserva una area di memoria
contigua di grandezza 100 bytes (quello che gli ho passato io) + 4
bytes (la grandezza di char*p ).
Io vorrei una funzione inversa , ovvero qualcosa del tipo:
int x=funzione(p); che mi ritorni appunto 104;
Se scrivo int x=sizeof(p) mi ritorna giustamente solo 4;
Avete suggerimento da darmi?
Grazie e ciao.
Gun101


Non è possibile ottenere quello che vuoi tu; del resto se allochi memoria
con le funzioni suddette, sai benissimo la dimensione che hai intenzione di
allocare! ;-)
--------------------------------
Inviato via 
http://usenet.libero.it

 Avete suggerimento da darmi?
malloc serve solo in casi molto rari.  Per allocare memoria si usa new
o new[], e spesso non c'e` bisogno di allocare memoria "a mano".
Prova a guardare anche vector, auto_ptr, boost/smart_ptr, boost/pool.
        Mauro

 per contenere un puntatore a char.
Il ragionamento e' corretto, ma la dimensione del puntatore *non* fa
parte dell'area allocata.
 
Ciao,
Nicola
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 non è contigua...per averla così devi usare la calloc()!
L'area allocata da malloc e` sempre contigua, altrimenti sarebbe
completamente inutilizzabile (come faresti a sapere dov'e` la memoria
allocata?).
La differenza fra malloc e calloc e` che calloc azzera la memoria.
        Mauro

Leggete i libri sul C e poi venite a parlare



Non č cosě
Hai mai provato a compilare su un sistema alpha o sparc o ultra sparc!?
l'operatore sizeof() secondo te perchč esiste??


 parte dell'area allocata.
Nessuno lo ha detto che fa parte!



callocl sta per "allocazione continuata" tradotta in it


 Nessuno lo ha detto che fa parte!
Tu no, ma l'OP ha parlato di 4 byte aggiuntivi che non si capisce da
dove vengano e tu non hai commentato; quindi l'ho fatto io.


 l'operatore sizeof() secondo te perchč esiste??
Il paragrafo 5.3.3 dello standard del C++ recita:
"The sizeof operator yields the number of bytes in the object
representation of its operand. 
The operand is either an expression, which is not evaluated, or a 
parenthesized typeid. The sizeof operator shall not be applied to an 
expression that has function or incomplete type, or to an enumeration 
type before all its enumerators have been declared, or to the 
parenthesized name of such types, or to an lvalue that designates a 
bitfield.
sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1; 
the result of sizeof applied to any other fundamental type (3.9.1) is
implementation defined. [Note: in particular, sizeof(bool) and
sizeof(wchar_t) are implementation defined. 69) ] 
[Note: See 1.7 for the definition of byte and 3.9 for the definition 
of object representation. ]"
Come vedi parlando di C++ un char e' sempre lungo un byte.


 Leggete i libri sul C e poi venite a parlare
Io leggo anche libri sul C, ma qui mi riferisco a quello che dicono
libri sul C++, perche' questo e' l'argomento del newsgroup.
Dopodiche' quello che ho scritto vale anche per il C.


 ha
scritto:

SORRY!


   p = static_cast<char*>(malloc(100));
Ma, io l'ho sempre scritto " p= (char*) malloc(100); " e ha sempre
funzionato, ma devo ammettere che ho visto alcune cose negli ultimi testi di
C++ che dicevano come dicevi tu.
Temo di essere poco aggiornato ormai.
Ciao
Emanuele

 p= (char*) malloc(100); " e ha sempre
 QUESTO E' CAST STILE C
a decidere e solo la preferenza del programmatore.


 malloc(100 * sizeof(char))
Il fatto che nell'uso comune con "byte" si intenda un gruppo di otto bit
non significa che questo sia formalmente corretto. Questa volta ti
riporto la definizione dallo standard del C99 (cosi' sei piu' contento
:-)
"byte
addressable unit of data storage large enough to hold any member of the
basic character set of the execution environment
NOTE 1 It is possible to express the address of each individual byte of
an object uniquely.
NOTE 2 A byte is composed of a contiguous sequence of bits, the number
of which is implementation defined.
The least significant bit is called the low-order bit; the most
significant bit is called the high-order
bit."


significa che su un'altra architettura ha lo stesso valore!)
   In pratica sizeof(char) e` sempre uno, come specifica lo standard
ISO, quindi un char corrisponde sempre a un byte. Un byte invece
potrebbe essere composto da piu` di 8 bit.
-- 
S.L.

 a decidere e solo la preferenza del programmatore.
Diciamo che si dovrebbe *sempre* usare la prima versione.
-- 
Andrea Bergia - studente              Linux Registered User #281550


Un byte costituito da più di otto bit?!?!?
Che fai modifichi i fondamenti dell'informatica?!?
UN BYTE E' SEMPRE DI 8 BIT
non può essere diverso!


Ragazzi qui non si parla di C++ standard, si parla di C++.
Sono tanti i compilatori non conformi allo standard


 p=malloc(100);
Questo è C e non C++, altrimenti sarebbe stato:
char *p;
p = new char[100]
Che compilate con un ambiente C++, non significa che sia C++, E' codice C e
come tale viene compilato, quindi, oltre ad essere OUT, lo standard C++ non
centra nulla.


 Leggete i libri sul C e poi venite a parlare
Leggendo un libro *a caso* sul C (The C programming language, B. W.
Kernighan - D. M. Ritchie) leggo:
1.2 Variables and Arithmetic Expressions
"... C provides several other data types besides int and float, including:
char         character - a single byte
..."
7.8.5 Storage Management:
"The functions malloc and calloc obtain blocks of memory dynamically.
void *malloc(size_t n)
returns a pointer to n bytes of uninitialized storage, or NULL if the
request cannot be satisfied.
void *calloc(size_t n, size_t size)
returns a pointer to enough free space for an array of n objects of the
specified size, or NULL if
the request cannot be satisfied. The storage is initialized to zero."
Ciao,
Cecco

non può essere diverso!
http://www.wikipedia.org/wiki/Byte
sbirish.

 [CUT]
Allora avevo ragione a pensare che AlterX sparasse fregnacce sulla 
continuitą della memoria in calloc()....
:-OOO
 
-- 
Luc.

centra nulla.
veramente l'unico appunto che avresti potuto fare sarebbe stato sulla
mancanza del cast, che genera un errore in C++.
mi spiace deluderti, ma in C++ malloc esiste, se intendevi dire che č
sbagliato usarla, io prima mi leggerei Alexandrescu.
Posta un pň meno e leggi un pň di piů nel ng, ti eviti qualche
figuraccia.
Grazie per esserti documentato prima di rispondere.
sbirish.


Esiste la malloc non perchè è C++, ma perchè è una libreria che viene
inclusa con l'header stdlib.h che esiste e data come estensione al C++ per
la compatibilità con il C!


 Sono tanti i compilatori non conformi allo standard
No: per le richieste specifiche e dipendenti dall'implementazione ci sono i 
newsgroup  appositi; _qui_ si parla di C++ *nudo* e *crudo*
-- 
Per l'e-mail rimuovere la frase in maiuscolo e gli underscore.

la compatibilità con il C!
ritiro il grazie.
sbirish.

> ritiro il grazie.
In che senso?!?!
Quello che scrivo non lo leggo da nessuna parte e tantomeno mi documento
prima.


prima.
e si vede.
sbirish.

Cioè tu pensi che sto dicendo cazzate?!?
Perchè per te il linguaggio C++ è formato dalle funzioni come malloc?
posso capire se parlavi di new; questo si che è parte integrante del C++.
Ma se dici che malloc è parte integrande del C++, non hai capito nulla.


 continuità della memoria in calloc()....
Sei libero di pensare quello che vuoi, peccato che i prof della facoltà di
informatica non la pensavano così!
Pazienza...


 Pazienza...
Esatto. 
-- 
Luc.

 Pazienza...
Scusa, ma secondo quanto dici te (e i prof della facoltà di informatica), se
fai una strcpy su un puntatore a memoria allocata con malloc o con calloc
allora si rischia di ottenere undefined behaviour... a me sembra una
cavolata, mi fido più di K&R;-)
Ciao,
Cecco


Che alloca la memoria inizializzandola a 0 è scontato per me, non sò per te.
Un array secondo te, non è memoria contigua??



Non capisco cosa intendi...non ho mai detto una cosa del genere, non sto
parlando di questo!
Quello che dici tu è pienamente condiviso da me.


 calloc sta per "allocazione continuata" tradotta in it
Sta per "cancella allocata" tradotta in it. :-///
-- 
Luc.

Questo è per chi dice che la memoria è allocata SOLO contigua:
the heap that is used by malloc(), calloc() and realloc() is not guaranteed
to be one contiguous piece of memory.


calloc()
Return Value.
   A pointer to the allocated space.
   The type of this pointer is void*. A type cast to the desired type of data
pointer should be performed on this returned pointer in order to be used as
an ordinary array of a concrete type.
 If the system could not allocate the requested block of memory or if any of
the parameters was 0 a NULL pointer is returned.
Portability.
   Defined in ANSI-C. <---- I CAN'T BELIEVE!!!!
--------------------------------------------------
   Some systems may apply restrictions on the maximum size for a memory
block. >


 to be one contiguous piece of memory.
Si intende PAGINE di memoria non contigue... č normale! Tanto poi ci 
sono le tabelle di traslazione... da contiguo a pagine.
Tutto questo implica che, se devo fare un device che usa il DMA per 
scaricare qualcosa in memoria (č un esempio...) non č garantito che la 
memoria allocata sia su pagine contigue, cioč con indirizzi FISICI 
contigui. Questo non vuol dire che il vettore ha dei buchi, ma che 
semplicemente le pagine sono messe nei modi piů vari in memoria.
Se stiamo parlando in ALTO livello allora si puň affermare che la 
memoria allocata č vista come un vettore di byte contigui.
Se scendiamo a livello di Sistema Operativo, questo non vuol dire che 
gli indirizzi FISICI siano necessariamente contigui (VIRTUALI sě 
ovviamente).
OK?
Luigi

Ma se dici che malloc è parte integrande del C++, non hai capito nulla.
std::malloc è citata più volte nello standard iso-iec-14882-1998.
proviamo con la maieutica:
Un_altro>> char *p;
Un_altro>> p=malloc(100);
tu> Questo è C e non C++, altrimenti sarebbe stato:
tu> char *p;
tu> p = new char[100]
1) mi dici cosa vieta in C++ l'uso di std::malloc ? 
2) ritieni che non sia standard? 
3) ritieni che l'uso di malloc in C++ sia a priori errato?
4) puoi dirmi spiegarmi cosa c'è di sbagliato nelle righe qui sotto?
template <class T>
struct MallocCreator
{
	static T* Create()
	{
		void* buf = std::malloc(sizeof(T));
		if (!buf) return 0;
		return new(buf) T;
	}
};
sbirish.

Ti riferisci a questo dicendo che un byte non è sempre 8 BIT!?!?!
 a contiguous sequence of a fixed number of bits; 8 bit bytes are by far and
away the most common though 7 bit bytes and 9 bit bytes (especially on the
36 bit architecture of the PDP-10)
Ma hai visto che si riferisce ad una architettura di 36bit, come accennavo
io prima?!?
E QUESTO CONCORDA CON QUELLO CHE DICO IO SULLA DIMENSIONE DI UN CHAR CHE
PUO' VARIARE!!!
e sottolineo l'uso di sizeof().


Ma io non sto dicendo che non è standard C, ne tanto meno che non lo si può
usare misto con C++.


Ma intendevo questo, in un certo senso sono "buchi" di memoria, visto che
c'è una tabella di traslazione...non è contigua


 c'è una tabella di traslazione...non è contigua
Lo so, ma ho specificato per ivatere che ci fossero troppi botta e 
risposta! :)
Ciao!

OK!


 risposta! :)
 Finalmente qualcuno che ha capito il problema!


 Che alloca la memoria inizializzandola a 0 č scontato per me, non sň per
te.
Non č affatto scontato: malloc ritorna semplicemente un "chunk" di memoria
di dimensione richiesta, ma il suo contenuto non č affatto inizializzato,
per cui dipende da cosa era memorizzato prima in quell'area di memoria;
calloc invece "cancella" tutto il contenuto precedente ponendolo a zero.
Ciao,
Cecco

 Quello che dici tu è pienamente condiviso da me.
Tu hai detto in un post precedente che malloc non ritorna un'area di memoria
contigua, ma se così fosse non ci potresti fare nulla senza rischiare di
scrivere in aree di memoria protetta, il che mi sembra un'assurdità;-)
Ciao,
Cecco

non può essere diverso!
   Puo`.
-- 
S.L.

e sottolineo l'uso di sizeof().
   La dimensione di un char in bit puo` variare. La dimensione di un
char in byte e` sempre e comunque uno (sizeof(char) = 1). Se la
macchina ha un char di 9 bit, ha un byte di 9 bit. Se un compilatore
restituisce un valore diverso da 1 per sizeof(char) non e` conforme
allo standard.
   Non mi vengono in mente altri modi per dirlo, rinuncio.
-- 
S.L.

 Diciamo che si dovrebbe *sempre* usare la prima versione.
C'e' una ragione pratica oppure e' una questione di stile?
Ciao

 Ma se dici che malloc è parte integrande del C++, non hai capito nulla.
Lo standard del C++ non ha capito nulla.  
Strano, perche' e` la definizione ufficiale del linguaggio.  Prova a
inoltrare un defect report, ma dubito che lo accettino, visto che
tutti i maggiori esperti di C++ e i membri del comitato di
standardizzazione non capiscono nulla.
Citazione da it.sport.atletica (Icarus):
  non necessariamente "gli altri" hanno ragione, ma se quando vai in
  autostrada vedi tutti che ti vengono contro, prova a ripensare a
  come hai preso il casello.
        Mauro

 C'e' una ragione pratica oppure e' una questione di stile?
Lo static_cast è più facile da individuare nei sorgenti del (cast); 
richiama di più l'attenzione.
Saluti
-- 
Per l'e-mail rimuovere la frase in maiuscolo e gli underscore.

 guaranteed to be one contiguous piece of memory.
magari se leggessi con un po' piu` di attenzione riusciresti a capirci
qualcosa, no?
Quello che non e` necessariamente contigui e` lo *heap* usato da malloc - ma
lo heap e` una cosa ben diversa dai singoli buffer di memoria restituiti,
che invece sono contigui.
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

 Pazienza...
Bwahahahaha
Me ne sono stato in disparte perchè  'onestamente' non saprei bene a chi
dare ragione, conosco poco il C, un pochino meglio il C++ e ho sempre usano
new anzichè malloc o calloc.
Ma a questa chicca non potevo non rispondere....
Ragazzi: non si può dare credito ai professori....
Chi sa fa, chi non sa insegna.
Giusto per citarvi qualche aneddoto:
- il prof ci fornisce 50 listati di esempio da usare per fare le
esercitazioni: tutti e 50 i main sono stati dichiarati void
- interrogazione: l'alunno scrive <iostream> e il prof segna errore, manca
il .h
- listato per esemplificare la lista, mostrato sulla lavagna luminosa e
disponibile nelle dispense, dopo averlo copiato scrupolosamente ha rivelato
la bellezza di 34 errori sintattici, tutti corretti a uno a uno, ma il prof
aveva provato a compilare? misteri della fede......
- matrice, per accedere all'elemento a,b la bellissima espressione
matrice[a,b]!!! (quando l'ho vista ho deciso che era più divertente smettere
di leggere asimov e seguire... chissà quante chicche mi sono perso!)
Meno male che gli esercitatori la sanno più lunga dei professori, perlomeno
quei tanti che non hanno l'autonomia di leggersi uno di quei mattoni sul C++
(che a me piacciono tanto e credo pure a voi) si rifanno chiedendo a
loro.......


Stai solo girando la frittata, alla fine è come dico io!
no un byte è sempre di 8 bit!
Almeno sai che è un'unità di misura standard com il metro??
millimetri, centimetri, metro, etc...
BIT BYTE KiloByte, etc...
hai mai sentito parlare di un metro formato da 90 cm?!?
se hai un computer che ti misura 1Kb come formato da 1000 bytes, anzicchè
1024 bytes, allora ti credo. Ma penso che questo non succederà mai!!
L'ho già scritto in questo thread:
UN BYTE E' SEMPRE DI 8 BIT
CHE UN CHAR PER LO STANDARD C++ E' DI 1 byte, per questo non devi applicare
la proprietà transitiva per cui un CHAR=1 byte = 8 bit... NON ESISTE!!!
Un char è un tipo virtuale e, come ti ho dimostrato sin dall'inizio è
variabile, proprio perchè è un tipo inventato e dipende da un' architettura
particolare, ma il byte è sempre un byte, come un metro è sempre un metro!
NON SI DISCUTE.
Ipotizziamo per assurdo che posso creare il tipo char:
typedef union char {
      int car: 8; // in questo caso combacia con un byte, ossia un char su IA32
      int car: 16; // in questo caso combacia con due byte, ossia due char su
IA32, magari un char su IA 64
};
ma 1 byte è sempre 8 bit.
FINISCO NON RISPONDO PIU' CON CHI NON VUOLE IMPARARE O ACCETTARE LA VERITA'!


Basta fare una ricerca su google, ma per comodità vi do uno dei tanti
indirizzi dove troverete una piccola descrizione dei tipi, e frasi come:
"La dimensione delle locazioni di memoria associate a variabili che hanno
certi tipi non è fissa per tutte le architetture, ma può variare."
oppure:
" Una sequenza di otto bit prende il nome di byte"
o ancora:
"l tipo int è per default signed e quindi è equivalente a tipo signed int,
invece i tipi char, signed char e unsigned char sono considerate categorie
distinte. I vari tipi sopra elencati, oltre a differire per l'intervallo dei
valori rappresentabili, differiscono anche per la quantità di memoria
richiesta per rappresentare un valore di quel tipo (che però può variare da
implementazione a implementazione). "
Indirizzo:
 
http://www.itc-belotti.org/5b9900/Gotti/Dichiarazioni/Tipi
 primitivi.htm
Andate in pace!


 ha scritto nel messaggio
news:81Z72Z86Z56Y10...@usenet.libero.it...

Beh, detto da uno che scrive una cosa del genere:
// il mio primo programma in C++
// visualizzazione di una stringa
#include <iostream.h>
void main()  {
    cout << "Il mio primo programma in C++ " << endl;
}
ne deduco che non ha mai letto uno Standard, per cui non sa nemmeno che lo
standard definisce 1 byte come la dimensione di un char, come ti ha già
fatto notare Nicola Musatti postandoti l'excerpt dello Standard. Non credi
nemmeno a chi ha fondato il linguaggio?
Comunque, in aggiunta a tutto quello che ti hanno già fatto notare, ti posto
un brano preso dal Jargon Dictionary
(
http://info.astrian.net/jargon/terms/b/byte.html
, l'ho trovato facendo una
ricerca con google;-):
"
byte
byte     /bi:t/ n.     [techspeak] A unit of memory or data equal to the
amount used to represent one character; on modern architectures this is
usually 8 bits, but may be 9 on 36-bit machines. Some older architectures
used `byte' for quantities of 6 or 7 bits, and the PDP-10 supported `bytes'
that were actually bitfields of 1 to 36 bits! These usages are now obsolete,
and even 9-bit bytes have become rare in the general trend toward power-of-2
word sizes.
Historical note: The term was coined by Werner Buchholz in 1956 during the
early design phase for the IBM Stretch computer; originally it was described
as 1 to 6 bits (typical I/O equipment of the period used 6-bit chunks of
information). The move to an 8-bit byte happened in late 1956, and this size
was later adopted and promulgated as a standard by the System/360. The word
was coined by mutating the word `bite' so it would not be accidentally
misspelled as bit. See also nybble.
"
Ciao,
Cecco


Ribadisce sempre che un char può variare di numero di bit...e questo lo sto
dicendo dal primo post del thread!!!
Che lo standard C++ definisce il CHAR come un byte, non significa che un
byte può essere diverso di numero di bit! Il char si, ma non il byte!
un byte è sempre 8 bit!
come un metro è sempre 100cm!
Riuscite a capire la differenza tra un tipo inventato (char) e una unità di
misura (byte)????
A me sembra di no!
Per quanto riguarda il "suo primo programma", quello che ha scritto a
maggior ragione lo ha preso da qualche libro, ed è così visto che le cose
che ha scritto sono reali!.


 >    
http://www.itc-belotti.org/5b9900/Gotti/Dichiarazioni/Tipi
Scusate eh... ci metto pure la mia di opinione.
Da quel che ne so io lo standard C++ definisce il char come dato avente
sizeof pari a uno. Ovviamente se è signed o unsigned la dimensione non
cambia. Gli altri tipi di dati possono variare a condizione che
1=sizeof(char)=sizeof(unsigned char)=sizeof(signed
char)<=sizeof(short)=sizeof(unsigned short)=sizeof(signed
short)<=sizeof(int)=sizeof(unsigned int)=sizeof(signed
int)<=sizeof(long)=sizeof(signed long)=sizeof(unsigned long).
Se quanto sopra non è rispettato allora il compilatore C++ non è un
compilatore C++ standard
Ogni sistema ha la sua parola e generalmente un int ha dimensione pari a una
parola, ma non è una regola.
Inoltre:
Una parola è un insieme bit, tale che possa contenere un certo numero di
byte, ad esempio 16 bit o 32 bit ed è importante per la rappresentazione
degli indirizzi della memoria.
Bit è la minima unità di informazione e può essere 0 o 1
Nipple  sono 4 bit
Byte è stato definito come 8 bit nell'ultimo quarto di secolo, e oggi credo
che su tutti i sistemi in commercio
un byte sia pari a 8 bit ma....
è tuttavia vero che alcuni vecchi computer (ad esempio alcuni mainframe
piuttosto datati) avevano parola di 36 bit, ad esempio (questo non lo sapevo
ma l'ho trovato online) gli IBM 701, 702 e 704 del 1953-1955
Ciò significa che avevano un byte pari a 9 bit e parola pari a 4 byte.
Per cui un byte può essere definito a piacimento anche se negli ultimi anni
la dimensione di un byte è universalmente di 8 bit
Quindi un char potrebbe teoricamente essere di 9 bit (molto difficile) ma in
ogni caso la sua dimensione è 1.
Quindi se malloc(x) alloca x byte, crea spazio per x char, qualunque sia la
parola e qualunque sia la definizione di byte.

Mamma mia che thread lungo... C'ho trenta metri di post sopra la testa ;-)
 Non voglio intromettermi su discorsi improntati sullo "standard" del C++ e
sulle definizione esatte, anche perche' non le conosco bene. Tuttavia credo
che la verita' sia nel mezzo. La necessita' di definire un Byte nasce dal
fatto che questa e' la piu' piccola area di memoria accessibile attraverso
un indirizzo di memoria. Se si vuole scrivere un bit, il microprocessore
deve prima leggere tutto il byte di appartenenza e riscriverlo dopo aver
modificato il singolo bit. Credo che il C++ usi il char per definire questa
area, e tutte le architetture hardware che conosco utilizzano 8 bit per
formare un byte.
Credo che andare alla ricerca di una verita' storica sia di poca importanza
e credo pure che sara' difficile che incontrero' un byte a 6 bit, vorrei
dire impossibile ma non si sa mai. Tuttavia si possono avere delle
differenze con float e integer le cui dimensioni possono tranquillamente
dipendere dall'architettura della macchina (address a 64 bit invece che a
32).
Chiedo scusa per l'intromissione e spero che non troverete in quello che ho
scritto troppe castronerie.
Ciao
Emanuele

 Nipple  sono 4 bit
NIBBLE ! (Nipple vuol dire capezzolo...)
freudianamente,
g.

 bit invece che a 32).
Tra l'altro, avete mai riflettuto sulle conseguenze di una disparità di 
dimensionamento tra dati e indirizzi? Per esempio, non si potrà (con 
facilità) spostarsi da un dominio all'altro...
Ciao!
-- 
---
*************** | Have you ever retired a human by mystake?
*** Azathot *** |
*************** | To contact me, ask me gently. Thanks.

Giovanni Resta <g.r...@iit.cnr.it.nospam> wrote in message
3EBBA26...@iit.cnr.it.nospam...

LOL
certamente un lapsus freudiano
;-)

 int x=funzione(p); che mi ritorni appunto 104;
Io farei così:
void * operator ::new( size_t _size ) {
   if ( _size == 0 ) _size = 1;
   void * rc = malloc( _size + sizeof( size_t ) );
   * ( size_t * ) rc = _size;
   return ( char * ) rc + sizeof( size_t );
}
size_t runtime_sizeof( void * _ptr ) {
   size_t * st = ( char * ) _ptr - sizeof( size_t );
   return *st;
}
void * operator ::delete( void * _ptr ) {
   if ( ! _ptr )
      return;
   free( ( char * ) _ptr - sizeof( size_t ) );
}
Esempio di uso:
main( ) {
        char * pippo = new char[ 100 ];
        cout << "Ho allocato " << runtime_sizeof( pippo ) << " bytes." << endl;
        delete[] pippo;


 un byte è sempre 8 bit!
Non secondo la definizione usata dallo standard del C++ (e da molti
altri).
Nessuno (tranne il buon senso) ti vieta di definire il byte in altro
modo, pero quando lo standard C++ parla di byte, usa la sua
definizione (char) e non la tua (8 bit).  Quando lo standard dice che
sizeof restituisce il numero di byte, vuol dire che sizeof restituisce
il numero di caratteri, non il (n. di bit / 8).
        Mauro

 void * operator ::new( size_t _size ) {
Ma hai provato almeno a compilare?...
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

 Ma hai provato almeno a compilare?...
Veramente no. Lo lasciavo come compito a casa. :)


 32).
Il problema non è questo, ma semplicemente il fatto che AlterX sostiene,
contro quanto posto dallo Standard, che non sia vera l'uguaglianza
sizeof(char) = 1 byte, mentre tutti i documenti ufficiali che sono stati
postati nel corso del thread ne dimostrano la veridicità.
Ciao,
Cecco

 che ha scritto sono reali!.
E questo cosa significa? Che tu credi a quello che ha scritto una persona
che non si documenta sul C++ da mooolti anni, e non credi invece a chi ti
dice delle cose documentandone la provenienza. Non capisco per quale motivo
ti ostini a sostenere delle tesi di cui sei convinto solo tu quando la
verità ti viene messa sotto al naso.
Ciao,
Cecco

 Avete suggerimento da darmi?
l'idea generale è di ridefinire malloc, realloc e free in questo modo:
void * smalloc(std::size_t _Size)
{
 // alloca la memoria richiesta e lo spazio per un std::size_t
 void * pTemp = std::malloc(_Size + sizeof(_Size));
 if(pTemp)
 {
  // salva le dimensioni del buffer
  *(std::size_t *)pTemp = _Size;
  // ritorna il buffer usabile
  return (std::size_t *)pTemp + 1;
 }
 return pTemp;
}
void * srealloc(void * _Ptr, std::size_t _Size)
{
 if(_Ptr)
 {
  if(_Size)
  {
   // il vero buffer inizia un std::size_t prima e deve includere
   // spazio extra per uno std::size_t
   void * pTemp =
    std::realloc((std::size_t *)_Ptr - 1, _Size + sizeof(_Size));
   if(pTemp)
   {
    // salva le nuove dimensioni del buffer
    *(std::size_t *)pTemp = _Size;
    // ritorna il buffer usabile
    return (std::size_t *)pTemp + 1;
   }
   return pTemp;
  }
  else
  {
   // come sopra
   std::free((std::size_t *)_Ptr - 1);
   return NULL;
  }
 }
 return std::malloc(_Size);
}
void sfree(void * _Ptr) { std::free((std::size_t *)_Ptr - 1); }
std::size_t smemsize(void * _Ptr) { return *(std::size_t *)_Ptr; }
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.1. C, C++ and ASM developers
                               and beta testers are welcome!

void * smalloc(std::size_t _Size)
Che bella idea usare quel brutto identificatore
_Size! Lo hai fatto per cercare in tutti i modi
di avere grane ? Non sarebbe stato piu' leggibile
un identificatore "normale" ?
"
hmmmmmmm .... meglio inizare con un underscore che
fa fiko... ma... aspetta... cosi' il programma
sarebbe comunque legale visto che si tratta di
un simbolo locale... meglio usare un underscore
seguito da una maiuscola (che e' riservato per
gli implementatori)!!
Mamma quanto sono fiko! MaMmA kUaNtO sOnO fIkOoOoOoOo
"
Bah...
Se dovessi valutare questa roba per decidere se
dare un parere favorevole alla tua assunzione la
sola scelta di questi nomi ti taglierebbe fuori...
perche' si evince che non e' che non lo sapevi...
ma che sapevi e hai fatto apposta.
Roba da asilo.
E questo senza contare la sostanza (come i potenziali
problemi di allineamento di cui non fai cenno).
Andrea

 problemi di allineamento di cui non fai cenno).
D'altro canto, lei non programma mica con certe "mostruosità"... (cfr. 
thread "Newbie")... lei programma "mostruosità" direttamente. :)


 allineamento di cui non fai cenno).
che non esistono. malloc non garantisce alcun allineamento


 Coglione
Che insulti sono questi !?!
Se volete insultarvi chiamative in privato, non fatelo qui.
Tommy

 sì, l'ho fatto apposta per avere te a triturarmi le palle.
Così finalmente scopriamo che, in realtà, sei un trans.


nonostante quello che potrebbe dire il mio nick, sono Juliet. Ah, quasi 
dimenticavo, Andrea Griffini ha scritto:
[...]
noto anche i memorabili contributi che hai dato al newsgroup di recente


 noto anche i memorabili contributi che hai dato al newsgroup di recente
Dì la verità: hai le tue cose, vero?


 Che insulti sono questi !?!
non prendo molto bene il non essere adulata e riverita


 non prendo molto bene il non essere adulata e riverita
Guarda che con un leggero antidolorifico i cinque giorni passano più 
rapidamente. Garantito.


che non esistono. malloc non garantisce alcun allineamento
Una bestialita' come questa che stai dicendo non merita
neppure un commento. Comunque vedo che a segare una
ipotetica candidatura in effetti farei bene... non
perche' non conosci il problema dell'allineamento
(l'ignoranza non e' in se' una colpa) ma perche'
nemmeno ti sei sognato/a di controllare.
Andrea

noto anche i memorabili contributi che hai dato al newsgroup di recente
Non scrivo molto in questo newsgroup in effetti.
Il rapporto segnale/rumore, e mi spiace notarlo,
qui e' veramente infimo.
Andrea

non prendo molto bene il non essere adulata e riverita
Deve essere una vita dura...
Battute a parte in effetti rileggendo il messaggio vedo
che sono stato un po' "forte"; ma in passato ho avuto
discussioni molto accese con wannabe programmatori
professionisti che insistevano nella violazione di
regole sui nomi perche' .... hmmm .... non so perche'.
Un professionista ogni tanto deve prendere qualche
rischio o violare qualche regola per arrivare al
100% della soluzione. Ma violare regole note per il
solo gusto di farlo e' veramente da imbecilli.
Completamente diverso se la cosa e' capitata per caso
e perche' ignoravi la regola.
Resta un fatto che hai un pessimo gusto per i nomi :)
Andrea
PS:
  Hmmm... una donna ? Programmatrice ?
  Una vera rarita' :) ... Io sono appassionato
  di programmazione, matematica, scacchi e arti
  marziali; tutta roba in cui le donne le devi
  cercare con il lanternino (tranne forse la
  matematica). Un vero peccato avere cominciato
  con il piede sbagliato... se dovessimo finire
  con lo sposarci pero' il nome dei bimbi lo
  decido io (e niente underscore!).

che non esistono. malloc non garantisce alcun allineamento
   Andrea si riferiva a particolari architetture che potrebbero avere
particolari requisiti di indirizzamento. Si spiega meglio con una
ipotesi:
   alcune cpu con byte di 8 bit ,ad esempio, potrebbero riuscire ad
accedere a un intero a 64 bit (diciamo "quadword"), solo se questo si
trova a un indirizzo multiplo di 8 (altrimenti vanno in exception e
comunque non leggono/scrivono la quadword);
   poiche` malloc non sa a priori per cosa userai l'area allocata, su
quelle architetture restituira` sempre un'area allineata all'ottavo
byte (l'indirizzo avra` comunque gli ultimi tre bit pari a zero);
   queste macchine potrebbero tuttavia avere un size_t di 32 bit;
   sotto queste condizioni (credimi, non del tutto improbabili), la
tua implementazione restituirebbe un puntatore sfalsato di 4 byte, e
quindi inutilizzabile per chi volesse allocare un'array di quadword.
-- 
S.L.

 sognato/a di controllare.
dove devo controllare? (potrei sapere già che tipo di allineamento vien 
garantito da malloc. Considera questo. Potrei averci pensato su, capito 
l'errore - banale, a differenza di quanto tu voglia far credere facendo 
leva su una delle mie rare parentesi di ignoranza - e voler solo vedere 
come risponderai. Non si fa un messaggio educato per poi cadere così, e 
tutto perchè non ti sei accontentato di avere semplicemente ragione, ma 
hai voluto pretenderti superiore)


 taglierebbe fuori...
santo cielo! mi stai dicendo che non assumeresti mai il team della STL? 
bontŕ mia, io credevo che la Silicon Graphics assumesse persone capaci, 
e invece...! che delusione. Che terribile delusione, a pensare a quanto 
del mio codice si basa su una libreria in cui si leggono orrori simili:
// [...]
template <class _CharT, class _Traits>
class basic_ostream : virtual public basic_ios<_CharT, _Traits>
{
  typedef basic_ostream<_CharT, _Traits> _Self;
 
public:                         // Types
  typedef _CharT                     char_type;
  typedef typename _Traits::int_type int_type;
  typedef typename _Traits::pos_type pos_type;
  typedef typename _Traits::off_type off_type;
  typedef _Traits                    traits_type;
  typedef basic_ios<_CharT, _Traits> _Basic_ios;
public:                         // Constructor and destructor.
  explicit basic_ostream(basic_streambuf<_CharT, _Traits>* __buf);
  ~basic_ostream();
// [...]
santa miseria, ma ci sono un sacco di underscore seguiti da maiuscola e 
doppi underscore! ce n'č una quantitŕ incredibile! si potrebbe dire che 
quasi tutti gli identificatori sono illegali! mio dio, qualcuno avverta 
questi poveri sprovveduti che non stanno scrivendo un compilatore!
Parlando seriamente, come dovrei interpretare tutto ciň?


 linguaggio ti evita di dover scrivere in notazione ungherese.
non sequitur. Il punto della notazione ungherese non è lo *scrivere* il 
codice, quanto il *leggerlo*


Parlando seriamente, come dovrei interpretare tutto ciň?
Sono giunto a due conclusioni:
 1) parlare seriamente e' ampiamente al di la' delle
    tue possibilita' cerebrali
 2) tu non hai abbastanza neuroni per poter
    interpretare queste cose o per comprendere
    o anche semplicemente mandare a memoria che
    nei programmi che scrivi non puoi usare
    identificativi che iniziano con un underscore
    seguito da una lettera maiuscola.
L'unica altra alternativa che vedo e' che invece tu la
cosa l'abbia capita perfettamente e che per qualche
misteriosa ragione stia solo perdendo tempo e
facendone perdere a me.
Andrea

quando ti pare, se hai dubbi che non legga la documentazione e basta)
è vero che lo standard sia a pagamento ( una cifra più simbolica che
 altro..) ma è anche vero che i draft degli standard li trovi online..
puoi leggere quello se ti interessa..
... baci sparsi ...
sbirish

Parlando seriamente, come dovrei interpretare tutto ciň?
ciao juliet, gli underscore prefissi sono appunto riservati agli
implementor per la libreria. viene generalmente considerato non
igienico utilizzare gli underscore prefissi per evitare collisioni,
per quanto in letteratura tu possa trovare esempi in cui tale
convenzione viene utilizzata ( cfr. Gof ).
... baci sparsi...
sbirish

 convenzione viene utilizzata ( cfr. Gof ).
Scusate. Come č esattamente la regola degli identificatori?
Underscore + Maiuscola meglio di no
Underscore + Underscore meglio di no
Underscore + Minuscola invece va bene?


Gli identificatori che *iniziano* con un underscore e una lettera maiuscola
oppure che *contengono* due underscore di seguito sono riservati in ogni
contesto.
Nel namespace globale gli identificatori che *iniziano* con un underscore sono
riservati.
Max

 
Credo che tuttavia non sia necessaria. E' vero che ammetti di essere 
molto C like, e che il C++ per te è un'aggiunta... ma in C++ non credo 
che ci sia la necessità della notazione ungherese.
Parere personale.
Luigi

 
Una domanda... ma tu sei al polito?

 cerebrali
limitati a rispondere, non mi interessano questi giochetti


limitati a rispondere, non mi interessano questi giochetti
Ok mamma
Andrea

 libreria standard, ma una qualsiasi libreria di terze parti.
La ex-stl č entrata a far parte delle librerie standard (non tutta ma quasi,
credo con la revisione del 98).

 un po' di cervello
ne ho abbastanza da essere me, te e altre 2.6 persone, e farle laureare 
ad Harvard tutte quante
(commento fuori luogo: qui si tratta di sapere, non di capire)


FINISCO NON RISPONDO PIU' CON CHI NON VUOLE IMPARARE O ACCETTARE LA VERITA'!
Tra la tua verità e quella di Bjarne ho già scelto.
Ritorno nel limbo ... ciao!

(commento fuori luogo: qui si tratta di sapere, non di capire)
Il problema e' che mai riuscirai ad apprendere se prima non
capisci che tu, di C++, non sai niente. Ne sai talmente poco
che nemmeno ti rendi conto di quanto e' poco.
Esiste anche un problema di atteggiamento terribile, che
ti porta a difendere ad oltranza le cazzate sparate per
(incolpevole) ignoranza, come se dalla difesa di quelle
fesserie dipendesse la tua dignita' quando e' invece proprio
in questa difesa irragionevole che si perde la faccia.
Faccia a cui comunque non sembri tenere un granche', visto
che non ti degni nemmeno di fare un minimo sforzo di verifica
prima di affiggere su tutti i muri del mondo imbecillita'
con sotto la tua firma.
Hmmm... firma...
Veramente non e' che si possa parlare della tua firma...
e questo forse spiega la spavalderia. Mi sono sempre chiesto
se chi fa post anonimi lo fa perche un briciolo di coscienza
residua si vergogna di quanto viene scritto.
Boh... credo che vivro' una vita terribile arrovellandomi
con questo dubbio giorno e notte. O magari no.
Passo e chiudo
Andrea

 briciolo di coscienza residua si vergogna di quanto viene scritto.
anonima? io sono Juliet. Sempre stata Juliet, sempre lo sarò, sempre lo 
stesso indirizzo di posta elettronica. Mai nascosto la mia identità
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.1. C, C++ and ASM developers
                               and beta testers are welcome!