Re: pointer casts(newbie)
On Feb 9, 4:56 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de> wrote:
Kai-Uwe Bux wrote:
James Kanze wrote:
template< typename T >
void
dump(
std::ostream& dest,
T const& obj )
{
IOSave saver( dest ) ;
dest.setf( std::ios::hex, std::ios::basefield ) ;
dest.fill( '0' ) ;
unsigned char const*current
= reinterpret_cast< unsigned char const* >( &obj ) ;
unsigned char const*end = current + sizeof( T ) ;
while ( current != end ) {
dest << std::setw( 2 ) << *current ;
++ current ;
if ( current != end ) {
dest << ' ' ;
}
}
}
[...]
IOSave ???
I bet it's a RAII class that restores the state of the ostream
on exit, so that the user of this function doesn't
accidentally output numbers in hex with fillchar '0'.
Exactly. I've been using it for almost 15 years now. I've sort
of assumed that everyone has something like it in their toolkit.
Is there a paper somewhere about techniques / things you can
do with RAII besides managing memory and object lifetime? Like
undoing/committing changes (in transactions), restoring stream
states, etc.?
Well, in a certain sense, all use of RAII is a question of
undoing or committing changes in a transaction---even allocating
memory can be considered a change which you undo by freeing it.
Probably the most frequent use of RAII is something like
boost::scoped_lock, for mutexes. Another RAII class in my
toolkit include OutputFile (deletes the file in the destructor,
if commit hasn't been called---so you don't leave partially
written, incoherent files laying around in case of an error);
this one is associated with a SetOfOutputFiles, which ensures
all or nothing over several files. In some cases, it could also
be used to manage temporary files; I use a global
solution here (with an option to suppress the delete of the
files, for debugging purposes), but that's only valid for
programs which do something and then terminate; if a server
needs a temporary file to manage a request, it should use RAII.
I also use a somewhat extended form of RAII to manage the
context for logging (defines a "record" in the log, ensuring
that the record is written atomically in a single block, that
the first line gets the usual log header, and that following
lines are intented, and that the record ends with a '\n', even
if the client code doesn't provide one).
At a higher level, of course, all sorts of transaction
management, and even login management, can be handled, although
whether this is really RAII or not depends somewhat on the
organization of the code and the requirements of the
application. (In one application, I also used it to generate
change notifications. But that's really part of transaction
management as well.)
Interestingly, I very rarely use RAII for memory management.
Most of the time, if RAII would work, either I won't use dynamic
allocation at all, or it will be hidden in one of the standard
containers.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34