Advice on writing portable C++ application

[Ramon F Herrera]

My goal is to write a studio-type application which will initially run
on Windows, but I would like it to run on other platforms with minimum
efforts.

I have made the decision to go with C++.

Through advice obtained in this NG (thanks!) I was able to determine
the available alternatives on the most obvious component that must be
portable, i.e. the GUI library. I still have to decide among the 3 big
ones (they are 3, right?).

But my question is about non GUI stuff: what else should I do to
achieve portability? Let's say I want to open a file. I don't want to
use the Windows specific system calls, but to use something like
'fopen()'. What non-GUI libraries or programming environments are
recommended?

TIA,

-Ramon

[Victor Bazarov]

Ramon F Herrera wrote:

My goal is to write a studio-type application

What's a "studio-type application"? Similar to Visual _Studio_?

which will initially run
on Windows, but I would like it to run on other platforms with minimum
efforts.

I have made the decision to go with C++.

Through advice obtained in this NG (thanks!) I was able to determine
the available alternatives on the most obvious component that must be
portable, i.e. the GUI library. I still have to decide among the 3 big
ones (they are 3, right?).

But my question is about non GUI stuff: what else should I do to
achieve portability? Let's say I want to open a file. I don't want to
use the Windows specific system calls, but to use something like
'fopen()'. What non-GUI libraries or programming environments are
recommended?

Usually the libraries designed to be portable contain some non-GUI
stuff. For example, Qt has threads, timers, strings, etc. It even
has some support for directory enumeration and file path management
as I recall. RTM (or Google) for more.

If you can't find (or decide not to use) a library that provides
those things, you could write your own or look on the Web for the
alternatives. For all I know they do exist, and probably plenty
of them. The main problem for you is that they are not really
topical since they don't support _all_ platforms where C++ exists
and hence you should try asking in the newsgroup dedicated to the
OS you're going to target.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Kira Yamato]

On 2007-11-27 18:07:44 -0500, Ramon F Herrera <ra***@conexus.netsaid:

My goal is to write a studio-type application which will initially run
on Windows, but I would like it to run on other platforms with minimum
efforts.

I have made the decision to go with C++.

Why are you not considering java? They seem to have API's that have
implementations on each of the "3 big ones," including graphics and
file systems which you need.

>
Through advice obtained in this NG (thanks!) I was able to determine
the available alternatives on the most obvious component that must be
portable, i.e. the GUI library. I still have to decide among the 3 big
ones (they are 3, right?).

But my question is about non GUI stuff: what else should I do to
achieve portability? Let's say I want to open a file. I don't want to
use the Windows specific system calls, but to use something like
'fopen()'. What non-GUI libraries or programming environments are
recommended?

TIA,

-Ramon

--

-kira

[Ramon F Herrera]

On Nov 27, 7:26 pm, "Victor Bazarov" <[e-mail]:

Ramon F Herrera wrote:

My goal is to write a studio-type application

What's a "studio-type application"? Similar to Visual _Studio_?

Going back to the earliest studio-type apps, mine is something similar
in look to MacPaint/MacDraw. You have a palette, you pick components
and you drag them around a canvas. You have a rectangular selection
tool, resizing, moving, that kind of stuff.

Nothing to do with compiling.

-Ramon

[Ramon F Herrera]

On Nov 27, 7:26 pm, "Victor Bazarov" <[e-mail]:

Ramon F Herrera wrote:

My goal is to write a studio-type application

What's a "studio-type application"? Similar to Visual _Studio_?

which will initially run
on Windows, but I would like it to run on other platforms with minimum
efforts.

I have made the decision to go with C++.

Through advice obtained in this NG (thanks!) I was able to determine
the available alternatives on the most obvious component that must be
portable, i.e. the GUI library. I still have to decide among the 3 big
ones (they are 3, right?).

But my question is about non GUI stuff: what else should I do to
achieve portability? Let's say I want to open a file. I don't want to
use the Windows specific system calls, but to use something like
'fopen()'. What non-GUI libraries or programming environments are
recommended?

Usually the libraries designed to be portable contain some non-GUI
stuff. For example, Qt has threads, timers, strings, etc. It even
has some support for directory enumeration and file path management
as I recall. RTM (or Google) for more.

The main problem for you is that they are not really
topical since they don't support _all_ platforms where C++ exists
and hence you should try asking in the newsgroup dedicated to the
OS you're going to target.

In practical, realistic terms, the platforms I care about are Windows,
Linux and Mac.

-Ramon

[Ramon F Herrera]

On Nov 27, 7:36 pm, Kira Yamato <[e-mail]:

On 2007-11-27 18:07:44 -0500, Ramon F Herrera <[e-mail]:

My goal is to write a studio-type application which will initially run
on Windows, but I would like it to run on other platforms with minimum
efforts.

I have made the decision to go with C++.

Why are you not considering java? They seem to have API's that have
implementations on each of the "3 big ones," including graphics and
file systems which you need.

Guess what, Kira... I do have Java version of the program, whose staus
is somewhere between a prototype and a working application. There are
a couple of factors for the C++ decision:

- I love Java, but I hate its non-compiled nature sometimes.
- I am itching for a reason to pick up C++ in a non-trivial project.
- Some of the libraries that I need are available in native only and
I don't find the JNI particularly appealing.

