Re: Commercial traps: How to avoid?
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?
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-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]