Board index » kylix » Re: Cross Platform Development

Re: Cross Platform Development


2005-07-30 12:01:15 AM
kylix1
Sorry, "create" should be read as "great" :)))
"Dmitry" < XXXX@XXXXX.COM >wrote in message
Quote

>At the moment the new tool reads the xml files of doxygen and I'm
>currently writing a framework that allows an easier usage of the
>information (all symbols are resolved). So I'm at step 2 of 4 (1:read
>xml,
>2:convert to internal data structs, 3:generate C++ wrapper files,
>4:generate Delphi import unit)

If i right undestand your tool, in theory, make it possible to port ANY
C++ Framework to flat API and it
will may use in Delphi-Kylix? If it so, that is create!


"Andreas Hausladen" < XXXX@XXXXX.COM >wrote in message
news:42ea2756$ XXXX@XXXXX.COM ...
>Dmitry wrote:
>
>>Hello, why this technique doesn't works for Qt4? Can you share more
>>details?
>
>The Qt3 for Kylix code was generared by the Qt# generator which I
>modified
>a lot. It uses doxygen for parsing C++ files what is not bad but
>unfortunatelly it is limited to doxygen 3.6 (we are now at 1.4x) and it
>does a lot thing on demand (finding out if a method is overloaded,
>virtual, override, ...). On the other had using doxygen limits you to one
>directory structure. But Qt4 has QtCode, QtGui, QtXml, ... and the most
>hurting one Qt3support. This causes types/function to be duplicated and
>the hash tables in CGen (the Qt# generator) stops with an excpetion.
>Furthermore it is not possible to add further APIs that are based on
>another API like QtGui requires QtCore.
>
>My new attempt still uses doxygen (writing a C++ parser is not that easy
>and doxygen 1.41 returns good results). But it allows you to plug in
>further depending APIs like QtGUI based on QtCore and then KDE4Lib. It
>should also work with Qt3.
>At the moment the new tool reads the xml files of doxygen and I'm
>currently writing a framework that allows an easier usage of the
>information (all symbols are resolved). So I'm at step 2 of 4 (1:read
>xml,
>2:convert to internal data structs, 3:generate C++ wrapper files,
>4:generate Delphi import unit)
>
>--
>Regards,
>
>Andreas Hausladen
>(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
>(andy.jgknet.de/blog)


 
 

Re:Re: Cross Platform Development

Jonathan Benedicto wrote:
Quote
So I would have to make the library export all these a extern "c"
functions, then I'd have to write Pascal "wrapper" classes ?
Exactly.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(andy.jgknet.de/blog)
 

Re:Re: Cross Platform Development

Jonathan Benedicto wrote:
Quote
I had to do this so that the library would work across c++ compilers.

I'm afraid that I'm completely ignorant when it comes to Pascal.
That is not only a problem of Pascal compilers. It is also a problem
between different compiler vendors and even between different compiler
versions: gcc 2.95 vs. gcc 3.x
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(andy.jgknet.de/blog)
 

{smallsort}

Re:Re: Cross Platform Development

"Andreas Hausladen" < XXXX@XXXXX.COM >wrote in message
Quote
Exactly.
Thank you very much for this info. I guess I'll have to use your tool once
the library is completed. <g>
Jonathan
 

Re:Re: Cross Platform Development

Quote
You are right, I forgot about that. Chrome definately would be another route.
Of course with this route you have to live without VCL/CLX, and use the
.net classes directly.

There is an open source project that provides a library for more easy
porting Delphi projects. Maybe this might help.
-Michael
 

Re:Re: Cross Platform Development

"Michael Schnell" < XXXX@XXXXX.COM >wrote in message
Quote
>You are right, I forgot about that. Chrome definately would be another
>route.
>Of course with this route you have to live without VCL/CLX, and use the
>.net classes directly.

There is an open source project that provides a library for more easy
porting Delphi projects. Maybe this might help.
If I want to target .NET/MONO, why wouldn't I just use the existing Delphi
compiler?
Dan
 

Re:Re: Cross Platform Development

Quote
>You are right, I forgot about that. Chrome definately would be another route.
>Of course with this route you have to live without VCL/CLX, and use the
>.net classes directly.
>

There is an open source project that provides a library for more easy
porting Delphi projects. Maybe this might help.
That's ShineOn, and it aims to provide the Delphi *RTL* for Chrome.
No visual VCL components.
Simon
 

Re:Re: Cross Platform Development

Quote
"Michael Schnell" < XXXX@XXXXX.COM >wrote in message
news:42ea9dfc$ XXXX@XXXXX.COM ...
>>You are right, I forgot about that. Chrome definately would be another
>>route.
>>Of course with this route you have to live without VCL/CLX, and use the
>>.net classes directly.
>
>There is an open source project that provides a library for more easy
>porting Delphi projects. Maybe this might help.

If I want to target .NET/MONO, why wouldn't I just use the existing Delphi
compiler?
Well, for Chrome, Mono is a supported target, for Delphi 2005 it isn't. With
some tweakings it's possible to get Delphi Winforms applications (not VCL.NET)
to run under Mono, but with Chrome you actually get support on it from the
vendor.
Still, personally I'm not really interessted in Chrome as I'm not interested
in .NET/Mono. I want my applications to be native and fast.
Simon
 

Re:Re: Cross Platform Development

Quote
If I want to target .NET/MONO, why wouldn't I just use the existing Delphi
compiler?

In addition to Simons answer:
Delphi is not a _really_ .Net compliant tool (even D2005 for Windows).
e.g. .NET has a built-in garbage control. So you usually never do a
"free" for a component. This is done by the framework, but not "as soon
as possible" (the Delphi way) but "only when necessary" (e.g. if the
memory is needed for some other purpose. Thus D2005 creates a lot of
overhead.
e.g./2 Strings are handled by the .NET framework. But here, normal
Strings are read-only. Than means you can do "s1 := s1+s2;" but the old
s1 is (virtually) freed and a new s1 is created. but you can't do "s1[5]
:= 'A'" or "setlength(s1,10);". To do something like this you need to
use the special "stringbuilder" class that is much slower than normal
strings.
-Michael
 

Re:Re: Cross Platform Development

"Michael Schnell" < XXXX@XXXXX.COM >wrote in message
Quote
>If I want to target .NET/MONO, why wouldn't I just use the existing
>Delphi compiler?
>

In addition to Simons answer:

Delphi is not a _really_ .Net compliant tool (even D2005 for Windows).
Oh, really?
Quote

e.g. .NET has a built-in garbage control. So you usually never do a "free"
for a component. This is done by the framework, but not "as soon as
possible" (the Delphi way) but "only when necessary" (e.g. if the memory
is needed for some other purpose. Thus D2005 creates a lot of overhead
I don't think you understand how GC works in .NET and in Delphi 2005. Here
are some links for you:
homepages.borland.com/abauer/archives/2003_11_16_archive.html
This link is referenced from MS blogs where they indicate that the Delphi
method is a good approach:
weblogs.asp.net/astopford/archive/2003/11/22/39277.aspx
"... rather than modify existing Delphi code to make use of IDispose the
compiler provides the Free method to do this for you. It's interesting to
note that the compiler also controls this to prevent Free from being called
twice. I can see the real value of adding this feature to the compiler as it
provides a higher level to the programmer for clearing up."
Here's another link on the BDN site:
bdn.borland.com/article/0,1410,29365,00.html
In short, calling free doesn't invoke GC immediately; it merely lets the GC
know that the object can be cleaned up.
Quote
e.g./2 Strings are handled by the .NET framework. But here, normal Strings
are read-only. Than means you can do "s1 := s1+s2;" but the old s1 is
(virtually) freed and a new s1 is created. but you can't do "s1[5] := 'A'"
or "setlength(s1,10);". To do something like this you need to use the
special "stringbuilder" class that is much slower than normal strings.
I think this is a .NET issue and not a Delphi issue. I know things are
changing in 2.0.
Dan
 

Re:Re: Cross Platform Development

Michael Schnell wrote:
Quote

>If I want to target .NET/MONO, why wouldn't I just use the existing Delphi
>compiler?
>

In addition to Simons answer:

Delphi is not a _really_ .Net compliant tool (even D2005 for Windows).

This is wrong. Actually according to Anders H. Delphi is currently more
compliant than C# (IOW implements more of the .NET spec)
Quote
e.g. .NET has a built-in garbage control. So you usually never do a
"free" for a component. This is done by the framework, but not "as soon
as possible" (the Delphi way) but "only when necessary" (e.g. if the
memory is needed for some other purpose. Thus D2005 creates a lot of
overhead.

Wrong. In Delphi you have the choice of normal GC and deterministic freeing.
More flexibility, not less. If you choose you can not do a free and let the GC
collect it when it normally would.
Quote
e.g./2 Strings are handled by the .NET framework. But here, normal
Strings are read-only. Than means you can do "s1 := s1+s2;" but the old
s1 is (virtually) freed and a new s1 is created. but you can't do "s1[5]
:= 'A'" or "setlength(s1,10);". To do something like this you need to
use the special "stringbuilder" class that is much slower than normal
strings.

This is the .NET way. You also use StringBuilder with C# etc.
Quote
-Michael
--
Jeff Overcash (TeamB) On waves of silver I dreamed of gold
(Please do not email 'Till I lost the peace that dreaming gives
me directly unless I dreamed of the moment of my own death
asked. Thank You) That no one ever dreams and lives (Marillion)
 

Re:Re: Cross Platform Development

Thanks for the pointers,
-Michael
 

Re:Re: Cross Platform Development

Quote
Wrong. In Delphi you have the choice of normal GC and deterministic freeing.
More flexibility, not less. If you choose you can not do a free and let the GC
collect it when it normally would.
Thanks. I did not know that avoiding to implement/call free for objects,
while removing the references and thus let the GC do it's work is possible.
Quote
This is the .NET way. You also use StringBuilder with C# etc.

Of course. But when writing code the traditional Delphi way using the
language defined string type will force the Framework to StringBuilder
objects instead of .NET strings and thus to much less performance. Or am
I wrong ?
-Michael
 

Re:Re: Cross Platform Development

"To the world outside Delphi, your objects simply appear to implement
the IDisposable pattern."
"So, when you call Free on the component, the expectation is that that
component is removed from the Owner's list immediately. These semantics
are now preserved."
This is what I heard would create a performance problem. Even though (of
course) the GC "collecting" action is not called by doing "Dispose" on
an "IDisposable" object (this is only done automatically when resources
are low or by calling some .NET API), using "IDisposable" at all and
calling "Dispose" was said to be unnecessary and reduce performance.
Many objects are created once and either live until the end of the
application or it does no harm to let them live, as resources are not
tight. Thus GC would never do anything at all and does not need to be
informed about the objects' state by making them IDisposable.
-Michael
 

Re:Re: Cross Platform Development

Michael Schnell wrote:
Quote


Of course. But when writing code the traditional Delphi way using the
language defined string type will force the Framework to StringBuilder
objects instead of .NET strings and thus to much less performance. Or am
I wrong ?

No you are wrong. You get the same performance problems under C# if you try to
use native .NET strings. .NET has a different paradigm on how to work with
strings. The correct way is with the StringBuilder class no matter what .NET
language you are using. The difference in speed between the Win32 string class
and the .NET one is because the Win32 string class is an AnsiString and fully
memory allocated through the Delphi memory manager. The .NET string class (no
matter what .NET language you are using) does all its allocation/deallocation
though the OS, much slower. It does not matter what .NET language you use, the
string class will be slower. That is why the StringBuilder class was introduced
(by MS, not Borland) to give you speed when manipulating strings under .NET.
Quote
-Michael
--
Jeff Overcash (TeamB) On waves of silver I dreamed of gold
(Please do not email 'Till I lost the peace that dreaming gives
me directly unless I dreamed of the moment of my own death
asked. Thank You) That no one ever dreams and lives (Marillion)