On 19.08.2012 16:19, Oto BREZINA wrote:
> Finally I have some spare time so I start with some work on T-Merge
>
> 1.
> Do you know if "CStringA sLine = CStringA(sLineT)" is internally using
> *WideCharToMultiByte*
> <http://msdn.microsoft.com/en-us/library/windows/desktop/dd374130%28v=vs.85%29.aspx>?
> What is for "CStringA(sLineT)" conversion here?
yes, it does, via some c-runtime functions.
But this conversion is utf16 to ansi, not utf8.
why do you ask?
> 2.
> I don't use STL much what is your preferred container for BYTE array,
> according some webs candidates are:
> CStringA - have count, operator [], copy on write, but may be
> missleading of use
> vector - have count and []
> unique_ptr - have [], but lack count
it depends on your use case.
for example, if you don't need [] access but only iteration, use a deque
instead of a vector - especially for big arrays.
> 3.
> Thru code I have seen lot of *ptr++ based algos (sometimes in unnatural
> way for me), are those quicker then based on ptr[]?
> According some quite old optimalisation guide ptr[] could be faster
> becouse of less increment instructions, and simpler cache management,
> however it was in about '97.
> Do you have any real performance tests/data - I tried to run my own, but
> I was unable to start performance tests as I'm not admin ... will try
> again later.
ptr incrementations can be faster than index based access, usually when
using std containers.
> 4.
> I would like to write filters classes for ASCII, UTF8, UTF16BE, UTF16LE
> and add UTF32s reads/writes. Do you have/know any preferred
> interface/template for that job?
why? such filter classes would be good for streams, but we don't use
streams in TMerge but load the files completely in one go.
> 5.
> Have you any specific reason to not support UTF32, or just too small use
> cases.
Is there even a tool/app/whatever that writes such files?
I've never seen such a file myself.
So why implement something that won't be used?
> Have you any reason to not support other EOLs? According
> http://en.wikipedia.org/wiki/Newline only NEL seems be questionable.
actually, yes: the svn diff library doesn't support them, so supporting
them in TMerge makes no sense. We could split the lines there, but the
diffing engine would treat those as one line and so the diff would be
shown wrong.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2999453
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-08-19 20:33:23 CEST