Re: QCString construction

--===============1704707408==
Content-type: multipart/signed; boundary=nextPart65072072.BA4EaRiqPz;
 protocol="application/pgp-signature"; micalg=pgp-sha1
Content-transfer-encoding: 7bit

--nextPart65072072.BA4EaRiqPz
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Saturday 10 February 2007 02:16, David Faure wrote:
> This leads me to 3 patches.
>
> One for kmail, I wrote a utility function for creating a QCString
> from char*+size, and used that when creating a QCString from a
> DwString where it matters (i.e. where I found pretty large strings to
> be used when attaching large files).

The related changes look good. I'm just wondering why you didn't add
  QCString CString( const DwString & str )
instead of (or additionally to)
  QCString CString( const char* str, size_t strLen )
?

This would allow us to do
=2D  return asDwString().c_str();
+  return KMail::Util::CString( asDwString() );
instead of
=2D  return asDwString().c_str();
+  const DwString& asString =3D asDwString();
+  return KMail::Util::CString( asString.c_str(), asString.length() );

> Can a kmail developer review the change to KMMessage::asString() and
> asSendableString(), too? It avoids a asString() (Assemble) and a
> fromString (Parse), but I hope it's doing the right thing.

I am very uneasy about those changes because completely different things=20
happen when you copy a message and when you create a message from a=20
string. If we had unit tests... But as it stands I'm against those=20
changes.

Regards,
Ingo

--nextPart65072072.BA4EaRiqPz
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBFz4g+GnR+RTDgudgRAh5UAJ98r0RVOgOsHvhDoNvU4QMth/PTUACfa8AB
kEytu8WGNNanlq8cXtZdqig=
=3Mqz
-----END PGP SIGNATURE-----

--nextPart65072072.BA4EaRiqPz--


--===============1704707408==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
KMail developers mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kmail-devel

--===============1704707408==--