2013, Thursday September 19
By A.Bouchez on 2013, Thursday September 19, 11:41
We all know that the first Delphi
for Android was just released...
I just found out
an amazing alternative, using native Android controls, and FPC/Lazarus as
compiler and IDE.
It creates small .apk file: only 180 KB, from my tests!
It makes use of
direct LCL access of Android native controls, so it is a great sample.
2013, Wednesday July 24
By A.Bouchez on 2013, Wednesday July 24, 11:01
I'm currently fighting against out of memory errors on an
heavy-loaded Java server.
If only it had been implemented in Delphi and mORMot!
But at this time, the mORMot was still in its burrow.
Copy-On-Write and a good heap manager can do wonders of stability.
Here are some thoughts about Garbage Collector, and how to temper
They may apply to both the JVM and the .Net runtime, by the way.
2013, Tuesday May 21
By A.Bouchez on 2013, Tuesday May 21, 08:55
Apart from being very slow during compilation, the Delphi NextGen
compiler introduced a new memory model, named ARC.
We already spoke about ARC years ago, so please
refer to our corresponding blog article for further information, especially
about how Apple did introduce ARC to iOS instead of the Garbage
About how ARC is to be used in the NextGen compiler, take a look at Marco's
blog article, and its linked resources.
But the ARC model, as implemented by Embarcadero, has at least one huge
performance issue, in the way weak
references, and zeroing weak pointers have been implemented.
I do not speak about the general slow down introduced during every class/record
initialization/finalization, which is noticeable, but not a big concern.
If you look at XE4 internals, you will discover
a disappointing global lock introduced in the RTL.
2013, Sunday May 19
By A.Bouchez on 2013, Sunday May 19, 13:24
One quick Sunday post,
from a comment I wrote in a blog article.
I'm always wondering why a lot of programmers tend to implicitly assume that
"the shorter source code, the better".
It is true when it means that with proper code refactoring, making small
objects with dedicated methods, the code of your methods will be smaller.
It is true when you do not like to write as a "Copy & Paste" coder, without
searching to put common code in shared places.
But is it true at the language level?
I mean, is it just because your ARC or GC model allow you not to manage the
object memory, that it is always better?
Just some ideas...
2013, Saturday May 11
By A.Bouchez on 2013, Saturday May 11, 10:59
When I first read the
technical white paper covering all of the language changes in XE4 for mobile
development (tied to the new ARM LLVM-based Delphi compiler), I have to
confess I was pretty much confused.
Two great mORMot users
just asked for XE4/iOS support of mORMot.
Win32/Win64 support for XE4 will be done as soon as we got a copy of
I suspect the code already works, since it was working as expected with XE3,
and we rely on our own set of low-level functions for most internal work.
But iOS-targetting is more complex, due to the NextGen compiler, mainly.
2013, Monday April 22
By A.Bouchez on 2013, Monday April 22, 07:34
You perhaps know that I'm not a big fan of the
RAD DB approach for end-user applications.
They are easy to define, almost no code to write, and you are able to publish a
working solution very fast.
But it is a nightmare to debug and maintain. I prefer the new
DataBinding feature, or... of course... ORM!
In mORMot, we have some auto-generated screens, and in our roadmap, we
forcast to use some auto-binding features, using a KISS by-convention MVC
For some users, we made a ORM /
TDataSet conversion unit.
And we discovered that
TDataSet has a weird, and very
misleading definition of its
AsString property, for Unicode
versions of Delphi.
2013, Tuesday March 26
By A.Bouchez on 2013, Tuesday March 26, 20:20
On the Embarcadero
forums, some user did have a perfectly sane reaction, about a non obvious
integer type cast like
Int64Var := Int32Var*Int32Var, which may
We've got to stop becoming, as one poster put it, "human pre-compilers"
The compiler ought to have the common sense to not need the programmer to cast
the two integer values.
I respectfully think just the opposite.
Such a type cast is part of the language grammar.
If you know the grammar, you will know how it will be compiled.
To be honest, you have the same in all languages, with more or less range
checking, optimization, and implicit conversion.
This is why I like Delphi: it can be mastered by any programmers, whereas truly
mastering Java or .Net needs a genius.
Delphi is just... human...
2013, Wednesday March 13
By A.Bouchez on 2013, Wednesday March 13, 13:18
We have included x64
optimized asm of
Move() for Win64
- for corresponding compiler targets, i.e. Delphi XE2 and XE3.
It will handle properly cache prefetch and
appropriate SSE2 move
System.pas unit of Delphi RTL will be patched at startup,
NOX64PATCHRTL conditional is defined.
Therefore, whole application may benefit for this optimized version.
Performance improvement is noticeable, when compared with the original
pascal-based version included in
By the way, the Delphi x64 built-in assembler does not recognize
movnti opcode... so we had to inline it as plain
db hexadecimal values.
A bit disappointing. Until now, we did not suffer from anything in regard to
the x64 compatibility at Delphi level.
No stand-alone unit available yet, since it is included in our
SynCommons.pas shared unit, starting with the 1.18 revision of
Feedback is welcome, as usual!
2012, Thursday December 20
By A.Bouchez on 2012, Thursday December 20, 11:14
On our forum, a clever question was posted
about publishing some enhanced RTL functions for newer versions of Delphi - as
we did for
Delphi 7 and 2007.
I was looking for a faster IntToStr implementation and discovered
That's really too bad,
SynCommons.pas really does contain some
seriously fast stuff, people would greatly benefit from it if it was made
In fact, it would not be enough to change the RTL function
IMHO, to write something scalable, you need to get rid of such
2012, Tuesday November 13
By A.Bouchez on 2012, Tuesday November 13, 10:54
Do you know the Go language
It is a strong-typed, compiled, cross-platform, and concurrent.
It features some nice high-level structures, like maps and strings, and still
have very low-level access to the generated code: pointers are there, in a safe
strong-typed implementation just like in pascal, and there is even a "goto",
which sounds like an heresy to dogmatic coders, but does make sense to me, at
least when you want to optimize code speed, in some rare cases.
It is created/pushed by Google, used internally by the company in their
computer farms, and was designed by one of the original C creators.
2012, Thursday October 18
By A.Bouchez on 2012, Thursday October 18, 10:51
A very interesting comment by
mpv in our forum highlighted some points about potential interface (ab)use:
IMHO: Idea is good, but "the devil is in the details". To use mocking I must
use interfaces. When I use interfaces I lost control on code, because I don't
see implementation. Debugging an optimization became very hard. Especially if a
beginner developer read something like GOF (Gang Of Four) and wherever
necessary and where not use design templates like Visitor, Decorator and so on,
and in debugging I don't understand at all what class actually implement passed
interface. As for me, this is a biggest problem for .NET framework - developers
use interfaces, don't look on implementation (and often don't have it in
sources at all), do not learn by reading someone else's code and therefore
produce monkey-code. This is only IMHO...
Could sounds rude, and like a trolling subject, but I perfectly understand
this point of view.
Introducing stubs and mocks
in mORMot was not the open door to all problems.. but,on the contrary,
to help write robust, efficient, and maintainable code.
It does not mean that using interfaces and C#/Java is the root of all evils and
code inefficiency, but that it may lead into problems.
2012, Saturday October 6
By A.Bouchez on 2012, Saturday October 6, 14:38
In Delphi, you have several ways of handling data life time, therefore
several ways of handling memory:
- For simple value objects (e.g.
byte integer double
shortstring and fixed size arrays or
record containing only such types), the value is copied in
- For more complex value objets (e.g.
string and dynamic
record containing such types), there is a reference
counter handled by each instance, with copy-on-write feature and
compiler-generated reference counting at code scope level (with hidden
- For most
class instances (e.g. deriving from
TObject), you have to
each instance, and manage its life time by hand - with explicit
class deriving from
RefCount property, with
methods (this is the reference-counted COM model), and you can use Delphi
interface to work with such instances - see this blog article.
With Delphi XE3, we were told that some automatic memory handling at
class level are about to be introduced at the compiler and RTL
Even if this feature is not finished, and disabled, there are a lot of changes
in the Delphi XE3 Run Time Library which sounds like a
preparation of such a new feature.
2012, Thursday August 30
By A.Bouchez on 2012, Thursday August 30, 08:52
Apart the sad
and concerning license change issue (which has been confirmed by David I.
himself), XE3 has some features, in order to support Windows 8 new
'tile-based' interface (formerly known as "Metro").
Windows Runtime, or WinRT (not to be confused with
Windows RT, which is a tablet manufacturer only version of Windows
8) is a cross-platform application architecture on the Windows 8 operating
WinRT supports development in C++/CX (Component Extensions, a language
based on C++) and the managed languages C# and VB.NET, as well as
WinRT applications natively support both the x86 and ARM
architectures, and also run inside a sandboxed environment to allow for greater
security and stability.
WinRT will also be part of the upcoming Windows Phone 8 operating
It has been clearly stated that only Microsoft compilers and
runtime libraries (RTL) will be able to have full access to the low-level API
needed to create a decent RTL.
This has been done for security reasons, but it won't allow third-party JIT or
compilers to work as expected. Only Microsoft's C++ and C# compilers / virtual
machines have access to the needed API. Even if you do not have a JIT in your
language (Delphi is compiled and do not have any virtual machine), you would
need to access to some low-level API calls e.g. to mark some memory block as
executable (e.g. for virtual
Delphi is not able to have native support of WinRT, due to this
This is a known fact, but let us tell about "Windows 8 sideloading" feature,
available with XE3.
In short, even if you do not have 100% WinRT application, XE3
"Metropolis" (sic) styled Desktop applications have some potential to
behave like native UI applications, even if not being
2012, Tuesday August 28
By A.Bouchez on 2012, Tuesday August 28, 08:07
Here is some unbelievable news retrieved from "Te Waka o Delphi" blog:
From XE3 onwards, your Delphi Professional EULA
will prohibit you from using Delphi Professional for anything other than local
If you want to build client/server database applications using Delphi
Professional, you will be required to purchase a “Client/Server Add-On”
This goes beyond the fact that you do not get (or can otherwise use or install)
client/server drivers for the DBExpress or other “built in” data access
frameworks, but extends even to 3rd party data access technologies.
That is, whatever you may be able to do or achieve – technically – using some
3rd party component or library with you Delphi Professional compiler, you
cannot legally create a client/server application.
Never mind any 3rd party components or libraries, this same prohibition will
apply even if you are using naked, unadorned Microsoft ADO.
Damn show-stopper for me.
Embarcadero is killing Delphi.
Our very own mORMot Open-Source framework is fully Client-Server
oriented, and allow creating scalable Client-Server applications even with an
Oracle DB system back-end, even with XE2 starter edition (direct access,
without any DB.pas / DBExpress layer).
2012, Monday June 18
By A.Bouchez on 2012, Monday June 18, 22:06
The memory allocation model of the Delphi
interface type uses
some kind of Automatic Reference Counting (ARC). In order to avoid
memory and resource leaks and potential random errors in the applications (aka
EAccessViolation exception on customer side) when
interface, a SOA framework like mORMot has to offer
so-called Weak pointers and Zeroing Weak pointers
Note that garbage collector based languages (like Java or C#) do not suffer
from this problem, since the circular references are handled by their memory
model: objects lifetime are maintained globally by the memory manager. Of
course, it will increase memory use, slowdown the process due to additional
actions during allocation and assignments (all objects and their references
have to be maintained in internal lists), and may slow down the application
when garbage collector enters in action. In order to avoid such issues when
performance matters, experts tend to pre-allocate and re-use objects: this is
one common limitation of this memory model, and why Delphi is still a good
candidate (like unmanaged C or C++ - and also Objective C) when
it deals with performance and stability.
2012, Wednesday June 13
By A.Bouchez on 2012, Wednesday June 13, 06:41
It is pretty useful, in some cases, to retrieve a
instance from a given
You should better use
interfaces in your business logic, but having access to the underlying
implementation is needed at lower level.
Beginning with Delphi 2010, you are able to use the
operator, e.g. via
aObject := aInterface as TObject or
aObject := TObject(aInterface).
This operator use a special hidden interface GUID (
retrieve the object instance, calling an enhanced version
But if you want to maintain compatibility with older version of Delphi (as
we want for mORMot to work with the beloved Delphi 6 or 7), you'll
have to find a way.
2012, Monday May 28
By A.Bouchez on 2012, Monday May 28, 09:15
In a very nice (like always) blog post, trolling
comments were dispatched about the "native" concept:
From the technical point of view, both assertions are false.
The article was subtitled: "Say a Lie Often Enough and You’ll Start
Believing it Yourself
At least, it is a trolling subject.
It remembered me about some of my past studies, i.e. five years of
university studies in Medieval Theology in Italy and France (yes, I know, this
is strange background for a Delphi programmer):
"Stat Roma pristina nomine, nomina nuda tenemus"
Our modern world is not thinking any more, it is sinking into nominalism, whereas IMHO the
scientific approach is more compatible with a realistic
approach of universals.
Today, marketing is everything.
Is it a necessary
2012, Sunday May 20
By A.Bouchez on 2012, Sunday May 20, 09:47
In a Stack Overflow
question, someone asked about some nested procedure call he found out. That
is, a procedure inside another procedure.
He found out this coding style to be messy, which sounds like a reasonable
opinion. But his alternative proposal of putting the internal procedure outside
the main one, i.e. making it global, is IMHO even worse.
In some case, a private
class, or even
object with methods is an handy and maintainable implementation
2012, Thursday April 19
By A.Bouchez on 2012, Thursday April 19, 06:23
Did you hear from the great Smart project?
It is an IDE and some source runtime able to develop and compile an
It does target AJAX Mobile application creation (i.e. Android and
iPhone/iPad apps running Web-Kit).
You'll get an unique
.html file containing the whole client-side
application: it won't need any server side implementation. Using a third-party
tool like PhoneGap, you'd be able to supply your customers with true
native applications, running without any network, and accessing the full power
of any modern Smart Phone.
Smart is a great candidate for implementing rich client-side AJAX
applications, to work with our client-server mORMot framework.
In order to interface Smart code with mORMot, we started
implementing some low-level code to work with our RESTful
So we'll need to implement some Smart dedicated Open Source code
implementing crc32 and SHA-256 hashing.
2012, Tuesday April 10
By A.Bouchez on 2012, Tuesday April 10, 11:53
One potential issue with Delphi coding, is about how the result of a
functions are implemented.
If you forget to set a
result value to a function, you'll
get a compiler warning.
Never underestimate such warning: IMHO this is not a warning, but an error.
And you should better be aware of the handling of reference-counted types
string) in a function results: those are passed the stack as
var parameters, so the result of a function may be set
even if an exception is raised during function execution!