Search  

---

C:/temp/src/j2k/Deprecated/old_18mar_diff/Str14dec/StrExtra.cpp

Go to the documentation of this file.

#ifndef __J2K__JString_Extra_CPP__
#define __J2K__JString_Extra_CPP__

#include <j2k/Fred/String/String.hpp>

/*
Functions defined:
------------------
AllocBuffer( size )
AllocBeforeWrite( size )
GetBuffer( size )
ReleaseBuffer()
FreeExtra()
LockBuffer()
UnlockBuffer()

Functions used:
---------------
CopyBeforeWrite()
*/

// ALL THESE ARE FOR EXTERNAL USAGE ONLY !

/** ANDREA ***************************************************

  I didn't know the term "external usage". What does that mean ?
  That users of the class can use these methods but implementer
  are forbidden to ?

  No, it comes from CString, it means that users are able
  to screw up the char* as they want.

  "External usage of internal privates..."

*************************************************************/

inline void JString::AllocBuffer(ULONG Len) {  
  pData->Dec(); 
  pData = new JStringData( Len );
}

inline void JString::AllocBeforeWrite(ULONG Len) { 
  if ( pData == strNull || pData->nbRefs > 1 || Len > pData->bufferSize ) {
    pData->Dec();
    pData = new JStringData( Len );
  }
}

////////////////////////////////////////////////////////////////////////////
// Advanced direct buffer access
////////////////////////////////////////////////////////////////////////////

char* JString::GetBuffer(ULONG minBuf) {

 if (pData == strNull) {
   return "";
 }

/** ANDREA ***************************************************

  We are ignoring the minBuf parameter. Is this the intended
  behaviour ? This surprises me. It means that

  char *b=s.GetBuffer(100);
  // Now i've a pointer to 100 chars (minimum)
  // or may be not if the string was initially empty.

  If it's empty then you get nothing, maybe I could provide an empty bigger ?!

*************************************************************/
 
 if (pData->lock != 0) {  // Already locked !
   pData->lock++;
   return pData->data;
 }

/** ANDREA ***************************************************

  Here we ignored the minBuf parameter. Is this correct ?
  This surprises me even more.

  char *b=s.GetBuffer(100);
  // Now i've a pointer to 100 chars (minimum)
  // or may be less if someone got the buffer too
  // before me and asked for a smaller minimum size.

  If it's lock it's lock.
  It's not expected behavior.
  
*************************************************************/

 if ( pData->nbRefs > 1  ||  minBuf > pData->bufferSize) {
   // We have to create a new buffer
   if ( minBuf < pData->length ) {
     minBuf = pData->length;
   }

   JStringData* pOldData = pData;
   pData = new JStringData( pData->data, minBuf );
   pOldData->Dec();
 }

 pData->lock = 1;

 // return a pointer to the character storage for this JString
 return pData->data;
}

inline void JString::ReleaseBuffer() {
  if (pData == strNull) return;
  pData->lock--;
  pData->Dec();       // Destroy the object, if NO Lock !

/** ANDREA ***************************************************

  After calling ReleaseBuffer the string object is pointing
  to an istance of JStringData that has been destroyed.

  NO?  Unless the user delete it ?
  I should check maybe for pData == NULL ?

  This means that when the string object will be destroyed
  too it will call Dec() on a dead object.
  This means undefined behaviour.

  hmmm.
*************************************************************/
}

void JString::FreeExtra() {
  if (pData == strNull ) return;
  if (pData->length <= 0 ) {
    pData->Dec();
    pData = strNull;
    return;
  }

  if (pData->length < pData->bufferSize) {
    JStringData* pOldData = pData;
    pData = new JStringData( pOldData->data, pOldData->length );
    pOldData->Dec();
  }
}

inline char* JString::LockBuffer() {
  return GetBuffer( 0 );
}

inline void JString::UnlockBuffer() {  
  ReleaseBuffer();    // The object is Destroy, if NO Lock !
/** ANDREA ***************************************************

  No... the JStringData object is destroyed; not the object.
  This generates a serious double-destroy problem or a may
  be more subtle memory overwrite: normally good debug memory
  handlers can detect a simple double destruction, but if the
  memory is reallocated to some other object then you're just
  going to access some raw memory considering it a JStringData
  object. Even worse there is an high probability that the
  memory area will be allocated to just another JStringData
  object with even more subtle long-term effects.

  And your wonderful "safety checks" are probably going to
  further delay the discovery of such problems probably
  several millions instructions after this bug gave its bite.

  But if you got your A+ in the meanwhile...


  Let me think about it again, it comes from CString ( MFC lib )
  it not a safe feature, but I wanted to be compatible... hmmm.
*************************************************************/
}

#endif

---