Re: [fpc-devel] String and UnicodeString and UTF8String
On 01/11/2011 11:10 AM, Hans-Peter Diettrich wrote: UTF-8 combines an single (byte-based) storage type with lossless encoding of full Unicode. Ansi and UCS2 (really UTF-16) only *look* easier to handle in user code, but both will fail and require special code whenever characters outside the assumed codepage may occur. Preface: I don't write international apps, and probably won't for the foreseeable future... Isn't all of this concentration on trying to make strings have single byte characters (who cares how they are encoded), using the argument that it is somehow faster, incorrect for just about any modern processor, including embedded CPU's such as ARM? It was my understanding that 32 bit aligned access was always faster than byte aligned access on just about any CPU FPC still supports. The argument holds just fine for memory, but I don't really get the speed argument. Maybe I'm missing something. Jeff. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Matt Emson wrote: I would also agree. I used to use Interfaces or raise shared classes/declarations to a new unit both could use to overcome this issue myself. But I remember the Be GUI porters having loads of issues mimicing the Be API header structure because there were so many forward class declarations in the C++. It was impossible to do a unit to header file match because circular dependencies crept up at almost every turn. Without direct matching of header and unit names, the Be API documentation became hard to use. I don't know if they ever solved it, maybe if Olivier is still about, he can chime in? I would think any time you have two objects that need bidirectional access of any sort that you would need to define an connector object to make this link, so the data or functions that needs to be shared between the two don't reside in either object, but in the connector object. Because if the data or functions are needed by both, they really aren't a part of either, it is its own thing and should have its own object. Or maybe I'm not seeing the problem properly. I just know that the few times I've hit on the circular unit problem where A needed to know about B, and B needed to know about A, that's how I've solved it, by making another unit C with the parts that needed access and pointing both A and B to that new unit. Maybe my problems were trivial, though. I'm certainly no OOP expert. Jeff. -- I haven't smoked for 3 years, 4 months and 2 weeks, saving $5,572.94 and not smoking 37,152.94 cigarettes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
Michael Schnell wrote: Again something inspired by Delphi-Prism ? ( http://prismwiki.codegear.com/en/Lambda_Expressions ) Wow, talk about unreadable code... I'm all for saving typing, but not at the expense of readability. This reminds me of C's oddball ? operator. One of the reasons I like Pascal is that you do usually have to spell out what you are doing. It makes reading the code months or years later, or reading someone else's code much easier. So it might not be the most efficient in terms of typing, or even compilation or execution, but the savings in maintenance more than make up for it. The examples given at that site would drive me crazy. I don't believe I'll be using Prism any time soon. Jeff. -- I haven't smoked for 3 years, 2 months and 3 days, saving $5,222.69 and not smoking 34,817.99 cigarettes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode support in RTL - Roadmap
Martin Friebe wrote: I must agree with the FPC can not to it all automatically line (as much as I regret, and admit the beauty there was, if fpc could). What I mean is: 1) Any Application/Program, that currently compiles and works (using none utf8, never mind if ascii or ansi) will keep working, if compiled using *none* utf8 mode. This is reasonable. It also implies that perhaps what everyone is trying to do is impossible. With plain strings, or Ansi strings, we have code that works today. If you change any of those to UTF*, then code that uses things such as SetLength, Length, stringvar[index], copy(string, index, count), pos etc. cannot work 100% reliably. You don't know what the programmer wants when he says stringvar[3]. Does he mean the third character in the string? Or the third byte in the memory array represented by the string (perhaps he was using a string as a buffer)? If you assume one or the other, when one element of a string doesn't equal one byte, half of the time you'll be wrong, it doesn't matter which UTF type you are using, what locale you are in, or anything. It almost seems to me, that if you want to use UTF strings as the default, you should either throw errors or at least stern warnings on any use of Length, SetLength, stringvar[index] et all and force any code using them to be rewritten with UTF variants. It would make more sense to knowingly say all code using such constructs is broken in a Unicode environment than to leave it to chance that the way the code now interprets these constructs is the way the coder originally intended. I know much of my code would break just using AnsiString as opposed to the original counted string. For me, *any* UTF* version discussed here would break it even more. I don't have any need for Unicode, so feel free to ignore anything I say. But I don't want my code breaking in unpredictable ways, either, because the underlying string types change on me behind my back (ie, in the RTL/FCL). Jeff. -- I haven't smoked for 2 years, 3 months and 1 week, saving $3,736.95 and not smoking 24,913.01 cigarettes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] help with softfloat for arm big endian crosscompiler
Micha Nelissen wrote: I'm using an XScale armeb (big-endian) debian distribution here at work. The DigiConnect ME and WI-ME modules run ARM7 big endian as well. Not sure about the other Digi modules. There is a linux implementation for these as well as their native Net+OS. Jeff. -- I haven't smoked for 3 months, 3 weeks and 5 days, saving $533.11 and not smoking 3,554.09 cigarettes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