As you can see some of my reasoning is based on feelings (except for
the speed, that one is demonstrably objective).

-Ramon

[Victor Bazarov]

Ramon F Herrera wrote:

[..]
In practical, realistic terms, the platforms I care about are Windows,
Linux and Mac.

As Alf mentions, Boost is one library you could certainly make use of.
Look in the archives, there used to be the "list of available libraries
FAQ" posted here by Nikki Locke. Peruse it to see what else is there.
I am certain you can find [almost] anything you need that has already
been designed, debugged (to some extend), and packaged in an easy to
use form (relatively speaking, of course).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Marco Manfredini]

Ramon F Herrera wrote:

My goal is to write a studio-type application which will initially run
on Windows, but I would like it to run on other platforms with minimum
efforts.

I have made the decision to go with C++.

Through advice obtained in this NG (thanks!) I was able to determine
the available alternatives on the most obvious component that must be
portable, i.e. the GUI library. I still have to decide among the 3 big
ones (they are 3, right?).

But my question is about non GUI stuff: what else should I do to
achieve portability? Let's say I want to open a file. I don't want to
use the Windows specific system calls, but to use something like
'fopen()'. What non-GUI libraries or programming environments are
recommended?

The ones that come with your GUI library, the most of them put a layer
above the OS functionality (QFile,wxFile etc..), because they need it
anyway to achieve portability. Also, mixing, say, let's say a thread
layer library X with a high level GUI Y library usually doesn't work to
well (you end with a system where X-threads use X-mutexe and can not
synchronize with Y-threads, because they use Y-semaphores and so on)

[Ramon F Herrera]

On Nov 27, 7:45 pm, "Alf P. Steinbach" <[e-mail]:

Through advice obtained in this NG (thanks!) I was able to determine
the available alternatives on the most obvious component that must be
portable, i.e. the GUI library. I still have to decide among the 3 big
ones (they are 3, right?).

A bunch.

I recently did some looking around and these are ones that have made
an impact:

http://www.wxwidgets.org/
http://www.gtk.org/
http://trolltech.com/

The GIMP toolkit didn't give me a good initial impression: how can a
*graphical* toolkit have such a clumsy looking web page? (typical of a
lot of GNU stuff).

The last one, Qt, has commercial leanings but they seem to be changing
their ways, adapting to a changing world. It is preferred by Google,
HP, etc.

Those are the 3 big ones I was talking about. Any other contenders?

-Ramon

[Ian Collins]

Ramon F Herrera wrote:

>
But my question is about non GUI stuff: what else should I do to
achieve portability? Let's say I want to open a file. I don't want to
use the Windows specific system calls, but to use something like
'fopen()'. What non-GUI libraries or programming environments are
recommended?

What's wrong with the standard library, in this case, iostreams?

--
Ian Collins.

[Marco Manfredini]

Ian Collins wrote:

Ramon F Herrera wrote:

>But my question is about non GUI stuff: what else should I do to
achieve portability? Let's say I want to open a file. I don't want to
use the Windows specific system calls, but to use something like
'fopen()'. What non-GUI libraries or programming environments are
recommended?

What's wrong with the standard library, in this case, iostreams?

the iostreams library avoids a couple of mainstream concepts for the
sake of total portability, for example "filename separators", "filename
character sets","directories","volumes","URL".

The GUI libraries OTOH emerged when iostreams & the standard library
weren't available in their final form and so they developed their own,
tightly coupled solutions for IO. They cover a much larger set of
platform dependent features, are integrated into the toolkit framework
(=exceptions, toolkit string classes) and are also more complete (like:
I can open a stream from ftp and use this to load an image).

With iostreams alone, I wouldn't even know where and how to store the
user's settings.

[Ian Collins]

Marco Manfredini wrote:

Ian Collins wrote:

>Ramon F Herrera wrote:

>>But my question is about non GUI stuff: what else should I do to
achieve portability? Let's say I want to open a file. I don't want to
use the Windows specific system calls, but to use something like
'fopen()'. What non-GUI libraries or programming environments are
recommended?

What's wrong with the standard library, in this case, iostreams?

the iostreams library avoids a couple of mainstream concepts for the
sake of total portability, for example "filename separators", "filename
character sets","directories","volumes","URL".

The GUI libraries OTOH emerged when iostreams & the standard library
weren't available in their final form and so they developed their own,
tightly coupled solutions for IO. They cover a much larger set of
platform dependent features, are integrated into the toolkit framework
(=exceptions, toolkit string classes) and are also more complete (like:
I can open a stream from ftp and use this to load an image).

With iostreams alone, I wouldn't even know where and how to store the
user's settings.

Fair point.

--
Ian Collins.

[Michael Oswald]

Alf P. Steinbach wrote:

Poco <url: http://pocoproject.org/>.

Hm, interesting. I haven't noticed it before. Have you actively used it?
lg,
Michael

[Matthias Buelow]

Ramon F Herrera wrote:

The GIMP toolkit didn't give me a good initial impression: how can a
*graphical* toolkit have such a clumsy looking web page? (typical of a
lot of GNU stuff).

Because it's by programmers, for programmers, who don't care about such
petty details.

However, I recommend wxWidgets. It's quite mature, complete and free. It
sits upon the/a native toolkit (and doesn't try to mimick it, like Qt),
although you can also create your own portable widgets of some sorts.