Home > Archive > Kylix > August 2005 > Cross Platform Development
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Cross Platform Development
|
|
| Robby Tanner 2005-07-28, 5:05 pm |
| Hi there,
I know this has been debated before but I need a review (pointers for
further reading more than welcome).
With Kylix up in the air, what are the current options for Linux/Win32
development? I'm just looking at the CrossKylix website right now. Are
there other methods folks would care to comment on?
Regards,
Rob
| |
| Jonathan Benedicto 2005-07-28, 5:05 pm |
| "Robby Tanner" <robby_tanner@hotmail.com> wrote in message
news:42e92626$1@newsgroups.borland.com...
> Hi there,
>
> I know this has been debated before but I need a review (pointers for
> further reading more than welcome).
>
> With Kylix up in the air, what are the current options for Linux/Win32
> development? I'm just looking at the CrossKylix website right now. Are
> there other methods folks would care to comment on?
In what language ? Pascal or C++ ?
Jonathan
| |
| Simon Kissel 2005-07-28, 5:05 pm |
| > I know this has been debated before but I need a review (pointers for=20
> further reading more than welcome).
>=20
> With Kylix up in the air, what are the current options for Linux/Win32 =
> development? I'm just looking at the CrossKylix website right now. =
Are=20
> there other methods folks would care to comment on?
There are several routes:
- CrossKylix (this will only be a permanent solution if you trust =
Borland
to sooner or later pick up Kylix again for an update)
- CrossFPC (work in progress, will embed the FPC compiler targetting =
Linux
into the Delphi IDE, basicly the same as CrossKylix, but with an updated
compiler)
- Lazarus=20
- FreePascal
- Delphi 2005 + Mono
Depending on what your needs are, all these routes have advantages and =
drawbacks.=20
If you are doing server development (cgi, isapi, webservices, intraweb =
etc),=20
probably CrossKylix will be the best route to go, with the option to =
later switch to
CrossFPC.
If you want to do GUI applications and use the Borland-provided =
toolchain (dbexpress etc),
CrossKylix also is a possible route if you don't mind that your =
applications won't look
as good as recent QT3 KDE applications.
If you want to do GUI client applications, and don't need to use =
existing
commercial components or Borland database layers (dbexpress), Lazarus =
might be a route,
if you can live with beta software.
If the boxes you are deploying to are more or less under your control =
and you wish=20
to do GUI applications, you could also go the .NET route, using Mono for =
Linux and=20
Winforms on the Delphi side (not vcl.net). As most distros don't yet =
install a recent
stable version of Mono including Winforms support, without having =
control of the linux
boxes this will be a deployment nightmare.
Using FreePascal directly is a possible route if you want to do non-gui =
console
applications.
I guess to give you a decent advice we'd need more info on what kind of =
applications
you are after.
Simon
| |
|
| > CrossFPC.
When can we expect a first alpha version?
| |
| Simon Kissel 2005-07-28, 5:05 pm |
| > > CrossFPC.
>=20
> When can we expect a first alpha version?
Well, a first alpha version exists since May, but it's only made =
available
to the CrossFPC team.
Currently the biggest show-stopper issues are missing Linux resource =
support and
a few issues in the variants support. This is needed to support visual =
CLX
and DBExpress. As soon as these parts are finished, CrossFPC should be
usuable for first projects.
Sadly I've been very busy with commercial projects during the last 2 =
month,
and there hasn't been much progress on the CrossFPC front. I'm planning =
to
back to it real soon now.
Probably a first usuable public version if the project will become =
available in
August or September, but don't nail me on it.
Simon
| |
| Michael Schnell 2005-07-28, 5:05 pm |
| > There are several routes:
>
> - CrossKylix (this will only be a permanent solution if you trust Borland
> to sooner or later pick up Kylix again for an update)
> - CrossFPC (work in progress, will embed the FPC compiler targetting Linux
> into the Delphi IDE, basicly the same as CrossKylix, but with an updated
> compiler)
> - Lazarus
> - FreePascal
> - Delphi 2005 + Mono
>
As I suppose he wants to find an RAD environment to write
"Delphi-language", you can add
- Chrome (They seem to claim claim it works professionally: development
in Windows using Microsoft's IDE "Visual Studio", create .NET
assemblies that run under Microsoft .NET on Windows, Mono on Windows and
Linux, and compact .NET framework on Windows CE.
-Michael
| |
|
| > Probably a first usuable public version if the project will become available in
> August or September, but don't nail me on it.
sounds good :-)
| |
| Brion L. Webster 2005-07-28, 10:02 pm |
| Simon Kissel wrote:
>Sadly I've been very busy with commercial projects during the last 2 month,
Sadly? Congratulations, Simon, you're making money! Something we all
hope to do!
I think it's amazing you work so hard on this project you donate to us as
it is.
-Brion
| |
| Robby Tanner 2005-07-28, 10:02 pm |
| Either one, I guess. I'm a Delphi programmer predominantly, but if
cross-platform means getting in to C++, I'll head that direction.
C++ has a lot of things to offer so it wouldn't be such a bad thing to get
in to.
Rob
"Jonathan Benedicto" <incorrect@no.server> wrote in message
news:42e92e4c$1@newsgroups.borland.com...
> "Robby Tanner" <robby_tanner@hotmail.com> wrote in message
> news:42e92626$1@newsgroups.borland.com...
>
> In what language ? Pascal or C++ ?
>
> Jonathan
>
| |
| Robby Tanner 2005-07-28, 10:02 pm |
|
"Michael Schnell" <mschnell_at_bschnell_dot_de@aol.com> wrote in message
news:42e95176$1@newsgroups.borland.com...
>
> As I suppose he wants to find an RAD environment to write
> "Delphi-language", you can add
>
> - Chrome (They seem to claim claim it works professionally: development in
> Windows using Microsoft's IDE "Visual Studio", create .NET assemblies
> that run under Microsoft .NET on Windows, Mono on Windows and Linux, and
> compact .NET framework on Windows CE.
Thanks to both of you for the pointers.
Rob
| |
| Robby Tanner 2005-07-28, 10:02 pm |
| "Simon Kissel" <kissel@computerman.de> wrote in message
news:42e93500$1@newsgroups.borland.com...
> I guess to give you a decent advice we'd need more info on what kind of
> applications
> you are after.
A variety actually. Servers, GUI clients, DB-aware, controls systems, etc,
etc.
Where does FreeCLX fit in to all this?
Rob
| |
| Jonathan Benedicto 2005-07-28, 10:02 pm |
| "Robby Tanner" <robby_tanner@hotmail.com> wrote in message
news:42e963dc$1@newsgroups.borland.com...
> Either one, I guess. I'm a Delphi programmer predominantly, but if
> cross-platform means getting in to C++, I'll head that direction.
>
> C++ has a lot of things to offer so it wouldn't be such a bad thing to
> get in to.
I'm trying to build a cross-platform library, that will incorporate a GUI
system similar to the VCL. It will be cross-compiler, and I'm hoping that
I'll be able to get it to work in Pascal. It is basically a C++ shared
library, and so I hope that I'll just have to write a Pascal header for it
to be C++ / Pascal.
The GUI system will be completely library-drawn, so apps on Windows and
Linux, written using this library will look and act the same.
Hopefully I will be able to complete this.
Jonathan
| |
|
| "Robby Tanner" <robby_tanner@hotmail.com>
> Either one, I guess. I'm a Delphi programmer predominantly, but if
> cross-platform means getting in to C++, I'll head that direction.
>
> C++ has a lot of things to offer so it wouldn't be such a bad thing to get
> in to.
I recommend C++ for cross-platform development. I'm switched on the C++
after Kylix failure. C++/STL/BOOST for console program development. Add here
Qt for GUI, and OCL for Oracle connectivity.
| |
| Andreas Hausladen 2005-07-29, 9:08 am |
| Jonathan Benedicto wrote:
> I'm hoping
> that I'll be able to get it to work in Pascal. It is basically a C++
> shared library, and so I hope that I'll just have to write a Pascal
> header for it to be C++ / Pascal.
I will not shorten your hope but you cannot simply import a C++ class into
a Pascal program. For this you must flatten the C++ class (C++ wrapper).
And that is a lot of work as you can see how long it has taken until I
could make the first release of Qt3 for Kylix. And the worst thing is that
this technique doesn't work for Qt4 anymore. So I'm currently writing a
new conversion tool. (this time in Delphi not C#).
--
Regards,
Andreas Hausladen
(http://www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(http://andy.jgknet.de/blog)
| |
| Dmitry 2005-07-29, 9:08 am |
| Hello, why this technique doesn't works for Qt4? Can you share more details?
Dmitry
"Andreas Hausladen" <AndreasDOTHausladen@gNOMAILmx.de> wrote in message
news:42ea0c75@newsgroups.borland.com...
> Jonathan Benedicto wrote:
>
>
> I will not shorten your hope but you cannot simply import a C++ class into
> a Pascal program. For this you must flatten the C++ class (C++ wrapper).
> And that is a lot of work as you can see how long it has taken until I
> could make the first release of Qt3 for Kylix. And the worst thing is that
> this technique doesn't work for Qt4 anymore. So I'm currently writing a
> new conversion tool. (this time in Delphi not C#).
>
>
> --
> Regards,
>
> Andreas Hausladen
> (http://www.kylix-patch.de.vu - unofficial Kylix 3 patches)
> (http://andy.jgknet.de/blog)
| |
| Dmitry 2005-07-29, 9:08 am |
| Hello.
The buggest problem of the writing Cross-Platfom code is to get rich GUI on
the different platforms.
The RTL it is not, as i think. This can be C++ or Pascal it is not so
important.
The one of the ways to create portable GUI is to use DINO (Gecko-Delphi
Framework).
http://www.kamasoftware.com/gdfoverview.php
No Qt, No VCL, No CLX. All GUI is describe as XML(XUL) and building on Linux
and Windows.
The application is looks like Netscape/Mozilla clons. As example look at the
application writing with DINO - HelpExplorer.
http://www.kamasoftware.com/gdfscreenshots.php
Dmitry
"Robby Tanner" <robby_tanner@hotmail.com> wrote in message
news:42e92626$1@newsgroups.borland.com...
> Hi there,
>
> I know this has been debated before but I need a review (pointers for
> further reading more than welcome).
>
> With Kylix up in the air, what are the current options for Linux/Win32
> development? I'm just looking at the CrossKylix website right now. Are
> there other methods folks would care to comment on?
>
> Regards,
> Rob
>
>
| |
| Simon Kissel 2005-07-29, 9:08 am |
| > As I suppose he wants to find an RAD environment to write=20
> "Delphi-language", you can add
>=20
> - Chrome (They seem to claim claim it works professionally: =
development=20
> in Windows using Microsoft's IDE "Visual Studio", create .NET=20
> assemblies that run under Microsoft .NET on Windows, Mono on Windows =
and=20
> Linux, and compact .NET framework on Windows CE.
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.
Simon
| |
| Simon Kissel 2005-07-29, 9:08 am |
| > > I guess to give you a decent advice we'd need more info on what kind =
of=20
>=20
> A variety actually. Servers, GUI clients, DB-aware, controls systems, =
etc,=20
> etc.
>=20
> Where does FreeCLX fit in to all this?
FreeCLX simply is going to be an updated CLX version with VCL =
compatibility
improved. It will work transparently with Delphi, Kylix, CrossKylix and=20
CrossFPC. It is not required for any of the platforms, but it will be an =
added
benefit for all of these.
What this means is: Whatever the future of Kylix might be, going the =
VCL/CLX
route will be safe, as there will be several compatible paths to take =
your
project to, with very high source compatiblity.
Simon
| |
| Simon Kissel 2005-07-29, 9:08 am |
| > >Sadly I've been very busy with commercial projects during the last 2 =
month,
>=20
> Sadly? Congratulations, Simon, you're making money! Something we all =
> hope to do!
Thanks ;)
> I think it's amazing you work so hard on this project you donate to us =
as=20
> it is.
Well, as stated earlier my commercial future depends on the future of =
Delphi-Linux
target, so I'm doing this out of self-interest ;)
Also a lot of the work is done by other individuals/projects. For =
example CrossFPC
more or less is a simplified FPC distribution that automatically sets up =
Cross-
compilation and adds a thin compatibilty layer, plus the IDE =
integration. The main
work of course is done by the FPC team, doing a great job providing most =
of the
toolchain.
All in all what I'm trying to achieve is to simply bundle the best of =
the existing
seperate projects together to provide an easy and stable future path for =
Kylix
users.
Simon
| |
| Simon Kissel 2005-07-29, 9:08 am |
| > "Robby Tanner" <robby_tanner@hotmail.com>
to get=20[color=darkred]
>=20
> I recommend C++ for cross-platform development. I'm switched on the =
C++=20
> after Kylix failure. C++/STL/BOOST for console program development. =
Add here=20
> Qt for GUI, and OCL for Oracle connectivity.=20
If you don't care about the language switch this might be the option. =
However,
this also has major drawbacks.
First of all, I wouldn't want to deploy QT apps for Windows. Windows =
applications
should have a native GUI. Using VCL/CLX as abstraction layer helps a lot =
here.
Also, I'd really miss the infrastructure Borland provides. Using =
dbexpress I
get database support for each and any database system on the market with =
a=20
standardized interface.=20
Besides that I highly prefer Pascal of C++. And I don't feel like =
spending
an hour to build a project on the console with gcc-build, when I'm able =
to=20
build my application inside a nice IDE in seconds in =
Delphi/Kylix/CrossKylix.
Simon
| |
| Simon Kissel 2005-07-29, 9:08 am |
| > The one of the ways to create portable GUI is to use DINO =
(Gecko-Delphi=20
> Framework).
> http://www.kamasoftware.com/gdfoverview.php
> No Qt, No VCL, No CLX. All GUI is describe as XML(XUL) and building on =
Linux=20
> and Windows.
> The application is looks like Netscape/Mozilla clons. As example look =
at the=20
> application writing with DINO - HelpExplorer.=20
> http://www.kamasoftware.com/gdfscreenshots.php
While this is an interesting project, its website leaves me with a lot =
of questions:
- How about deployment? How is the gecko engine deployed? What versions =
are supported?
What are the terms of gecko redistribution?=20
- Do they provide sources of their framework?
- Who are the authors? Why haven't we heard of them? They don't seem to =
be=20
part of any of the various Kylix projects. They don't seem to post =
here.
It should be in there best interest to for example provide CrossKylix =
support
for their product.
- Is this thing still developed? Last site update is from last year, =
there are no
Forums to see if a developer community exists.
Point is: If you base your applications on a framework, you need to be =
able to trust in
it, it needs to be future-proof. If it's a commercial offering, then it =
needs to be=20
from a stable, known company (and as we know from Borland, this also =
doesn't always
give you enough security, sigh). If it's a community project, the team =
behind it should
look stable. And well, ideally it should be open source, so that in a =
worst-case scenerio
(the project dies) you are able to take over and maintain it yourself.
That's why I'm currently betting on the Kylix/CrossKylix/CrossFPC route. =
If Borland
decides to one day uptime Kylix, my applications will be fine. If they =
decide not to,
CrossFPC gives me a second layer of security. As the FPC project is =
going on for years
already, this looks pretty stable. And if FPC one day dies, it's open =
source and I'm
still able to secure the future of my Applications myself.
Simon
| |
| Andreas Hausladen 2005-07-29, 9:08 am |
| 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
(http://www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(http://andy.jgknet.de/blog)
| |
| Andreas Hausladen 2005-07-29, 9:08 am |
| Jonathan Benedicto wrote:
> I'm trying to build a cross-platform library, that will incorporate a
> GUI system similar to the VCL.
I have started a project some time months ago to write a layer that allows
the VCL to be used unter Linux natively. For this I use the Mono-WinForms
code. But this project is far far away from being compileable. It is only
a test to see how nead Mono-WinForms comes to Win32API. For example
Mono-WinForms has the function
GetMessage/P Message/TranslateMessage/DispatchMessage for X11.
I don't know if I will ever finish this VCL for Linux project because it
is only a project that shows me that it meight be possible.
--
Regards,
Andreas Hausladen
(http://www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(http://andy.jgknet.de/blog)
| |
| Dmitry 2005-07-29, 9:08 am |
| I can't provide answer for all questions which you has to ask.
But some of the questions be able to resolve easy:
I think the deployment of this framework is not deffer sharply from
deployment the DevExpress components for instance.
[color=darkred]
Gecko has no limits to deploy if you don't build your own version of it.[color=darkred]
The framework has xpidl2pas compiler and it is make it possible don't
depended from version of the GRE.
[color=darkred]
Goto Gecko web (www.mozilla.com) site and you will know :)
[color=darkred]
I don't know the components/frameworks for Delphi/Kilix for which the
sources is not available, only DCU.
[color=darkred]
Point is: If you base your applications on a framework, you need to be able
to trust in
it, it needs to be future-proof. If it's a commercial offering, then it
needs to be
from a stable, known company (and as we know from Borland, this also doesn't
always
give you enough security, sigh). If it's a community project, the team
behind it should
look stable. And well, ideally it should be open source, so that in a
worst-case scenerio
(the project dies) you are able to take over and maintain it yourself.[color=darkred]
Agree with you.
[color=darkred]
That's why I'm currently betting on the Kylix/CrossKylix/CrossFPC route. If
Borland
decides to one day uptime Kylix, my applications will be fine. If they
decide not to,
CrossFPC gives me a second layer of security. As the FPC project is going on
for years
already, this looks pretty stable. And if FPC one day dies, it's open source
and I'm
still able to secure the future of my Applications myself.[color=darkred]
If you have a 750BMW and the BMW factory is down and your gear-box is down
too, you
in theory can to produce spares by file but it is not possible as you
understand :))
So if your project is based on FPC and FPC is die, you project die too.
"Simon Kissel" <kissel@computerman.de> wrote in message
news:42ea2814$1@newsgroups.borland.com...[color=darkred]
> The one of the ways to create portable GUI is to use DINO (Gecko-Delphi
> Framework).
> http://www.kamasoftware.com/gdfoverview.php
> No Qt, No VCL, No CLX. All GUI is describe as XML(XUL) and building on
> Linux
> and Windows.
> The application is looks like Netscape/Mozilla clons. As example look at
> the
> application writing with DINO - HelpExplorer.
> http://www.kamasoftware.com/gdfscreenshots.php
While this is an interesting project, its website leaves me with a lot of
questions:
- How about deployment? How is the gecko engine deployed? What versions are
supported?
What are the terms of gecko redistribution?
- Do they provide sources of their framework?
- Who are the authors? Why haven't we heard of them? They don't seem to be
part of any of the various Kylix projects. They don't seem to post here.
It should be in there best interest to for example provide CrossKylix
support
for their product.
- Is this thing still developed? Last site update is from last year, there
are no
Forums to see if a developer community exists.
Point is: If you base your applications on a framework, you need to be able
to trust in
it, it needs to be future-proof. If it's a commercial offering, then it
needs to be
from a stable, known company (and as we know from Borland, this also doesn't
always
give you enough security, sigh). If it's a community project, the team
behind it should
look stable. And well, ideally it should be open source, so that in a
worst-case scenerio
(the project dies) you are able to take over and maintain it yourself.
That's why I'm currently betting on the Kylix/CrossKylix/CrossFPC route. If
Borland
decides to one day uptime Kylix, my applications will be fine. If they
decide not to,
CrossFPC gives me a second layer of security. As the FPC project is going on
for years
already, this looks pretty stable. And if FPC one day dies, it's open source
and I'm
still able to secure the future of my Applications myself.
Simon
| |
| Jonathan Benedicto 2005-07-29, 5:08 pm |
| "Andreas Hausladen" <AndreasDOTHausladen@gNOMAILmx.de> wrote in message
news:42ea2954$1@newsgroups.borland.com...
> I have started a project some time months ago to write a layer that
> allows
> the VCL to be used unter Linux natively. For this I use the Mono-WinForms
> code. But this project is far far away from being compileable. It is only
> a test to see how nead Mono-WinForms comes to Win32API. For example
> Mono-WinForms has the function
> GetMessage/P Message/TranslateMessage/DispatchMessage for X11.
> I don't know if I will ever finish this VCL for Linux project because it
> is only a project that shows me that it meight be possible.
I have been thinking about making my library a open-source LGPL or Mozilla
licenced project on SF. If I can get developers to agree with my ideas. <g>
Jonathan
| |
| Jonathan Benedicto 2005-07-29, 5:08 pm |
| "Andreas Hausladen" <AndreasDOTHausladen@gNOMAILmx.de> wrote in message
news:42ea0c75@newsgroups.borland.com...
> I will not shorten your hope but you cannot simply import a C++ class
> into
> a Pascal program. For this you must flatten the C++ class (C++ wrapper).
> And that is a lot of work as you can see how long it has taken until I
> could make the first release of Qt3 for Kylix. And the worst thing is
> that
> this technique doesn't work for Qt4 anymore. So I'm currently writing a
> new conversion tool. (this time in Delphi not C#).
When you say "flatten", do you mean it must be redone into C ? Eg:
class Test
{
public:
Test();
void One();
void Two();
};
Must become something like:
void Test_Test();
void Test_One();
void Test_Two();
Jonathan
| |
| Andreas Hausladen 2005-07-29, 5:08 pm |
| Jonathan Benedicto wrote:
> Must become something like:
>
> void Test_Test();
> void Test_One();
> void Test_Two();
You must do all the things the compiler does for you:
# void Test::Test();
must become something like:
# Test* Test_Test() { return new Test(); }
And methods must become this:
# int Test_getValue(Test* t) { return t->getValue(); }
--
Regards,
Andreas Hausladen
(http://www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(http://andy.jgknet.de/blog)
| |
| Jonathan Benedicto 2005-07-29, 5:08 pm |
| "Andreas Hausladen" <AndreasDOTHausladen@gNOMAILmx.de> wrote in message
news:42ea0c75@newsgroups.borland.com...
> I will not shorten your hope but you cannot simply import a C++ class
> into
> a Pascal program. For this you must flatten the C++ class (C++ wrapper).
> And that is a lot of work as you can see how long it has taken until I
> could make the first release of Qt3 for Kylix. And the worst thing is
> that
> this technique doesn't work for Qt4 anymore. So I'm currently writing a
> new conversion tool. (this time in Delphi not C#).
PS. <g> When I said a shared library, I meant, under Windows .dll, under
Linux .so, that has been compiled in C++. The library is written in C++,
but so that Pascal can use it, I make an import library, and a Pascal
header file.
I thought that all one needed to do is this. My library exports a "extern
C" Application function, that returns a pointer to the application instance
class created by another "extern C" CreateApplication function.
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.
Jonathan
| |
| Jonathan Benedicto 2005-07-29, 5:08 pm |
| "Andreas Hausladen" <AndreasDOTHausladen@gNOMAILmx.de> wrote in message
news:42ea4a7d@newsgroups.borland.com...
> You must do all the things the compiler does for you:
> # void Test::Test();
> must become something like:
> # Test* Test_Test() { return new Test(); }
>
> And methods must become this:
> # int Test_getValue(Test* t) { return t->getValue(); }
So I would have to make the library export all these a extern "c"
functions, then I'd have to write Pascal "wrapper" classes ?
Jonathan
| |
| Dmitry 2005-07-29, 5:08 pm |
|
> 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" <AndreasDOTHausladen@gNOMAILmx.de> wrote in message
news:42ea2756$1@newsgroups.borland.com...
> Dmitry wrote:
>
>
> 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
> (http://www.kylix-patch.de.vu - unofficial Kylix 3 patches)
> (http://andy.jgknet.de/blog)
| |
| Dmitry 2005-07-29, 5:08 pm |
| Sorry, "create" should be read as "great" :)))
"Dmitry" <someone@int.ui> wrote in message
news:42ea5110$1@newsgroups.borland.com...
>
>
> 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" <AndreasDOTHausladen@gNOMAILmx.de> wrote in message
> news:42ea2756$1@newsgroups.borland.com...
>
>
| |
| Andreas Hausladen 2005-07-29, 5:08 pm |
| Jonathan Benedicto wrote:
> 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
(http://www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(http://andy.jgknet.de/blog)
| |
| Andreas Hausladen 2005-07-29, 5:08 pm |
| Jonathan Benedicto wrote:
> 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
(http://www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(http://andy.jgknet.de/blog)
| |
| Jonathan Benedicto 2005-07-29, 5:08 pm |
| "Andreas Hausladen" <AndreasDOTHausladen@gNOMAILmx.de> wrote in message
news:42ea52f9$1@newsgroups.borland.com...
> Exactly.
Thank you very much for this info. I guess I'll have to use your tool once
the library is completed. <g>
Jonathan
| |
| Michael Schnell 2005-07-29, 5:08 pm |
| > 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
| |
| Dan Palley 2005-07-29, 10:03 pm |
|
"Michael Schnell" <mschnell_at_bschnell_dot_de@aol.com> wrote in message
news:42ea9dfc$1@newsgroups.borland.com...
>
> 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
| |
| Simon Kissel 2005-07-30, 9:03 am |
| > "Michael Schnell" <mschnell_at_bschnell_dot_de@aol.com> wrote in =
message=20
> news:42ea9dfc$1@newsgroups.borland.com...
another=20[color=darkred]
the[color=darkred]
easy=20[color=darkred]
>=20
> If I want to target .NET/MONO, why wouldn't I just use the existing =
Delphi=20
> 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=20
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
| |
| Simon Kissel 2005-07-30, 9:03 am |
| > > You are right, I forgot about that. Chrome definately would be =
another route.
the[color=darkred]
>=20
> There is an open source project that provides a library for more easy=20
> 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
| |
| Michael Schnell 2005-07-30, 5:03 pm |
| > 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
| |
| Dan Palley 2005-07-30, 5:03 pm |
| "Michael Schnell" <mschnell_at_bschnell_dot_de@aol.com> wrote in message
news:42ebc249$1@newsgroups.borland.com...
>
> In addition to Simons answer:
>
> Delphi is not a _really_ .Net compliant tool (even D2005 for Windows).
Oh, really?
>
> 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:
http://homepages.borland.com/abauer...944429821073223
This link is referenced from MS blogs where they indicate that the Delphi
method is a good approach:
http://weblogs.asp.net/astopford/ar...1/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:
http://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.
> 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
| |
| Jeff Overcash (TeamB) 2005-07-30, 10:01 pm |
|
Michael Schnell wrote:
>
>
> 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)
> 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.
> 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.
> -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)
| |
| Michael Schnell 2005-07-31, 9:01 am |
| Thanks for the pointers,
-Michael
| |
| Michael Schnell 2005-07-31, 9:01 am |
| > 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.
> 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
| |
| Michael Schnell 2005-07-31, 9:01 am |
| >
> http://homepages.borland.com/abauer...944429821073223
>
Quote:
"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
| |
| Jeff Overcash (TeamB) 2005-07-31, 5:19 pm |
|
Michael Schnell wrote:
>
>
> 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.
> -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)
| |
| Marco van de Voort 2005-08-02, 9:20 am |
| On 2005-07-29, Dmitry <someone@int.ui> wrote:
> If you have a 750BMW and the BMW factory is down and your gear-box is down
> too, you
> in theory can to produce spares by file but it is not possible as you
> understand :))
> So if your project is based on FPC and FPC is die, you project die too.
This is false.
While I agree that if FPC would die, it would be very hard (and quite
unlikely) if a mere user would continue development on the same scale, this doesn't
mean that having the source is a very big thing.
Small fixes to compiler and runtime, and maybe even a small OS port are doable. (e.g.
porting to another *nix is typically a w full time to get the initial core working).
This can matter really a lot to businesses, since it gives application
developers some more breathing room, and allows to directly attack the problem on the place
where it is instead of performing complex workarounds (like binary postprocessors).
Specially on ever changing Linux, this can be quite important, as Kylix
history quite effectively shows.
| |
| Florian Klaempfl 2005-08-02, 9:20 am |
| Dmitry wrote:
> If you have a 750BMW and the BMW factory is down and your gear-box is down
> too, you
> in theory can to produce spares by file but it is not possible as you
> understand :))
> So if your project is based on FPC and FPC is die, you project die too.
This is true for every software, just remember that software of some company I
think it was called Kylix ;)? Commercial projects die easily, OSS projects are
much harder to kill, just look at the Mozilla case. And even better, if an OSS
project is really important for you (no, I'am not talking about some shareware
programmer making some thousand Euros per year but software making more money)
you can continue to develop it yourself or at least fixing it.
| |
| Michael Schnell 2005-08-02, 5:05 pm |
| >That is why the StringBuilder class was introduced
> (by MS, not Borland) to give you speed when manipulating strings under .NET.
>
That is what I don't understand. If with all operations the
Stringbuilder is faster than the ".NET string class" why did then not
just improve the ".NET string class" using the Stringbuilder code ?
I was told it that way:
If you do:
s1 := s1 + s2;
This is fast with the .NET string class, as there will be no memory
reallocation. The old s1 version just sits around there untouched until
the garbage control needs memory and frees it (in most cases this never
happens until the application is closed.
If you do the same with Stringbuilder it's slower because Stringbuilder
is a fare more complex thing than the .NET string class.
But if you do
s1[1] = 'X';
Stringbuilder has a function do do this in a single .NET API call.
Using the .NET string class would mean the compiler has to do something like
s1 := copy(s1, 2, high(Integer));
sx := 'X';
s1 := sx + s1;
Of course this is much slower than using Stringbuilder.
-Michael
| |
| Robert Love 2005-08-02, 5:05 pm |
| Michael Schnell wrote:
>
> That is what I don't understand. If with all operations the
> Stringbuilder is faster than the ".NET string class" why did then not
> just improve the ".NET string class" using the Stringbuilder code ?
You will have to ask Microsoft that.
--
Robert Love
Blog: http://peakxml.com
| |
| Robby Tanner 2005-08-03, 5:08 pm |
|
"Ender" <linuxmustdie@hotmail.com> wrote in message
news:42e9a7c0@newsgroups.borland.com...
> "Robby Tanner" <robby_tanner@hotmail.com>
>
> I recommend C++ for cross-platform development. I'm switched on the C++
> after Kylix failure. C++/STL/BOOST for console program development. Add
> here Qt for GUI, and OCL for Oracle connectivity.
STL is the Standard Template Library?
Rob
| |
| Robby Tanner 2005-08-03, 5:08 pm |
| Xref: number1.nntp.dca.giganews.com borland.public.kylix.non-technical:14487
"Robby Tanner" <robby_tanner@hotmail.com> wrote in message
news:42f11721$1@newsgroups.borland.com...
>
> "Ender" <linuxmustdie@hotmail.com> wrote in message
> news:42e9a7c0@newsgroups.borland.com...
>
> STL is the Standard Template Library?
If so, where do I get it?
I downloaded boost, thanks for the pointer.
Rob
| |
|
| >> I recommend C++ for cross-platform development. I'm switched on the C++
"Robby Tanner" <robby_tanner@hotmail.com>[color=darkred]
> STL is the Standard Template Library?
Yes.
| |
|
| "Robby Tanner" <robby_tanner@hotmail.com>
>
> If so, where do I get it?
>
> I downloaded boost, thanks for the pointer.
STL usually included in the modern Linux distros, i can't tell you right now
what package it uses.
| |
| Robby Tanner 2005-08-05, 5:06 pm |
|
"Ender" <linuxmustdie@hotmail.com> wrote in message
news:42f187f9@newsgroups.borland.com...
> "Robby Tanner" <robby_tanner@hotmail.com>
>
> STL usually included in the modern Linux distros, i can't tell you right
> now what package it uses.
There's no windows version or is it version-independent? How about BOOST?
I'm not stuck being windows-only, just curious about portability.
Rob
| |
|
| "Robby Tanner" <robby_tanner@hotmail.com>
> There's no windows version or is it version-independent? How about BOOST?
> I'm not stuck being windows-only, just curious about portability.
Both STL and BOOST are cross-platform. As i know MSVC shipped with their own
version of STL, however STL-dependent code you write will compile on Linux
without problems. BOOST from http://www.boost.org will compile on both,
Linux and Windows.
Recently i wrote an Windows console application which use only pure C++, STL
and BOOST. Then it was compiled on the Linux without code changes. The
changes was done only in build scripts.
|
|
|
|
|