Synopse Open Source - Tag - CrossPlatform - CommentsmORMot MVC / SOA / ORM and friends2024-02-02T17:08:25+00:00urn:md5:cc547126eb580a9adbec2349d7c65274DotclearMac OS X Stack Alignment, asm and trolls - A. Bouchezurn:md5:3c5ef51e7b9ace6cc08bc88742a7f8db2010-04-05T13:16:36+02:002010-04-05T12:16:36+02:00A. Bouchez<p>Thanks Chris for your comment back!</p>
<p>About "Unicode", that was exactly what I said about "true lye"... Unicode is
not only an encoding (i.e. how many glyphs you can put in 32 bits), but a whole
standard system. That's why I spoke about diacritics.</p>
<p>Delegates are easy to use for User Interface, very pleasant to write as a
code sample in a blog, but I'm not sure it is so good at multi threading for
example. For a real app I mean... classes and methods are a cleaner approach if
you have a lot of parameters to pass through your thread proc, or want to share
the same data among threads.</p>
<p>I suggest you should at least take a look at the free pascal forum archive,
and all the debates about the EMB way of evolving the language. It always
sounded to me less marketing in there, and more technical than the approach
used by Codegear/Embarcadero. Saying FPC team follows EMB is not true. FPC was
one of the first 64 bits compiler available for the Win64 platform. And what
about the new multi-threaded FPC heap, available by default since version 2.4?
Or their WideString approach (see next paragraph)? Or their package system for
the units?<br />
It sounded to me that EMB greatest success was by embedding open source or
third-party components (like FastMM4, FastCode, PNG, GIF, ribbon...). Datasnap
is powerfull, but you can get the same with FPC, and perhaps even more
powerfull...</p>
<p>Why are you saying the FPC's approach of Unicode is a mess? From the
compiler point of view, it is not. There is no possible hidden conversion like
with Delphi 2009/2010. Widestring in FPC were handled in a "Delphi 2009/2010
UnicodeString" way, since the beginning... IMHO the FPC team was right by not
following Codegear in the OLE string mapping for their WideString... In fact, I
think the FPC WideString was the first true fast unicode compiler for the
object pascal language, with 100% compatibility with AnsiStrings, some years
before Delphi 2009 was released.</p>
<p>I didn't speak about the Delphi 2010 RTTI. Why didn't EMB make the compiler
generate better code (like for the CopyRecord system procedure - see <a href="http://blog.synopse.info/post/2010/03/23/CopyRecord-faster-proposal" title="http://blog.synopse.info/post/2010/03/23/CopyRecord-faster-proposal" rel="ugc nofollow">http://blog.synopse.info/post/2010/...</a>
), instead of making the app code size grow so much? For our ORM approach - see
<a href="http://blog.synopse.info/category/Open-Source-Projects/SQLite3-Framework" title="http://blog.synopse.info/category/Open-Source-Projects/SQLite3-Framework" rel="ugc nofollow">http://blog.synopse.info/category/O...</a>
- we would like a wider RTTI support than the one available since Delphi 7, but
not at the expense of code size.</p>Mac OS X Stack Alignment, asm and trolls - Chrisurn:md5:134fec06e1f52439ee9b929bd7405f952010-04-04T01:33:05+02:002010-04-04T00:33:05+02:00Chris<p>'Saying Windows is natively "Unicode" is another true lye: it is
UTF-16.'</p>
<p>The term 'unicode' is not a synomym for UTF-8 - rather, it it's an umbrella
term that encompasses UTF-8, UTF-16LE, UTF16-BE, UCS-4... More exactly, these
are all 'unicode encodings' - no one is more 'unicode' than the other.</p>
<p>'About cross platform, Free Pascal Compiler has a better approach than EMB,
and is now much more advanced than the Delphi owner for that.'</p>
<p>What do you mean by 'more advanced'? Surely 'supports a wider range of
platforms' isn't the only yardstick for this. Does FPC support closures, for
example? Generally, my impression is that FPC and DCC have just evolved in
different ways.</p>
<p>'So here is my proposal: why couldn't Embarcadero people use the Free Pascal
Compiler as their internal compiler?'</p>
<p>IMO, the key stengths of Delphi at the off were made possible by Borland's
complete control over the compiler. By which I mean, pretty much every change
between the old Borland Pascal dialect and the new Delphi one was to make the
VCL and its associated design-time support possible (e.g. the new object model,
exceptions, RTTI - all stuff FPC simply copied). To say 'good bye' to doing
something similar in the future would lose a key commercial advantage - cf.
Microsoft with C#, or even Apple with Objective C - being able to control your
own language is hardly an outmoded idea. (I'm assuming, of course, that the FPC
folks would not simply accept Embarcadero requesting the language evolve in a
specific direction, or even have a certain feature added to it, simply because
this fitted Embarcadero's needs.)</p>
<p>Personally, I also disagree with you about D2009+'s vs. FPC's contrasting
approaches to Unicode - to me, it's FPC's approach that is a mess. The rights
and wrongs of Embarcadero's decisions here have been debated to death already
though...</p>Mac OS X Stack Alignment, asm and trolls - A. Bouchezurn:md5:2d05687d5045650d58b3ab10d1c29ea02010-03-28T12:52:54+02:002010-03-28T11:52:54+02:00A. Bouchez<p>Another point about Unicode:<br />
I really find the EMB Unicode approach not worth it: from the VCL point of
view, it was a need, but from the language and compiler point of view, it's a
mess.<br />
I really didn't get there point, why they just didn't want to use UTF-8
encoding instead of UTF-16. And don't speak about character index in
UnicodeString, if you know what unicode is, you know about diacritics, UTF-32
(i.e. true Unicode) and such. Saying Windows is natively "Unicode" is another
true lye: it is UTF-16. Converting from/to UTF-8 is not noticeable (because of
the L1 cache of our modern CPU) than using the hidden slow conversions
introduced with Delphi 2009. I really don't like the hidden API calls, like
WideCharToMultiByte() and such, introduced since Delphi 2009 RTL. Using UTF-8
encoding as default should have been enough for the VCL to be "Unicode-ready",
as marketing says...</p>