Newsgroup: it.comp.lang.c++
Titolo: dubbi su auto_ptr

::auto_ptr_ref(auto_ptr<int> &)' in function auto_ptr<int>::operator
auto_ptr<i
nt>::auto_ptr_ref<int>()
*** 3 errors in Compile ***
Invece con il DJGPP:
c:/djgpp/lang/cxx/stl_construct.h: In function `void
construct<auto_ptr<int>, au
to_ptr<int> >(auto_ptr<int> *, const auto_ptr<int> &)':
c:/djgpp/lang/cxx/stl_vector.h:321:   instantiated from
`vector<auto_ptr<int>,al
locator<auto_ptr<int> > >::push_back(const auto_ptr<int> &)'
autoptr2.cpp:14:   instantiated from here
c:/djgpp/lang/cxx/stl_construct.h:48: conversion from `const auto_ptr<int>'
to `
auto_ptr<int> &' discards qualifiers
c:/djgpp/lang/cxx/memory:37: in passing argument 1 of
`auto_ptr<int>::auto_ptr(a
uto_ptr<int> &)'
c:/djgpp/lang/cxx/stl_vector.h: In method `void
vector<auto_ptr<int>,allocator<a
uto_ptr<int> > >::_M_insert_aux(auto_ptr<int> *, const auto_ptr<int> &)':
c:/djgpp/lang/cxx/stl_vector.h:325:   instantiated from here
c:/djgpp/lang/cxx/stl_vector.h:593: conversion from `const auto_ptr<int>' to
`au
to_ptr<int> &' discards qualifiers
c:/djgpp/lang/cxx/memory:37: in passing argument 1 of
`auto_ptr<int>::auto_ptr(a
uto_ptr<int> &)'
Nota:
  Purtroppo la copia di valutazione del KAI C++ mi è scaduta da tempo,
  quindi non ho potuto provare con questo compilatore, lo potrebbe fare
  qualcuno che lo possiede?
Il tutto (credo) è dovuto al fatto che il costruttore di copie di auto_ptr
accetta come argomento una referenza non const mentre l'allocatore ne
richiede una const.
Ho risolto 'a mano' il problema riscrivendomi una classe auto_ptr in cui
il puntatore all'oggetto posseduto è mutable ed in cui il costruttore di
copie
richiede una const reference.
I miei due dubbi sono:
-- il comportamento del DGJPP e del BCC5.5 è normale
   (il che significa che auto_ptr come descritto nello standard
    non può essere usato nei container), oppure sono in errore?
-- la correzzione da me fatta (dichiarare il puntatore mutable etc)
    rispetta le specifiche ANSI/ISO o almeno, è compatibile con
    esse?
Saluti e grazie  Manlio Perillo

     esse?
Secondo me e` in violazione dello standard, anche se non
ho sotto mano il PDF dello standard stesso per darti l'esatto
capitolo e versetto.
Alex


[...]


 contemplato dallo standard ma che e semplicissimo da costruire.
Non e` contemplato perche` non c'e` consenso su cosa esattamente
dovrebbe fare.  Comunque, l'architettura proposta da Milewski e`
sicuramente una delle possibilita` da considerare (ma non sarebbe
quella che sceglierei, se la scelta spettasse a me).
Alex

 wrote in message
news:8kh9eo$osc$1...@serv1.iunet.it...








 Esatto.
Comunque non mi è ancora del tutto chiaro il perchè non
debba funzionare.
Infatti il seguente programma compila e funziona come deve
(o meglio, come io mi aspetto):
#include <memory>
#include <vector>
#include <iostream>
typedef std::auto_ptr<int> auto_int;
main()
{
  auto_int a(new int(7));
  auto_int* v = static_cast<auto_int*>( operator new(sizeof(auto_int)) );
  new(v) auto_int(a);
  std::cout << "v = " << *(*v) << '\n';
  std::cout << "a = " << a.get() << '\n';
  operator delete(v);
}
Il meccanismo che ho illustrato non è lo stesso di quello usato
nell'allocatore standard?
Lo Standard non poteva prevedere e supportare questa situazione
(ossia copy ctor e copy assignment non canonici) ?
Saluti e grazie per la risposta   Manlio Perillo

 > quella che sceglierei, se la scelta spettasse a me).
Se toccasse a me, farei una partial specialization di std::vector per
std::auto_ptr<T>.  Esattamente come userei la (non-parziale)
specializzazione di std::vector per bool, invece del bitset.  Ricordo
che nulla impedisce in una specializzazione parziale o totale di
aggiungere, togliere, o modificare membri.
Alex

 (ossia copy ctor e copy assignment non canonici) ?
Senza dubbio si sarebbero potute introdurre un altro milione di
astrusita` in aggiunta al mezzo milione che gia` ci sono, ma per
fortuna si sono invece fermati prima (anche se forse non
abbastanza presto).  Personalmente, come ho gia` accennato,
non spregerei vedere una partial specialization di vector per
auto_ptr (che, comunque, ognuno puo` aggiungersi da se`, se
lo ritiene opportuno).  Un'altra possibilita`, un idioma che e`
stato usato in vari altri casi ma non in questo specifico, avrebbe
potuto essere l'introduzione di un parametro traits (con default
a un ipotetico std::canonical_traits<T> o simile) che avrebbe
permesso di determinare cosa esattamente usare per la
costruzione (default e per copia), la distruzione, l'assegnazione
per copia.  Ma sono (o meglio sarebbero) dei palliativi, secondo
me.  La semantica di auto_ptr, un oggetto che praticamente si
annienta se lo assegni a qualcosa, e` troppo peculiare per
potere pensare di trattarlo cosi` alla leggera.
Alex

 wrote :
[...]
| La semantica di auto_ptr, un oggetto che praticamente si
| annienta se lo assegni a qualcosa, e` troppo peculiare per
| potere pensare di trattarlo cosi` alla leggera.
A proposito, io sono rimasto alla versione di Greg Colvin con (ometto i
template)
auto_ptr::auto_ptr(auto_ptr& a_p);
auto_ptr::operator=(auto_ptr& a_p);
senza il const, e con auto_ptr_ref.
Per ora pero' l'ho visto solo sulle molto spesso "accusate" RW di bcc, VC6
sp3 e il g++ hanno ancora il const ref.
A 'sto punto mi sorge il dubbio... non e' che sono tornati alla versione di
prima?

 wrote in message
news:38528...@news.megasys.it...

No.  Vedi lo Standard, 20.4.5.1, sub 2-3 e sub 7-9 rispettivamente
(pag. 373 nella versione del PDF che ho sotto mano).
Alex