[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: urlstring testing/enhancement
From: |
Federico Montesino Pouzols |
Subject: |
Re: urlstring testing/enhancement |
Date: |
Thu, 30 Jan 2003 12:30:24 +0100 |
User-agent: |
Mutt/1.4i |
On Thu, Jan 09, 2003 at 05:16:39PM -0800, Chad Yates wrote:
> before I post a patch to add the new STL string functions I was wondering if
> somebody knew the prefered way of dealing with excessive temporaries. see
> the following:
>
> /** @relates URLStream
> * Encode a octet stream using base64 coding into a STL string
> * @return base 64 encoded string
> * @param src source buffer
> * @param srcsize source buffer size
> */
> CCXX_EXPORT(std::string) b64Encode(const unsigned char *src, size_t srcsize)
> {
> size_t limit = (srcsize+2)/3*4+1;
> char* buffer = new char[limit];
>
> unsigned size = b64Encode(src, srcsize, buffer, limit);
> buffer[size] = '\0';
>
> std::string final = string(buffer);
> delete buffer;
> return final;
> }
>
> notice that I have to not only allocate a temporary buffer (since the
> b64Encode function doesn't work with strings directly -- or some kind
> streaming), but I have to make a copy before I unallocate it, and then yet
> another on the actual return by value. I have yet to delve into the realm
> of autoptr's. is that the best bet? if so, the stl autoptr, or does common
> c++ have a better one.
I guess there is no good solution for this. The first copy
seems unavoidable and the second one, as far as I know, could only be
avoided if the core routine operated over a string object instead of
the array of char, but that would be a lot worse. Well, after all, you
loose some performance, but you can save significant space :).
Also, what about adding an encode method that takes a string
object as argument.
>
> thanks,
>
> Chad
>
>
>
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp