Re: replacing unsigned char * with CString

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

But that's what Java does, all the time! It explicitly allocates memory, in all kinds of
situations. What do you think 'new' means in Java? It means "allocate memory"!

In your example, where you do a GetBuffer, if you did a GetBuffer of the wrong length, you
would still go out of bounds if you tried to write more via that pointer than you had
allocated. Nothing would magically expand the buffer for you; you'd just trash all the
nearby memory.

The issue of scope is another problem. You say you don't have to worry about deleting the
object when you close the program. You don't have to worry about deleting ANY object when
you close a program; they all go away! (Of course, the MFC debug runtime will complain,
but that's because it;s trying to help you avoid storage leaks). I often use CByteArray
or CArray<BYTE, BYTE> because the storage is released when I go out of scope, which is a
far more interesting situation.

Generally, you should forget the datatype 'char' exists at all in modern programming; it
is limited to very exotic situations where 8-bit signed values are required. Most
situations such as images would NEVER use 'char' as a datatype; they would use 'unsigned
char' and in the Windows world they would use that as BYTE, or a pointer LPBYTE.

Note the construct
CByteArray b;
b.SetSize(some value here);
ReadFile(h, b.GetData(), b.GetSize(), &bytesRead, NULL);
... use the data

means that all the space allocated to the CByteArray will be automatically disposed of
when you leave the scope where the CByteArray was declared, in this case, the end of the
block containing the declaration. So there's no reason to drop down to the
LPBYTE b = new BYTE[some value here];
...
delete [] b;
level of coding. std::vector has the same charm.
joe

On Wed, 12 Jul 2006 11:51:43 -0400, "Arlis Rose" <arlisATendevouraerospace.com> wrote:

Thanks Tom, yeah I now the stuff that is in those articles (read them both
just in case :) I think the main problem is that I am so used to (having
only been taught) Java syntax and I guess structure, that dynamically
allocating memory just seems...well wrong to me :S I think the problem is I
still want to see char * as Strings (as they are defined in Java) and not
array's (which is what they really are after all).
Basically the reason I like CString so much is that I have needed to have
2-3 consistent "strings" of data available to different functions, and so I
had simple added them as private class variables as "CString blah;" This
way I don't have to worry about going out of bounds, I can use all the
CStrings class functions (like Empty() and Format() and GetAt()), and again
(lazy programming I know) but I don't have to worry about deleting the
object when I close the program.
In the example I gave below the char * (if allocated the same way I do my
CString (I.e. via the size of the file I am going to read in)) makes the
most sense to me. I guess the problem was I originally just tried to write
"CString blah" at the beginning of the function and get it to work (without
having to dynamically allocate the memory myself) and this just isn't either
possible or at least suggested in this case. (BTW the way the programmer
they used to have working here wrote it was simply char * imageString = new
char[15000]; :( ouch) The code is riddled with calls like this (just
make the buffer big enough we would never (well almost never) have to worry
about it overflowing...trying to fix these up :)
Thanks for everyone's feedback, I will definitely be looking back over a
couple functions where we attempted to force the use of CStrings where the
char * is probably a lot easier to use.

"Tom Serface" <tserface@xxxxxxx> wrote in message
news:u89Ox$bpGHA.4960@xxxxxxxxxxxxxxxxxxxxxxx
Hi Arlis,

In this case you may want to just continue using regular old pointer.
There's nothing wrong with it. Trying to jury rig it into a CString or
CByteArray or any collection class may just be more trouble than it's
worth. You can certainly allocate memory from the heap using 'new' and
return it using 'free' and that works just fine. These articles might be
interesting to you:

http://www.fredosaurus.com/notes-cpp/newdelete/50dynamalloc.html
http://cplus.about.com/od/beginnerctutorial/l/aa072502a.htm

Tom


"Arlis Rose" <arlisATendevouraerospace.com> wrote in message
news:eT$HVJbpGHA.3820@xxxxxxxxxxxxxxxxxxxxxxx
Thanks everyone, looks like most of the posts are saying the same thing,
CString is not really what I want to be using in this case (which
thankfully means that I hadn't been using the CString wrong (just using
the wrong structure)). I will look into the CByteArray (and CArray) and
see if I can get one of them to work for me.
BTW - someone asked why I am reading a jpeg into a CString...well I have
to read it into some form of structure as I need to convert the 8 bit
data to 7 bit, then chop the data into 62 byte segments so I can send
them across a satellite network (the network is like old hayes modems it
will not accept any character from 0-20 (decimal value) so I have to do a
bunch of conversions and modifications to send the data - it also only
accepts 63 byte packets).
The program works great using the char * but (as per prior advice) I am
trying to remove these from my code as I don't know the size of the
structure I am reading in until the read operation is to be performed (it
is dynamic) so I wanted to use the simplicity of CString which
automatically expands the memory allocation as it is used. Hopefully
CByteArray or CArray will do the same thing for me.
Arlis



Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: recvfrom returns with an error code of 14, EFAULT "Bad Address"
    ... >ok I did get it to work, the problem was that I set the char* to NULL, ... and you'll be scribbling over random memory. ... If it were intended to allocate ... >memory think when the pointer was set to the what recv was ...
    (comp.unix.programmer)
  • Re: [PATCH 10 of 20] ipath - support for userspace apps using core driver
    ... The memory that we allocate with dma_alloc_coherent is indeed being ... char device's release method is called. ... so I conclude that the struct pages are leaking. ...
    (Linux-Kernel)
  • Re: printf
    ... >>> portion of memory. ... char *p; ... is that string literals are not writable, ... >>> You still have to allocate p. ...
    (comp.lang.c)
  • Re: Strange malloc problem
    ... Chris Dollin wrote: ... What does "does not allocate the memory mean"? ... ways of checking how much memory you have left. ... unsigned char * lcdata; ...
    (comp.lang.c)
  • Re: replacing unsigned char * with CString
    ... allocating memory just seems...well wrong to me:S I think the problem is I ... Basically the reason I like CString so much is that I have needed to have ... In the example I gave below the char * (if allocated the same way I do my ... having to dynamically allocate the memory myself) and this just isn't either ...
    (microsoft.public.vc.mfc)