Commercial traps: How to avoid?
Rune Allnor
It is a good idea to fit your text into 70 columns or so. -mod }
Hi all.
I have worked for some 15 years with engineering problems which required
programming skills, in various companies and institutions. One main lesson
I have learned is to keep my code as "plain vanilla" as possible; to avoid all
and any non-standardized bell and whistle the various systems tempt with.
The consistent code compatibility across platforms was one major reason
why I around 1997 left C++ as the main programming tool and decided to
use matlab instead.
For the last few years I have tried to get back into C++, mainly for two
reasons: Code maintenance in matlab is an utter nightmare, C++ has
evolved significantly in terms of standardization and portability across
platforms. I write my programs with all major platforms in mind;
small-scale businesses might want to use my tools on a Win platform,
the heavy-duty users might use Linux clusters, the stray users might
use MACs. What GUIs are concerned, Qt seems to provide the
combo of code consistency and portability across platforms I need.
The last few months I have extended my horizon -- I'm a 'fallen' UNIX
programmer -- into the Windows world. In my day-job, MSWord and
Excel are *the* tools to use. Nothing I can do about that. So I decided
to get a C++ Compiler/IDE with COM automation capacities.
This is a mine-field what my philosophy about writing as portable
code as possible is concerned. COM and Win bring me, by default
into the Microsoft herd; I have no choise but to hang on to their
marketing decisions.
Even worse, I bought a non-MS brand compiler, where lots of small
details differ from "usual" C/C++ conventions: Class members are
open for direct access (it seems everything by default is declared
public), indexes start from 1, not 0, and so on. Doing things
*slightly* different than the competitor is a commercial trap:
At first, one find these idiosyncracities awkward; with time
one accept them and start using them, until the point where the
cost of undoing things become too overwhelming, and one is
stuck with the commercial vendor.
To me, this is deja vu all over again: I am slowly getting myself
entagled in a web with commercial traps are all over the place.
I can't avoid that, for the components specifically related to
COM, but the influence from these commercial tools get to me,
in general throwing sand in the macinery and a messed-up focus,
ultimately resulting in non-portable code.
How should one deal with this situation? I am alrady doing
my best to separate the various components in the programs;
keeping the useful stuff separate from GUIs and COM blocks.
Still, i have this nagging feeling that all these various idiosyncracities
of the various commercial tools and libraryes sneak into my mind
and way of thinking, if not (yet) all the way into my code.
Any advice on how to deal with this?
Rune
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Sam
>
> Even worse, I bought a non-MS brand compiler,
I believe you can get better help if you name this non-MS compiler.
Or maybe ask for help in the newsgroups of that compiler??
> where lots of small
> details differ from "usual" C/C++ conventions: Class members are
> open for direct access (it seems everything by default is declared
> public), indexes start from 1, not 0, and so on.
This really is a very strange compiler. Are you sure
it is a C++ one? :-)
> How should one deal with this situation? I am alrady doing
> my best to separate the various components in the programs;
> keeping the useful stuff separate from GUIs and COM blocks.
> Still, i have this nagging feeling that all these various idiosyncracities
> of the various commercial tools and libraryes sneak into my mind
> and way of thinking, if not (yet) all the way into my code.
>
> Any advice on how to deal with this?
>
<speculation>
It seems to me that you are forced to use some kind of library the
non-MS compiler provides.
</speculation>
What's wrong in compiling Qt with this compiler (AFAIK Qt compiles with
an enormous number of different C++ compilers) and use it as usual? This
will only leave the COM stuff to deal with.
Just my 2 cents.
Gianni Mariani
...
>
> Any advice on how to deal with this?
Succumb to the dark side. Well, just a little.
I first define the objects using standard C++, nothing else, then I
write a very thin wrapper that does all the proprietary hooks. The
proprietary layer is very thin, paper thin. It's relatively easy to
maintain and allows me to port the bulk (99.9%) of the code to non
proprietary platforms.
I use an OS abstration layer, anything that is OS specific (like
managing file names, threads, time etc is done in an API that is
implemented for multiple OS's (I wrote and use Austria C++ for this,
boost is another alternative).
The very nice thing about having a portable codebase is that you can
test it across multiple platforms which raises issues earlier than if
you didn't.
Le Chaud Lapin
> The last few months I have extended my horizon -- I'm a 'fallen' UNIX
> programmer -- into the Windows world. In my day-job, MSWord and
> Excel are *the* tools to use. Nothing I can do about that. So I decided
> to get a C++ Compiler/IDE with COM automation capacities.
Why do you need to use Excel/Word? I have followed some of your posts
in comp.dsp, so I guess I could see how you might be driving Excel,
but why Word?
> This is a mine-field what my philosophy about writing as portable
> code as possible is concerned. COM and Win bring me, by default
> into the Microsoft herd; I have no choise but to hang on to their
> marketing decisions.
COM is, in my opinion, one of the biggest untruths that Microsoft has
tricked gullible managers and programmers into using. I was forced to
use it to write two shell namespace extensions (NSE's). Find a way to
break free if you can.
> Even worse, I bought a non-MS brand compiler, where lots of small
> details differ from "usual" C/C++ conventions: Class members are
> open for direct access (it seems everything by default is declared
> public), indexes start from 1, not 0, and so on. Doing things
> *slightly* different than the competitor is a commercial trap:
> At first, one find these idiosyncracities awkward; with time
> one accept them and start using them, until the point where the
> cost of undoing things become too overwhelming, and one is
> stuck with the commercial vendor.
In fairness to Microsoft, the free version of their C++ IDE,, Visual
Studio Express 2005 [http://msdn.microsoft.com/vstudio/express/visualc/
default.aspx] is simply state-of-the-art. The power for building
large-scale (and portable) software development is unprecedented. The
free version strips some of the features away from the commercial
version, but what remains is still very significant. The compiler is
also an area where one can almost "feel" the internal struggle at
Microsoft, between people who tend to think like yourself, versus
people who thought, at least at one point, that COM was absolutely
wonderful. The former has done a good job of holding their ground and
creating a compiler that tracks the standard to a reasonable degree.
> To me, this is deja vu all over again: I am slowly getting myself
> entagled in a web with commercial traps are all over the place.
> I can't avoid that, for the components specifically related to
> COM, but the influence from these commercial tools get to me,
> in general throwing sand in the macinery and a messed-up focus,
> ultimately resulting in non-portable code.
I empathize completely. You're going to have to be disciplined and
just-say-no. That feel that you get of being "lured into a trap" is,
IMO, very real. There were some fireworks in this group a about a
year ago about Microsoft calling a language C++ when they knew full
well that it wasn't. I would just keep Stroustrup nearby and walk the
line of the compiler. I can tell you with 100% certainty that
Microsoft did make it so that, if you want to avoid being trapped, you
can do so.
> How should one deal with this situation? I am alrady doing
> my best to separate the various components in the programs;
> keeping the useful stuff separate from GUIs and COM blocks.
> Still, i have this nagging feeling that all these various idiosyncracities
> of the various commercial tools and libraryes sneak into my mind
> and way of thinking, if not (yet) all the way into my code.
With COM, you're out of luck. I used it because I really had no
choice (two shell namespace extensions). You probably have other
options. With the GUI, this is a wild card. Win32 GUI interface is
tedious. MFC is distasteful example of how to employ C++, and many
programmers have indeed become contaminated by not properly defending
their minds from its "model". Based on your posting in comp.dsp, I do
not think you are in any danger of this happening, but I can imagine
how frustrating it must be to constantly hack at the weeds. :)
> Any advice on how to deal with this?
My approach, after my dreadful experience with COM, has been to
compromise only with GUI's. Anything else, such as databases,
networking, time, containers, security, signal processing [:)], file I/
O, even synchronization...I refused to compromise. I have built up a
library to abstract all of these elements away.
But that took a lot of time (years)...so...I would say...either get
busy writing libraries the way you want them...or hunt for what you
can use.
But you're right about being contaminated. The intellectual payback
for learning something like COM is near-zero compared to what you are
used to in signal processing. And for that matter, that includes all
the other stuff like C#, .NET, various IDL's, etc.
-Le Chaud Lapin-
Bob Hairgrove
On Sat, 26 May 2007 22:42:54 CST, Sam <sak...@yahoo.com> wrote:
>What's wrong in compiling Qt with this compiler (AFAIK Qt compiles with
>an enormous number of different C++ compilers) and use it as usual? This
>will only leave the COM stuff to deal with.
Yes, since Qt is implemented entirely in C++, a lot of grief can be
spared by using it (especially WRT the libraries which you can
compile yourself).
The latest version of Qt (4.x) has support for COM, at least on the
Windows platform. However, the corresponding modules are missing from
the open source distribution, so I haven't used it yet. And I have no
idea how, or if, they have also implemented it in the package for
other OS's.
--
Bob Hairgrove
NoSpam...@Home.com
Ulrich Eckhardt
> Even worse, I bought a non-MS brand compiler, where lots of small
> details differ from "usual" C/C++ conventions: Class members are
> open for direct access (it seems everything by default is declared
> public), indexes start from 1, not 0, and so on.
What? Please, which compiler is that? The reason I ask is that such
behaviour is seriously broken according to both the C and C++ standards,
and the public should be aware of it. In any way, return this 'thing' to
the vendor, it for sure is not a C or C++ compiler worth its name! If you
want a compiler, I'd suggest GCC for win32. It comes with DevC++ (from
bloodshed.net), a complete IDE, for free or separately as either mingw32 or
with Cygwin.
> Doing things
> *slightly* different than the competitor is a commercial trap:
> At first, one find these idiosyncracities awkward; with time
> one accept them and start using them, until the point where the
> cost of undoing things become too overwhelming, and one is
> stuck with the commercial vendor.
>
> To me, this is deja vu all over again: I am slowly getting myself
> entagled in a web with commercial traps are all over the place.
> I can't avoid that, for the components specifically related to
> COM, but the influence from these commercial tools get to me,
> in general throwing sand in the macinery and a messed-up focus,
> ultimately resulting in non-portable code.
I'd say that a good lot of making code portable involves either using
inherently portable things or to know which parts are platform specific and
at least keeping them separate from the rest.
My advice: get a real C++ compiler, the rest isn't that bad. However, I
can't comment on how far COM is portable, but if you want it to remote
control MS Word, I don't think that matters much anyway.
Uli
Lance Diduck
> How should one deal with this situation? I am alrady doing
> my best to separate the various components in the programs;
> keeping the useful stuff separate from GUIs and COM blocks.
> Still, i have this nagging feeling that all these various idiosyncracities
> of the various commercial tools and libraryes sneak into my mind
> and way of thinking, if not (yet) all the way into my code.
>
> Any advice on how to deal with this?
>
> Rune
vast majority of my code using it. All of the code in production
however runs on AIX or Solaris.
First piece of advice: set up an environment like Linux or Solaris
that will compile and run your code. As other posters have suggested,
it doesn't have to be all of the code, but it can be a significant
amount. This will force you to keep the code portable. Install CPPUNIT
or other such unit tester (works well on Windows and UNIX) to run
tests that do not depend on platform.
Second: Install libraries on Windows, or make wrappers, that make
system call look the same on Windows and UNIX. For example, there are
POSIX thread wrappers that sit on top of Windows threads. Also, you
can take a look at libraries like Apache or Boost to see how they make
platform independent wrappers.
Third: For COM looks at tools like COMstl
http://synesis.com.au/software/comstl/
Matthew Wilson has done considerable work in making platform
independent COM tools. These libraries keep you thinking C++ while you
are working with Microsoft specific functionality.
Fourth: make a python interface to your libraries. If nothing else, it
will force you to think in terms of "what really needs COM" and what
doesn't. The more you can put into the latter the better.
Fifth- do everything you can to stay away from "Managed C++." Or
anything .NET . You can consider it this way: If .NET was as fantastic
as MS marketers would have you believe, then Microsoft Office,
Internet Explorer, and many other applications would written in
nothing but .NET . They are not. They are in fact C/C++ applications.
There is something to be said for that.
So the real point is: that if you need to build portable code, then
set up your build environment that makes you write portable code.
Programming specifically for the Windows platform does not make anyone
less of a programmer. It is unfortunate that Microsoft did a horrible
disservice to themselves a while back with their "embrace and extend"
philosophy toward portability. This has changed in recent years: their
C++ compiler is one of the most standards compliant available-- they
have moved a lot of their marketing extensions into their own
proprietary C# language -where it should have been all along. (and the
only thing that C# has in common with C++ is that they both have a 'C'
in the name).
Lance
fideli...@gmail.com
> Any advice on how to deal with this?
I'm surprised that no one has suggested this, but this seems like a
good place to use Java. Your primary concern seems to be portability
while still being able to use GUI components, etc. This is exactly
what Java was designed for. Your statement that you came back to C++
because of better standardization so you could cross-compile (a
paraphrase) also supports the idea that your primary requirement is
cross-platform functionality. I realize that this is "comp.lang.c+
+.moderated" but I believe your answer is to be had elsewhere. Take a
look at the latest generation of Java VMs, they have significantly
improved in terms of speed and ease of use. The only real downside of
Java in this case is that it doesn't handle math extremely well, for
those cases I'd recommend writing libraries in C++ (those portions
should recompile very well for any platform since they don't do
anything platform specific). You can hook these up to your Java with
JNI.
Rune Allnor
> On May 26, 6:07 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>
> > Any advice on how to deal with this?
>
> I'm surprised that no one has suggested this, but this seems like a
> good place to use Java. Your primary concern seems to be portability
> while still being able to use GUI components, etc. This is exactly
> what Java was designed for.
Ah, sorry, I didn't say that, but my work is with large-volume,
high-throughput data processing. Seismics and sonar data, where
we are talking data sets on the order of tens of GB as the norm.
I need C++ for the performance.
Rune
Rune Allnor
To save the number of replies I answer here: Borland
Trubo C++ 2006. While it works as a core C++ compiler
and IDE for my own stuff (tested in console applications)
the general philosophy seems to be that it is a C++
interface to a Delphi workhorse. As I remember from
my days coding Turbo Pascal, the indexing was one
of the main differences between C and Pascal.
All the indexes I have found so far, even in the COM
libraries, start at 1. I would assume this is a
consequence of TC++ being designed on top of Delphi.
On 27 May, 11:01, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> On May 26, 6:07 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>
> > The last few months I have extended my horizon -- I'm a 'fallen' UNIX
> > programmer -- into the Windows world. In my day-job, MSWord and
> > Excel are *the* tools to use. Nothing I can do about that. So I decided
> > to get a C++ Compiler/IDE with COM automation capacities.
>
> Why do you need to use Excel/Word? I have followed some of your posts
> in comp.dsp, so I guess I could see how you might be driving Excel,
> but why Word?
My assigned tasks in my day-job is -- seriously! -- to move
data between Excel worksheets and, occasionally, to paste
some of those data into a Word document. That's it.
> > This is a mine-field what my philosophy about writing as portable
> > code as possible is concerned. COM and Win bring me, by default
> > into the Microsoft herd; I have no choise but to hang on to their
> > marketing decisions.
>
> COM is, in my opinion, one of the biggest untruths that Microsoft has
> tricked gullible managers and programmers into using. I was forced to
> use it to write two shell namespace extensions (NSE's). Find a way to
> break free if you can.
No way! The alternative to not using COM is to do all the
menial tasks -- and there are only menial tasks -- manually,
with all the pain caused by the occasinal glitch.
> In fairness to Microsoft, the free version of their C++ IDE,, Visual
> Studio Express 2005 [http://msdn.microsoft.com/vstudio/express/visualc/
> default.aspx] is simply state-of-the-art.
> I can tell you with 100% certainty that
> Microsoft did make it so that, if you want to avoid being trapped, you
> can do so.
OK, I'll admit that I may have a bias opinion against
Microsoft. I will have to check out their compiler, then.
> > How should one deal with this situation?
> programmers have indeed become contaminated by not properly defending
> their minds from its "model". Based on your posting in comp.dsp, I do
> not think you are in any danger of this happening,
Eh... I don't know if that's a good thing or bad thing...
> but I can imagine
> how frustrating it must be to constantly hack at the weeds. :)
Based on recent exchanges on comp.dsp, I can fully sympathize
with Sisyfos...
> But you're right about being contaminated. The intellectual payback
> for learning something like COM is near-zero compared to what you are
> used to in signal processing. And for that matter, that includes all
> the other stuff like C#, .NET, various IDL's, etc.
Agreed. Some of the other responders reminded me about the
commercial version of Qt. I already plan to base my GUI work
on that library (the open source edition); maybe the
commercial edition which includes COM is worth its $$$...
Rune
John Moeller
> On 27 May, 19:30, fidelisde...@gmail.com wrote:
>> On May 26, 6:07 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>>
>>> Any advice on how to deal with this?
>> I'm surprised that no one has suggested this, but this seems like a
>> good place to use Java. Your primary concern seems to be portability
>> while still being able to use GUI components, etc. This is exactly
>> what Java was designed for.
>
> Ah, sorry, I didn't say that, but my work is with large-volume,
> high-throughput data processing. Seismics and sonar data, where
> we are talking data sets on the order of tens of GB as the norm.
> I need C++ for the performance.
Right, and as "fidelisdecus" also wrote, you can use C++ in the areas of
your program that are hardware-bound, through a JNI interface.
Additionally, many of the so-called "performance problems" that are
arrayed against Java are myths. A lot of these exist because they were
real problems at the outset for Java. There has been a lot of work done
to resolve these, however.
Before anyone accuses me of being a shill for the enemy, I will state
that for hardware-bound problems, C++ is still king. Native code can
just crunch numbers and move data faster. But that's why JNI exists.
--
John Moeller
fish...@gmail.com
John Moeller
>> But you're right about being contaminated. The intellectual payback
>> for learning something like COM is near-zero compared to what you are
>> used to in signal processing. And for that matter, that includes all
>> the other stuff like C#, .NET, various IDL's, etc.
>
> Agreed. Some of the other responders reminded me about the
> commercial version of Qt. I already plan to base my GUI work
> on that library (the open source edition); maybe the
> commercial edition which includes COM is worth its $$$...
Be careful. Qt's commercial license expressly prohibits you from
starting development for a project with the GPL version, and then switch
to the commercial version. Make sure that you develop your project on
the commercial version the whole way if you plan to use it at all.
--
John Moeller
fish...@gmail.com
Sam
> A couple of other responders asked me what compiler I use.
> To save the number of replies I answer here: Borland
> Trubo C++ 2006. While it works as a core C++ compiler
> and IDE for my own stuff (tested in console applications)
> the general philosophy seems to be that it is a C++
> interface to a Delphi workhorse. As I remember from
> my days coding Turbo Pascal, the indexing was one
> of the main differences between C and Pascal.
>
> All the indexes I have found so far, even in the COM
> libraries, start at 1. I would assume this is a
> consequence of TC++ being designed on top of Delphi.
>
It seems strange that you've come to this conclusion.
The only place where indexing starts from 1 that I can remember from the
top of my head, is the AnsiString class, a wrapper around the Delphi
string type. Even there, if you call c_str() you get a const char * to
the internal data (like std::string). Even the majority of the Delphi
container classes and components use indexes starting at 0.
I overall consider VC++ a much better compiler but I still use Turbo C++
2006 Explorer (the free version) for small, quick and dirty Win32 GUI
programs.
Sam.
Rune Allnor
> Rune Allnor wrote:
> > A couple of other responders asked me what compiler I use.
> > To save the number of replies I answer here: Borland
> > Trubo C++ 2006. While it works as a core C++ compiler
> > and IDE for my own stuff (tested in console applications)
> > the general philosophy seems to be that it is a C++
> > interface to a Delphi workhorse. As I remember from
> > my days coding Turbo Pascal, the indexing was one
> > of the main differences between C and Pascal.
>
> > All the indexes I have found so far, even in the COM
> > libraries, start at 1. I would assume this is a
> > consequence of TC++ being designed on top of Delphi.
>
> It seems strange that you've come to this conclusion.
>
> The only place where indexing starts from 1 that I can remember from the
> top of my head, is the AnsiString class, a wrapper around the Delphi
> string type.
AnsiString and the various COM OLE objects are the only
no-standard classes I need to use, and both start indexing
from 1. I have no intentions about starting to use any of these
other Borland-specific components unless I am absolutelty
forced to.
Rune
Jerry Coffin
[ ... ]
> Additionally, many of the so-called "performance problems" that are
> arrayed against Java are myths. A lot of these exist because they were
> real problems at the outset for Java. There has been a lot of work done
> to resolve these, however.
Much of what's been said over the years in favor of Java is mythical as
well. Entire threads (quite a few of them, in fact) have been written
about many of the benchmarks that purport to show that Java is faster
than C or C++. I've looked at several such benchmarks, and found that
mostly they show the authors had no clue of how to write C or C++ well
at all (or maybe they were intentionally writing it terribly).
For one example, see:
{ Link checked. -mod }
--
Later,
Jerry.
The universe is a figment of its own imagination.
Rune Allnor
> Rune Allnor wrote:
> >> But you're right about being contaminated. The intellectual payback
> >> for learning something like COM is near-zero compared to what you are
> >> used to in signal processing. And for that matter, that includes all
> >> the other stuff like C#, .NET, various IDL's, etc.
>
> > Agreed. Some of the other responders reminded me about the
> > commercial version of Qt. I already plan to base my GUI work
> > on that library (the open source edition); maybe the
> > commercial edition which includes COM is worth its $$$...
>
> Be careful. Qt's commercial license expressly prohibits you from
> starting development for a project with the GPL version, and then switch
> to the commercial version. Make sure that you develop your project on
> the commercial version the whole way if you plan to use it at all.
Seems like an awkward thing to do? I would imagine a marketing
strategy where one gets people hooked on the free thing, and then
they would just *have* to get to the "real thing" at later stages?
That's pretty much how matlab gained such market shares; very
inexpensive student and academic lisences. They then realized
huge income from this marketing investment when the students
got out to industry and needed matlab -- commercial licenses,
of course -- to get any work done.
Rune
--
Mathias Gaunard
> Be careful. Qt's commercial license expressly prohibits you from
> starting development for a project with the GPL version, and then switch
> to the commercial version. Make sure that you develop your project on
> the commercial version the whole way if you plan to use it at all.
It seems the OP is only using the application in-house and is not
redistributing it.
Therefore that restriction doesn't apply I think.
--
Branimir Maksimovic
> Rune Allnor wrote:
> > On 27 May, 19:30, fidelisde...@gmail.com wrote:
> >> On May 26, 6:07 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>
> >>> Any advice on how to deal with this?
> >> I'm surprised that no one has suggested this, but this seems like a
> >> good place to use Java. Your primary concern seems to be portability
> >> while still being able to use GUI components, etc. This is exactly
> >> what Java was designed for.
>
> > Ah, sorry, I didn't say that, but my work is with large-volume,
> > high-throughput data processing. Seismics and sonar data, where
> > we are talking data sets on the order of tens of GB as the norm.
> > I need C++ for the performance.
>
> Right, and as "fidelisdecus" also wrote, you can use C++ in the areas of
> your program that are hardware-bound, through a JNI interface.
>
> Additionally, many of the so-called "performance problems" that are
> arrayed against Java are myths. A lot of these exist because they were
> real problems at the outset for Java. There has been a lot of work done
> to resolve these, however.
>
> Before anyone accuses me of being a shill for the enemy, I will state
> that for hardware-bound problems, C++ is still king. Native code can
> just crunch numbers and move data faster. But that's why JNI exists.
Except that JNI is cumbersome and is useful only if few java
classes has to use native api.
Writing just C++ wrappers for some native library is much easier then
writing C or C++ wrappers that also provide stubs for JNI. Java has
advantage of standard gui library, but it is questionable is it worth
the effort if majority of code will be C++,
but java will be used just for ui.
Java apps stick to particular platform and also particular version
of platform while C++ apps rely on wrappers.
C++ has boost, which provides pretty much all system specific
utilities and perhaps library such as wxWidgets for gui development,
which is alternative to commercial Qt.
For com development microsoft C++ compiler is ok, but there is not
much help for portable code there as COM is binary standard
for particular vtable implementation with specific calling convention
and types. So if C++ compiler is not binary compatible I can see no
advantage in using C++ over assembler in such cases ;)
Greetings, Branimir.
--
hast...@hotmail.com
> A couple of other responders asked me what compiler I use.
> To save the number of replies I answer here: Borland
> Trubo C++ 2006. While it works as a core C++ compiler
> and IDE for my own stuff (tested in console applications)
> the general philosophy seems to be that it is a C++
> interface to a Delphi workhorse. As I remember from
> my days coding Turbo Pascal, the indexing was one
> of the main differences between C and Pascal.
Are you positively sure that Turbo C++ array indexes
begin at 1 ?
Turbo C++ claims to be an Ansi C compiler, and I would
be surprised that Borland/CodeGear got that one wrong.
Especially given that they also claim to be able to
use the dinkumware library, which presumably wouldn't
work with 1 based arrays
> the general philosophy seems to be that it is a C++
> interface to a Delphi workhorse. As I remember from
> my days coding Turbo Pascal, the indexing was one
> of the main differences between C and Pascal.
Seconding Sam, this is essentially not the case in
Delphi, making the whole issue even more strange.
--- Raoul
Rune Allnor
> Rune Allnor wrote:
> > On 27 May, 19:30, fidelisde...@gmail.com wrote:
> >> On May 26, 6:07 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>
> >>> Any advice on how to deal with this?
> >> I'm surprised that no one has suggested this, but this seems like a
> >> good place to use Java. Your primary concern seems to be portability
> >> while still being able to use GUI components, etc. This is exactly
> >> what Java was designed for.
>
> > Ah, sorry, I didn't say that, but my work is with large-volume,
> > high-throughput data processing. Seismics and sonar data, where
> > we are talking data sets on the order of tens of GB as the norm.
> > I need C++ for the performance.
>
> Right, and as "fidelisdecus" also wrote, you can use C++ in the areas of
> your program that are hardware-bound, through a JNI interface.
>
> Additionally, many of the so-called "performance problems" that are
> arrayed against Java are myths. A lot of these exist because they were
> real problems at the outset for Java. There has been a lot of work done
> to resolve these, however.
>
> Before anyone accuses me of being a shill for the enemy, I will state
> that for hardware-bound problems, C++ is still king. Native code can
> just crunch numbers and move data faster. But that's why JNI exists.
I see that the simple argument for my choice of using C++
does not work in the present company... oh well.
A significant part of the explanation for me choosing C++
is that I am getting older and don't grasp new concepts
quite as easily as I used to. If I ever am to learn another
programming language, it will probably be C#, since that
will allow me to play with COM stuff without contaminating
the C++ parts of my mind.
While me slowing down is significant, the main reason
for me choosing C++ is that C++ lets me do stuff no
other language lets me do. Other languages are object
oriented -- more so than C++. Other languages make
nice GUIs -- easier than with C++. Others languages
are better for numerics. And so on.
C++ lets my mind play at full power while reducing the
hazzle of getting results. That used to be the attraction
with matlab, and the main reason why I started using
matlab. However, in my present situation, C++ is the
only language which lets me -- a way less than average
programmer but somewhat skilled engineer -- play with
advanced ideas in my main field of work. Some of the
ideas I am playing with have not been tested outside
small-scale labs, if at all. The complexity of getting
a working system up and running -- not to mention a
system on industial scale -- has never been done
before, for the single reason that everything needed
has to fit into one person's mind for the ideas to
come together.
C++ lets me *both* play with my ideas *and* test
them in applications on a scale which makes sense in
the industry. Once everyone have seen the ideas up
and running, the theorists can improve on the concept;
the programmers on the implementation; the users
on the work flow. But putting everything together
for the first time is one man's task. If I am to
be that man -- I have no idea yet if I will succeed
in my attempts -- it will be because C++ is the
tool which pulls the overall objective inside
my reach.
Rune
--
Rune Allnor
> On May 28, 3:26 am, John Moeller <fishc...@gmail.com> wrote:
>
> > Be careful. Qt's commercial license expressly prohibits you from
> > starting development for a project with the GPL version, and then switch
> > to the commercial version. Make sure that you develop your project on
> > the commercial version the whole way if you plan to use it at all.
>
> It seems the OP is only using the application in-house and is not
> redistributing it.
> Therefore that restriction doesn't apply I think.
My plan was -- before John made his comment -- to use
Qt GPL version to get an in-house demo up and running as
proof of concept. Not to be distributed anywhere, just
so people can see my ideas in working condition on *my*
PC. Once somebody say "I want one of those!" and is
willing to pay for it, I intend(ed) get the commercial
version of Qt, for the "real" implementation.
If there is anything in the Qt lisence which prevents
this, please let me know!
Rune
John Moeller
> Seems like an awkward thing to do? I would imagine a marketing
> strategy where one gets people hooked on the free thing, and then
> they would just *have* to get to the "real thing" at later stages?
> That's pretty much how matlab gained such market shares; very
> inexpensive student and academic lisences. They then realized
> huge income from this marketing investment when the students
> got out to industry and needed matlab -- commercial licenses,
> of course -- to get any work done.
From the Qt Commercial Licensing page:
"You must purchase a Qt Commercial License from Trolltech or from any of
its authorized resellers before you start developing. The Commercial
license does not allow the incorporation of code developed with the Open
Source Edition of Qt into a proprietary product."
I find this strategy a bit puzzling as well. You'd think they'd get
farther by offering a "taste" with the GPL version, and then offer the
commercial one if you want to upgrade. Oh well.
--
John Moeller
fish...@gmail.com
John Moeller
> In article <f3cst5$8bo$1...@news.xmission.com>, fish...@gmail.com says...
>
> [ ... ]
>
>> Additionally, many of the so-called "performance problems" that are
>> arrayed against Java are myths. A lot of these exist because they were
>> real problems at the outset for Java. There has been a lot of work done
>> to resolve these, however.
>
> Much of what's been said over the years in favor of Java is mythical as
> well. Entire threads (quite a few of them, in fact) have been written
> about many of the benchmarks that purport to show that Java is faster
> than C or C++. I've looked at several such benchmarks, and found that
> mostly they show the authors had no clue of how to write C or C++ well
> at all (or maybe they were intentionally writing it terribly).
I won't argue with that. What is it about lies and damn lies? :)
Anyway, I agree with you, but a lot of that is just language wars. You
could argue that badly-written code in Java isn't a good argument for
C++ either.
My side comments are probably a little too OT; I didn't mean to start a
language war here; just to reiterate that you can bring fast C++ code
into Java code. All I was trying to say is that you should make your
choice about Java or not Java (or any language, for that matter)
considering more than just performance. Sorry for the miscommunication.
--
John Moeller
fish...@gmail.com
John Moeller
and contain some C++ material. -mod }
I agree 100%. I have some experience with JNI, and I can tell you that
limiting its use to a few choice places is far better than using it as a
silver bullet.
> Writing just C++ wrappers for some native library is much easier then
> writing C or C++ wrappers that also provide stubs for JNI. Java has
> advantage of standard gui library, but it is questionable is it worth
> the effort if majority of code will be C++,
> but java will be used just for ui.
Hm. I don't know if I agree here. Like I said in a different post,
though, I'm not trying to start a language war, so I'll just leave it at
that.
> Java apps stick to particular platform and also particular version
> of platform while C++ apps rely on wrappers.
I'm not sure what you mean here.
> C++ has boost, which provides pretty much all system specific
> utilities and perhaps library such as wxWidgets for gui development,
> which is alternative to commercial Qt.
Honestly, I'm becoming more and more disillusioned with GUI frameworks
(like wxWidgets or Qt) as time goes on. I don't need something to
replace my main or dllmain, or whatever. That just gets in the way. I
believe that something lighter weight, like a GUI toolkit, is better.
You can code your core so that it could work with many different UI's,
whether they are GUI frameworks or GUI toolkits or even UI's offered by
other languages.
--
John Moeller
fish...@gmail.com
Jerry Coffin
[ ... ]
> You could argue that badly-written code in Java isn't a good argument
> for C++ either.
True -- but I don't think I've seen a web site devoted to claiming that
C++ is faster than Java, quoting "benchmarks" that appear to be based
primarily or exclusively on the fact that the Java being tested was
written exceedingly badly. Admittedly, in one case I did show how to
improve the speed of the Java in one benchmark by a fairly significant
margin (~2.5:1, if memory serves) but it was on a site devoted to
showing that Java was faster, not vice versa.
> My side comments are probably a little too OT; I didn't mean to start a
> language war here; just to reiterate that you can bring fast C++ code
> into Java code. All I was trying to say is that you should make your
> choice about Java or not Java (or any language, for that matter)
> considering more than just performance. Sorry for the miscommunication.
Quite all right. I haven't made a lot of use of JNI (nor do I know
anybody who has) so perhaps my experience was due mostly to ignorance,
not deficiencies in the interface itself. My experience, however, was
that it was more trouble than it was worth -- using JNI to mix Java and
C++ was more work than just writing the whole thing in C++. Different
requirements (e.g. portable GUI code) might have justified the extra
work, but in my case the original idea was to save work, and we quickly
found that it just wasn't going to do that.
Then again, that was quite a while ago too -- and Java's GUI library has
grown quite a bit since, so now even for the requirments I had, the
mixture might work out better than it did then.
--
Later,
Jerry.
The universe is a figment of its own imagination.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Branimir Maksimovic
>
> My plan was -- before John made his comment -- to use
> Qt GPL version to get an in-house demo up and running as
> proof of concept. Not to be distributed anywhere, just
> so people can see my ideas in working condition on *my*
> PC. Once somebody say "I want one of those!" and is
> willing to pay for it, I intend(ed) get the commercial
> version of Qt, for the "real" implementation.
>
> If there is anything in the Qt lisence which prevents
> this, please let me know!
Of course:
http://trolltech.com/developer/downloads/qt/windows
Qt is commercial product. It has gpl version only because
KDE is built with it, I guess. So their open source version
allows only free, gpl-ed software, you can't even compile
commercial product with it. Also, on windows,
only gcc is supported, you can't use it with borland
compiler, I think.
But, you can evaluate product, before purchasing it,
so I guess that is same thing that you want to do,actually.
If you didn't know, there is free alternative to
qt, http://www.wxwidgets.org/ and also if any help
there is http://sourceforge.net/projects/wxactivex.
wxWidgets is completely free library but not as nice
as Qt, but:
"The wxWindows Licence is essentially the L-GPL (Library General
Public Licence), with an exception stating that derived works in
binary form may be distributed on the user's own terms. This is a
solution that satisfies those who wish to produce GPL'ed software
using wxWidgets, and also those producing proprietary software."
Greetings, Branimir.
Bjørn Roald
> On 28 May, 15:34, Mathias Gaunard <loufo...@gmail.com> wrote:
>> On May 28, 3:26 am, John Moeller <fishc...@gmail.com> wrote:
>>
>>> Be careful. Qt's commercial license expressly prohibits you from
>>> starting development for a project with the GPL version, and then switch
>>> to the commercial version. Make sure that you develop your project on
>>> the commercial version the whole way if you plan to use it at all.
>> It seems the OP is only using the application in-house and is not
>> redistributing it.
>> Therefore that restriction doesn't apply I think.
>
> My plan was -- before John made his comment -- to use
> Qt GPL version to get an in-house demo up and running as
> proof of concept. Not to be distributed anywhere, just
> so people can see my ideas in working condition on *my*
> PC. Once somebody say "I want one of those!" and is
> willing to pay for it, I intend(ed) get the commercial
> version of Qt, for the "real" implementation.
>
> If there is anything in the Qt lisence which prevents
> this, please let me know!
As long as you accepts that your work will be under the GPL license you
are Ok. But if you want the commercial license, where you can keep your
secrets, the commercial license is needed from day one. Once GPL,
always GPL, that is the problem. It is really not much TrollTech can do
about that, it is a trait of the GPL. Note that they make you choose
between the two licenses, there is never a situation where both apply at
the same time.
--
Bjørn
Otis Bricker
news:1180368155.1...@m36g2000hse.googlegroups.com:
> On 28 May, 15:34, Mathias Gaunard <loufo...@gmail.com> wrote:
>> On May 28, 3:26 am, John Moeller <fishc...@gmail.com> wrote:
>>
>> > Be careful. Qt's commercial license expressly prohibits you from
>> > starting development for a project with the GPL version, and then
>> > switch to the commercial version. Make sure that you develop your
>> > project on the commercial version the whole way if you plan to use
>> > it at all.
>>
>> It seems the OP is only using the application in-house and is not
>> redistributing it.
>> Therefore that restriction doesn't apply I think.
>
> My plan was -- before John made his comment -- to use
> Qt GPL version to get an in-house demo up and running as
> proof of concept. Not to be distributed anywhere, just
> so people can see my ideas in working condition on *my*
> PC. Once somebody say "I want one of those!" and is
> willing to pay for it, I intend(ed) get the commercial
> version of Qt, for the "real" implementation.
>
> If there is anything in the Qt lisence which prevents
> this, please let me know!
>
Wouldn't it be better to contact the company directly? Asking here will
only get you opinions unless someone from TrollTech is participating.
Otis
Markus Schoder
The "once GPL, always GPL" thing is not true in general. You can always
switch to a different license for your own work if you no longer make
use of GPL components.
Only if you have already distributed a GPL version of your work this
version will stay under GPL forever (almost). You are free to distribute
new versions under a different license though.
Trolltech of course does not want you to do all development with the GPL
QT version and then only once you are ready to release switch to the
commercial version. But that is solely their decision nothing in the GPL
forces them to do that.
--
Markus Schoder
Le Chaud Lapin
> C++ lets me *both* play with my ideas *and* test
> them in applications on a scale which makes sense in
> the industry. Once everyone have seen the ideas up
> and running, the theorists can improve on the concept;
> the programmers on the implementation; the users
> on the work flow. But putting everything together
> for the first time is one man's task. If I am to
> be that man -- I have no idea yet if I will succeed
> in my attempts -- it will be because C++ is the
> tool which pulls the overall objective inside
> my reach.
I can understand your apprehension. You have ideas of what you want
to do, and basic on your training in another discipline seems like
the right language, especially after having a taste of Pascal.
But you want to make a complete system, and a complete system involves
not just the guts, but binding to the environment that surrounds the
guts. That means a GUI, and there are many choices with the GUI. You
probably remember how painful it was to acquire certain bits of
knowledge [Kalman filters come to mind], and you are cautious to
expend that type of brain energy on something that with uncertain
intellectual payback, not to mention a step learning curve. No one
wants to spend a week just to learn how to reliably draw a Bode plot
in a Window.
I can say two things to this:
1. IMO, the GUI frameworks have not yet matured to the point where a
programmer can point to just one of them and say, "This is the one
that was done right." There are lot of people trying though.
2. When someone succeeds in making a GUI framework, there is a cost -
You will have to use their list<> instead of std::list<> for example.
Many programmers are just now learning that there is not such thing as
amorphous, vague primitives that mix and match nicely together.
Something simple as a list<> class in one framework will bring the
world down upon you. Type is binding, and irreverence for this fact
will cause much pain and suffering.
3. Language matters. I am also an electrical engineer whose first
Algol-language was Pascal. I was in same situation, years ago,
asking, "Is this worth it?" while looking at Stroustrup's book. The
mind vacillates rapidly between "build" or "buy". I took the plunged,
and I can tell you without hesitation, C++ is worth every moment you
spend with it. The other languages, IMO, has less ROI. There are some
that say that code is code, and a language is simply something to let
you write programs. I would be wary of statements like this. They
indicate, IMO, a lack of appreciation for proper primitives that might
generate good form. As you pointed out, C++ is most liberating.
But you're probably wondering about how best to put a face on your
application. I would not go to Java or C# or any .NET stuff just to
get a GUI. And I am not certain that your statement that C# will let
you keep your C++ knowledge uncontaminated. Microsoft wants managers
and programmers the world over to believe this. They actually have a
new language called C++/CLI which they were promoting as a natural
extension to C++. An article was being written called "Pure C++" that
was anything but pure, so as to imply that "it's ok, the candy is
safe, eat it." Fortunately that untruth has since been corrected, but
you get the point - you have to guard what you learn, as you already
know.
My path in this situation was to stay with "pure C++", pure as in the
standard and the standard only. I then did something that might or
might not have been wise. I put much effort into studying the Win32
API. I wrote my GUI's using the native Win32 API. :(
Not a super pleasant experience, to be honest. Not as disturbing as
COM, but not fun. However, given the current state of GUI frameworks,
you almost have to do this. The frameworks, including MFC, simply
wrap the Win32 API on Windows, many not very well. In other words,
they do not fix the (broken) model, they simply give you a pile of
functions that can be invoked and declare it sufficient.
I would study the Win32 GUI functions just enough until you understand
what Microsoft was thinking, what they did when they made the GUI
framework. A bit of mind first, a bit of hand...the usual process.
Then after you have your bearings, decide what GUI framework you want
to use. I would avoid choosing a language based on the GUI model
alone. IMO, none of the new languages popping up lately will ever
surpass C++ in power or longevity. That would be like saying the
phasor method will replace H(s) because phasors are so much easier to
use. There are a lot of people who would like for that to happen, but
it never will.
-Le Chaud Lapin-
Branimir Maksimovic
> Branimir Maksimovic wrote:
>
> > Java apps stick to particular platform and also particular version
> > of platform while C++ apps rely on wrappers.
>
> I'm not sure what you mean here.
Just to clarify myself, I have meant to say that portability
of java applications is based on single platform and it's
library, while portability of C++ applications is based on
multiple platforms and wrappers for different libraries.
Java applications have problems when version of platform
changes, so as C++ wrappers for different versions of library.
So my point is that java wouldn't be better choice if portability is
concern. I think they are about same.
>
> > C++ has boost, which provides pretty much all system specific
> > utilities and perhaps library such as wxWidgets for gui development,
> > which is alternative to commercial Qt.
>
> Honestly, I'm becoming more and more disillusioned with GUI frameworks
> (like wxWidgets or Qt) as time goes on. I don't need something to
> replace my main or dllmain, or whatever. That just gets in the way.
Agreed. I usually start with tiny wrapper for either, just to satisfy
basic needs and add library functionality per usage basis.
So it happened to me that I did some application with wxWindows
and boss suddenly decides to go with Qt so I've ported application
in short time.
> You can code your core so that it could work with many different UI's,
> whether they are GUI frameworks or GUI toolkits or even UI's offered by
> other languages.
Agreed. In house lightweight gui toolkit is best option,
but for single developer perhaps there is no time to do that.
All in all, this is not much about C++, so this is all I have
to say about this subject.
Greetings, Branimir.
--
Mathias Gaunard
> Qt is commercial product. [...]
> So their open source version
> allows only free, gpl-ed software,
Their open source version is under the GPL.
That only means that if you distribute any derived work of Qt (any
application that makes use of it), it must be under a GPL-compatible
license.
So, if you don't redistribute your derived work, then GPL imposes no
restriction.
> you can't even compile
> commercial product with it.
To begin with, a "commercial product" could perfectly be under a GPL-
compatible license. That's one of the basic freedoms of the Free
Software Definition.
If you just compile something anyway, as I said earlier, there is no
restriction with the GPL. The GPL only has restrictions for
distribution.
> Also, on windows,
> only gcc is supported, you can't use it with borland
> compiler, I think.
The sources are provided, you're free to adapt them to the C++
compiler of your choice.
Branimir Maksimovic
> On May 29, 2:32 am, Branimir Maksimovic <b...@hotmail.com> wrote:
>
> > Qt is commercial product. [...]
> > So their open source version
> > allows only free, gpl-ed software,
>
> Their open source version is under the GPL.
> That only means that if you distribute any derived work of Qt (any
> application that makes use of it), it must be under a GPL-compatible
> license.
I think that they are more restrictive then gpl as
their site states that only free non commercial software
can use their open source version, what I said I just
reinterpreted from their words. Also they state about differences
between commercial and open source version that
they don't support other compilers than gcc on windows
(for open source version).
As I understand GPL does not prevents making commercial
software or compiling it with GPL=ed software,
but is about source distribution with binaries,
which is different then what I read about Qt.
Could you check trolltech site and see if I misinterpreted
something?
Greetings, Branimir.
Lourens Veen
> Rune Allnor wrote:
>> Seems like an awkward thing to do? I would imagine a marketing
>> strategy where one gets people hooked on the free thing, and then
>> they would just *have* to get to the "real thing" at later stages?
>> That's pretty much how matlab gained such market shares; very
>> inexpensive student and academic lisences. They then realized
>> huge income from this marketing investment when the students
>> got out to industry and needed matlab -- commercial licenses,
>> of course -- to get any work done.
>
> From the Qt Commercial Licensing page:
>
> "You must purchase a Qt Commercial License from Trolltech or from
> any of its authorized resellers before you start developing. The
> Commercial license does not allow the incorporation of code
> developed with the Open Source Edition of Qt into a proprietary
> product."
>
> I find this strategy a bit puzzling as well. You'd think they'd get
> farther by offering a "taste" with the GPL version, and then offer
> the
> commercial one if you want to upgrade. Oh well.
That's what I thought. But then I figured that the proprietary
licencing is per-seat, and that without this provision you could have
20 developers developing the entire programme using the GPL version
of QT, and then buy a single commercial seat licence to compile the
final to be distributed version. This provision means you have to buy
20 seat licences if you want to have 20 programmers build a
proprietary application using QT.
Lourens
--
ap...@student.open.ac.uk
> > commercial version of Qt. I already plan to base my GUI work
> > on that library (the open source edition); maybe the
> > commercial edition which includes COM is worth its $$$...
>
> Be careful. Qt's commercial license expressly prohibits you from
> starting development for a project with the GPL version, and then switch
> to the commercial version. Make sure that you develop your project on
> the commercial version the whole way if you plan to use it at all.
Another thing to be aware of with Qt is that it provides foundation
classes (OS abstractions etc) and GUI facilities. Sometines this is
what people want but sometimes people want to be able to keep the two
separate. If you are in the latter camp then something like ACE or
Boost might give you the foundation classes you need. Then there are
many GUI toolkits you could look at including Qt. Other possibilities
include FOX, FLTK, Gtk....
Regards,
Andrew Marlow
--
Mathias Gaunard
> I think that they are more restrictive then gpl as
> their site states that only free non commercial software
> can use their open source version
Maybe you misunderstood it, or maybe they were the ones that weren't
clear. The trolltech website tries to sell its stuff, not to be
pedantic. Everywhere they write "Open Source Edition", while the GPL
is a really specific open-source license, others aren't as
restrictive. Or maybe they're blurry on purpose, who knows.
Proprietary (not giving "freedom" of the software) and commercial
(selling a product) are orthogonal concepts. You can perfectly sell
free (as in free speech) software, even though it's not really
commercially viable if you want to sell the same product to many
people, since your clients can then redistribute it and steal your
market.
Actually, a license that prevents commercial usage can't be considered
a free software license at all. It's one of the basic principles of
the free software definition.
Anyway, this is getting a little off topic. If you want more detailed
and accurate information, I advise you to contact Trolltech directly.
They will certainly be more useful than a free software fanboy like me.