In article <6tr8ua$36p$1@nnrp1.dejanews.com>,
  devphil@my-dejanews.com wrote:
> In article <6tm4qo$9cc$1@nnrp1.dejanews.com>,
>   jkanze@otelo.ibmmail.com wrote:
>
> [wrapping nonportable APIs]
> > > Sure it's possible.  It's ugly as sin, but it's possible.
> >
> > It's not only possible, it's significantly cleaner than not doing so.
>
> So instead of tying yourself to the platform's proprietary extensions and
> API, you tie yourself to a third-party's extensions and API.  You still
> have to hope and pray that the third-party code is portable, /plus/ you
> now have to convince coworkers (and other client codewriters) to use it.

Do this: use a third-party API that seems relatively "clean." That is,
look for one that doesn't have too many "old" calls for compatibility
with old versions, or "native" hooks for accessing the underlying data.
You now have a "worst case" scenario for porting to some platform P,
even if the third-party API hasn't been ported there: the scenario
requires you to develop the platform-P-equivalent of the third-party
API. If 20% of ports require this, you've still come out way ahead
of writing it yourself for every platform.

> And if it costs money, you have to convince the managers to shell out the
> cash to purchase it.  Truly, it's less hassle and pain just to write one.

Always an available option, if the third-party APIs are too expensive
or too underpowered. (This is often the case when logically it shouldn't
be, such as for some oft-needed general-purpose packages.)

> > Of course, typically, you don't write the wrapper classes yourself;
> > you buy them in from a reliable third party.  Rogue Wave has some
> > wrappers for threads, or there are free versions from someone called
> > OMNI.
>
> As a student I couldn't afford anything that wasn't freeware

As a student you probably shouldn't waste your time planning to be
portable. This is a real-world goal, not a conceptual one.

> and now as a
> developer we're not allowed to buy anything for fear of cutting into some
> VP's six-digit salary.

Something that isn't typically taught in colleges that teach computer
programming, but should be: the Business Case.

    Summary: Purchase XYZ third-party software.

    Benefit: Expected to speed up 20% of our programming projects by
             10-50%, saving somewhere between $900,000 and $3,500,000
             over the next 3 years (depending on assumptions and
             utilization figures).

    Cost:    $1,250 for trial version; $50,000 to $200,000 for full
             version, depending on utilization levels.

Typically, six-figure-salary VPs read an additional three pages, and
provided they see reasonable documentation and nothing fraudulent,
they forward it to an SVP, who likewise reads it and forwards it to
an EVP, who reads it and forwards it to the CFO, who reads it and
signs at the dotted line. Then, each of the 5 executives involved
claims that they saved $3,500,000 -- but that's another story.

My point here is that you need to show the executives *why* they
should buy the software. Sell it properly and they will happily
buy -- or else the company is doomed anyway. (For more details on
what "doomed anyway" means, see
    http://www.unitedmedia.com/comics/dilbert )

> Pity all the freeware I've seen so far is buggy.
> Until a Standrd-conforming compiler becomes available, it's just not
> worth it.

At which point all the buggy freeware will suddenly, and magically,
become worth three to seventeen times as much as you originally paid
for it!

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:

[...]

> Contrast this to a "paint"-style drawing program, or a simulation
> of an electronic calculator. Both of these could be written to
> segregate the GUI aspects from the rest -- but here, you're likely
> to find that "the rest" is only 10% of the size of the GUI parts.
> Further, separating the GUI in this way may actually make the
> program harder to read/maintain, and perhaps even affect code size
> and performance.

The paint style program mostly deals with a very simple abstraction:
A rectangular area of m*n pixels, which each can be set to a given
color. In addition to setting individual pixels, there are some common
drawing commands like line, circle, ellipse, rectangle, pie.If you don't
find some operation you need, you must program it yourself anyway (like
if there's no "rectangle" operation, you'll have to draw the 4 lines
yourself).
It should not be too complicated to encapsulate that (and it will give
you the advantage to be able to work with extensions like "background"
color in transparent gifs without changing most of the program).
Also, you will have a set of tools (how they are selected is a GUI
question, of course), which operate on that pixel area, and a current
position (generally given by the mouse pointer - but that's a GUI
thing again; the logic is the same if it is moved through the joystick,
with the cursor keys, or even input directly into a dialog or a
command window; the latter may especially be useful). And then
there's keyboard input, of course.

With the electronic calculator simulation, the point is that most
of the GUI-independent part already is shipped with your compiler
(the math library).

[...]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

If it's a standard-conforming C++ compiler for Windows that you want,
then I highly recommend Metrowerks CodeWarrior.  This is an excellent
product.  CodeWarrior Pro 4 has just been released and boasts the
highest level of standard conformance available.  A few things that
CodeWarrior supports that you can't get with VC++ are exception
specifications, member templates, function-try-blocks, function template
partial ordering, covariant return types for virtual functions, and
correct lifetime for variables declared in "for" statements.  It is also
lightning fast compared to VC++.  See http://www.metrowerks.com/ for
more info.

-- Eric Lengyel


[ Moderator's note: This article reads like an advertisement,
  but was written in response to a request for information.
  I tried to ask the author to clarify whether he was connected
  with the product or was just a satisifed user, but email just
  bounced. -sdc ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3608497E.BB17623B@sierra.com>, Eric Lengyel
<elengyel@sierra.com> writes
>[ Moderator's note: This article reads like an advertisement,
>  but was written in response to a request for information.
>  I tried to ask the author to clarify whether he was connected
>  with the product or was just a satisifed user, but email just
>  bounced. -sdc ]

I do not know if he is, but you know I am not and I will provisionally
endorse his claims.  The provisional is because the product is too new
for me to assert that it does all those things correctly at all times.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6tm4qo$9cc$1@nnrp1.dejanews.com>,
  jkanze@otelo.ibmmail.com wrote:

[wrapping nonportable APIs]
> > Sure it's possible.  It's ugly as sin, but it's possible.
>
> It's not only possible, it's significantly cleaner than not doing so.

So instead of tying yourself to the platform's proprietary extensions and
API, you tie yourself to a third-party's extensions and API.  You still
have to hope and pray that the third-party code is portable, /plus/ you
now have to convince coworkers (and other client codewriters) to use it.
And if it costs money, you have to convince the managers to shell out the
cash to purchase it.  Truly, it's less hassle and pain just to write one.


> Of course, typically, you don't write the wrapper classes yourself;
> you buy them in from a reliable third party.  Rogue Wave has some
> wrappers for threads, or there are free versions from someone called
> OMNI.

As a student I couldn't afford anything that wasn't freeware, and now as a
developer we're not allowed to buy anything for fear of cutting into some
VP's six-digit salary.  Pity all the freeware I've seen so far is buggy.
Until a Standrd-conforming compiler becomes available, it's just not
worth it.


> > I've written such "wrapper" classes in the past, and recently recoded a
> > library for various kinds of atomic operations (mutexes, counting
semaphores).
> > The Standard Library didn't help me a bit, and the POSIX.1b realtime
> > extensions such as semaphores aren't supported in the recent Windows
compilers
> > such as VC++.
>
> There are things for which I don't know of a third party wrapper: shared
> memory, vmapping, and semaphores, for instance.  But if I had to do them,
> regardless of the platform, I'd start by creating a higher level abstraction,
> and wrap them in that.

This is /why/ I wrote my atomic operations library.  But even after I wrote
it, I /still/ couldn't port it to Windows, because the only system libraries
available are for VC++, which is so far from compliant WRT things like strings
and exceptions that there's no hope of a single implementation.

If I can retain patience long enough, someday I plan to just wrap their
stupid classes in mine and be done with it.  First the surrounding OS has to
remain up and running long enough to read the docs, but that's a separate
issue from standards compliance.  :-|


Luck++;
/dev/phil

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul D. DeRocco<pderocco@ix.netcom.com> wrote:
>Nathan Myers wrote:
>>
>> It's not silly.  As noted already in this thread, cross-compilation is
>> a mature technique, and well-supported for C++.   You can use the most
>> advanced available compiler on one system to generate code for
>> another.
>> This process is most familiar to embedded-system developers, but works
>> just as well no matter how "big" the target is.
>
>As an embedded programmer since the 8080, I can tell you it sucks. I
>always prefer native tools to cross tools, and try to do as many of my
>embedded projects on x86 platforms for that reason.
>
>You can't test and debug a Windows program without running it on a
>Windows machine. And since no one wants to reboot in order to test,
>you'd need a second machine to run the cross tools on.

I'd say this as "you'd want a second machine to run tests on".
Perfectly functional 486 boxes are advertised for $159.

>And you'd need a
>remote debugger with the appropriate support for it in the target
>system. The cross tools would have to be absolutely smokin', compared to
>VC++, to make it worth putting up with that.

Gdb (among others) debugs remotely through a serial port; all it takes
is a tiny stub running in the target machine to control the program
under test.  (I feel sorry for anybody who does embedded-system
programming and doesn't know about debugging stubs.)

(followups to comp.lang.c++.moderated.)
--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tony<Tony@ask.me> wrote:
> Nathan Myers:
>> As noted already in this thread, cross-compilation is
>> a mature technique, and well-supported for C++.   You can use the most
>> advanced available compiler on one system to generate code for another.
>> This process is most familiar to embedded-system developers, but works
>> just as well no matter how "big" the target is.
>
>But one loses, then, the experience of the target platform by not
>having the the day to day interaction with it.  Knowing those
>idosyncracies helps especially when you're developing a product for the
>platform.

I suppose that a developer who cross-compiles might not realize
how desperately important "auto-save", logging, and other failure
recovery methods are on certain target platforms?

(Followups to comp.lang.c++.moderated)

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6tbv5d$jn1$1@shell7.ba.best.com>, ncm@nospam.cantrip.org says...
> >That's silly.  I'm developing for Windows.
>
> It's not silly.  As noted already in this thread, cross-compilation is
> a mature technique, and well-supported for C++.   You can use the most
> advanced available compiler on one system to generate code for another.
> This process is most familiar to embedded-system developers, but works
> just as well no matter how "big" the target is.

But one loses, then, the experience of the target platform by not
having the the day to day interaction with it.  Knowing those
idosyncracies helps especially when you're developing a product for the
platform.

Tony



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35f99d8d.0@news.new-era.net>,
  scott@softbase.com wrote:
> devphil@my-dejanews.com wrote:
>
> > Since you have to use their API
> > anyway, just use all of it and save yourself some trouble.
>
> It is possible to create code in such a way that the user interface is
> separate from the internals. Such code could be easily ported. I
> disagree that developing software for Windows means portability is not
> required.
>
> > since there are just /so darn many/ Windows-isms that making truly po=
rtable
> > code
>
> I haven't found this to be true in general. It's easy enough to
> separate the truly Windows specific code from the rest, and wrap the
> rest in an Automation DLL or a regular DLL. Rarely do you need
> to interface with the operating system itself for anything other
> than the GUI -- the C++ standard library encapsulates memory
> management, data structures, etc.

It depends on the application, of course.  A program for computing
payroll taxes could easily have a new front end slapped into place,
if it was written with the GUI aspects in their own subroutines.

Contrast this to a "paint"-style drawing program, or a simulation
of an electronic calculator. Both of these could be written to
segregate the GUI aspects from the rest -- but here, you're likely
to find that "the rest" is only 10% of the size of the GUI parts.
Further, separating the GUI in this way may actually make the
program harder to read/maintain, and perhaps even affect code size
and performance.

Perhaps the latter kind of program is relatively rare, especially
in business software, and FAIK perhaps even in game programming
(though I doubt that). But my point is that the blanket statement
above isn't always true.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers wrote:
>
> It's not silly.  As noted already in this thread, cross-compilation is
> a mature technique, and well-supported for C++.   You can use the most
> advanced available compiler on one system to generate code for
> another.
> This process is most familiar to embedded-system developers, but works
> just as well no matter how "big" the target is.

As an embedded programmer since the 8080, I can tell you it sucks. I
always prefer native tools to cross tools, and try to do as many of my
embedded projects on x86 platforms for that reason.

You can't test and debug a Windows program without running it on a
Windows machine. And since no one wants to reboot in order to test,
you'd need a second machine to run the cross tools on. And you'd need a
remote debugger with the appropriate support for it in the target
system. The cross tools would have to be absolutely smokin', compared to
VC++, to make it worth putting up with that.

--

Ciao,
Paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

<devphil@my-dejanews.com> wrote:

> I think we'll just agree to disagree on this one.  I don't write Unix-centric
> code, necessarily; I use POSIX when I can and write good conforming wrapper
> classes when I must.  But I've given up trying to make any of it work under
> Windows.  Microsoft isn't interested in portability; they have absolutely no
> business reasons to allow you to write code that would let you leave their
> platforms.  If all I cared about was money, I would do the same.  :-)

Microsoft's POSIX implementation appears to be only useful in that it
lets vendors claim POSIX compliance in competing for government
contracts.

--
Harry Erwin, herwin@gmu.edu



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6thnek$bvv$1@nnrp1.dejanews.com>,
  devphil@my-dejanews.com wrote:
>
> In article <35f99d8d.0@news.new-era.net>,
>   scott@softbase.com wrote:
> > devphil@my-dejanews.com wrote:
> >
> > > Since you have to use their API
> > > anyway, just use all of it and save yourself some trouble.
> >
> > It is possible to create code in such a way that the user interface is
> > separate from the internals. Such code could be easily ported. I
> > disagree that developing software for Windows means portability is not
> > required.
>
> Such as wrappers for system calls, concurrent programming, network
> programming, /every/ kind of end-user interface except for std{in,out,err}
> (like any app running in a DOS box is going to sell well to Windows users).
>
> Sure it's possible.  It's ugly as sin, but it's possible.

It's not only possible, it's significantly cleaner than not doing so.
Of course, typically, you don't write the wrapper classes yourself;
you buy them in from a reliable third party.  Rogue Wave has some
wrappers for threads, or there are free versions from someone called
OMNI.  There are several commercial wrappers for sockets and windowing.
For that matter, there's a company somewhere that sells a UNIX version
of MFC, although from what I've seen, most of the alternatives offer
a higher level of abstraction, and thus cleaner code.

> > > since there are just /so darn many/ Windows-isms that making truly portable
> > > code
> >
> > I haven't found this to be true in general. It's easy enough to
> > separate the truly Windows specific code from the rest, and wrap the
> > rest in an Automation DLL or a regular DLL. Rarely do you need
> > to interface with the operating system itself for anything other
> > than the GUI -- the C++ standard library encapsulates memory
> > management, data structures, etc.
>
> Memory management, /only/ those data structures used specifically by the
> library, and high-speed algorithms.  (I'm not certain what you mean by
> encapsulating data structures; other than various kinds of containers there
> is next to nothing).  And "interfacing with the OS itself" is required all
> the time, because the Standard library doesn't address network connections,
> concurrent processes, multithreading, or mutual exclusion.  All of which
> have a fairly similar API on *nix systems, and a completely dissimilar API
> on Windows systems.

And there are third party libraries available for all.

> I've written such "wrapper" classes in the past, and recently recoded a
> library for various kinds of atomic operations (mutexes, counting semaphores).
> The Standard Library didn't help me a bit, and the POSIX.1b realtime
> extensions such as semaphores aren't supported in the recent Windows compilers
> such as VC++.

There are things for which I don't know of a third party wrapper: shared
memory, vmapping, and semaphores, for instance.  But if I had to do them,
regardless of the platform, I'd start by creating a higher level abstraction,
and wrap them in that.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ===
-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers wrote:
>
> Tony<Tony@ask.me> wrote:
> >
> >That's silly.  I'm developing for Windows.
>
> It's not silly.  As noted already in this thread, cross-compilation is
> a mature technique, and well-supported for C++.   You can use the most
> advanced available compiler on one system to generate code for another.
> This process is most familiar to embedded-system developers, but works
> just as well no matter how "big" the target is.

In theory, there's no difference between theory and practice. In
practice, there is. You cannot use the most advanced available compiler
on one system to generate code for another if that compiler doesn't
support it.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35f99d8d.0@news.new-era.net>,
  scott@softbase.com wrote:
> devphil@my-dejanews.com wrote:
>
> > Since you have to use their API
> > anyway, just use all of it and save yourself some trouble.
>
> It is possible to create code in such a way that the user interface is
> separate from the internals. Such code could be easily ported. I
> disagree that developing software for Windows means portability is not
> required.

Such as wrappers for system calls, concurrent programming, network
programming, /every/ kind of end-user interface except for std{in,out,err}
(like any app running in a DOS box is going to sell well to Windows users).

Sure it's possible.  It's ugly as sin, but it's possible.


> > since there are just /so darn many/ Windows-isms that making truly portable
> > code
>
> I haven't found this to be true in general. It's easy enough to
> separate the truly Windows specific code from the rest, and wrap the
> rest in an Automation DLL or a regular DLL. Rarely do you need
> to interface with the operating system itself for anything other
> than the GUI -- the C++ standard library encapsulates memory
> management, data structures, etc.

Memory management, /only/ those data structures used specifically by the
library, and high-speed algorithms.  (I'm not certain what you mean by
encapsulating data structures; other than various kinds of containers there
is next to nothing).  And "interfacing with the OS itself" is required all
the time, because the Standard library doesn't address network connections,
concurrent processes, multithreading, or mutual exclusion.  All of which
have a fairly similar API on *nix systems, and a completely dissimilar API
on Windows systems.

I've written such "wrapper" classes in the past, and recently recoded a
library for various kinds of atomic operations (mutexes, counting semaphores).
The Standard Library didn't help me a bit, and the POSIX.1b realtime
extensions such as semaphores aren't supported in the recent Windows compilers
such as VC++.


I think we'll just agree to disagree on this one.  I don't write Unix-centric
code, necessarily; I use POSIX when I can and write good conforming wrapper
classes when I must.  But I've given up trying to make any of it work under
Windows.  Microsoft isn't interested in portability; they have absolutely no
business reasons to allow you to write code that would let you leave their
platforms.  If all I cared about was money, I would do the same.  :-)


--
Luck++;
/dev/phil (okay, maybe a little bit of Unix-centrism  :-)

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <njKO7eSO4UCT-pn2-VSOw4IzBqKU2@pn-dialkn1-17.primary.net>,
peter.garner@toward.com says...
> > Yeah, but only practical choices seem to come from there: BC++ (dead
> > now), VC++.

> There at least two others, KAI C++ and egcs.  The latter being free!
> Both run on Linux for the PC.  There is more to life than Windows.

Oops.  Windows is my target (as is probably true for most developers).

Tony


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tony wrote:

> In article <njKO7eSO4UCT-pn2-VSOw4IzBqKU2@pn-dialkn1-17.primary.net>,
> peter.garner@toward.com says...
> > > Yeah, but only practical choices seem to come from there: BC++ (dead
> > > now), VC++.

> > There at least two others, KAI C++ and egcs.  The latter being free!
> > Both run on Linux for the PC.  There is more to life than Windows.

> Oops.  Windows is my target (as is probably true for most developers).

Believe it or not, there are still quite a few of us non-Windows
developers. It's not worthwhile arguing percentages, but there are
definitely enough of us to justify not equating C++ with Windows C++.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> wrote:
>Tony wrote:
>> peter.garner@toward.com says...
>> > > Yeah, but only practical choices seem to come from there: BC++ (dead
>> > > now), VC++.
>
>> > There at least two others, KAI C++ and egcs.  The latter being free!
>> > Both run on Linux for the PC.  There is more to life than Windows.
>
>> Oops.  Windows is my target (as is probably true for most developers).
>
>Believe it or not, there are still quite a few of us non-Windows
>developers. It's not worthwhile arguing percentages, but there are
>definitely enough of us to justify not equating C++ with Windows C++.

Even among those so cursed as to be obliged to program Windows, many
have successfully avoided using Windows as the development host.
Cross-compiling for Windows from a stable development platform such
as Linux, you are still developing both on and for the PC, but without
the crashes.  (You can think of Windows as a huge and sloppy embedded
system.)

Despite the appeal of cross-compilation, modern native compilers
for Windows can also be found.  The Cyg-win32 port of Egcs-1.1

  http://www.cygnus.com/misc/gnu-win32/

is a modern alternative to the backward native compilers available for
that platform.  Another alternative is the Intel VTune compiler, which
uses the EDG front end and drops into the VC++ IDE:

  http://developer.intel.com/design/perftool/icl/

They don't report which EDG front-end version it's based on.
Does anybody out there know?

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers wrote:

> Another alternative is the Intel VTune compiler, which
> uses the EDG front end and drops into the VC++ IDE:
>
>   http://developer.intel.com/design/perftool/icl/
>
> They don't report which EDG front-end version it's based on.
> Does anybody out there know?

According to the VTune WebSite, they use version 2.37 of the EDG
frontend in version 3.0 of their C++ compiler.

--
Christof Stadler
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This is probably getting off the chartered/beaten track for comp.std.c++,
and I don't read comp.lang.c++ (unmoderated)...


In article <35F6FA64.ABD@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
[lost some attributions in here, sorry]
> > > There at least two others, KAI C++ and egcs.  The latter being free!
> > > Both run on Linux for the PC.  There is more to life than Windows.
>
> > Oops.  Windows is my target (as is probably true for most developers).

I'll point out here the same thing that has been pointed out before:  if
you're going to tie yourself to a severely coupled vendor and platform (say,
Microsoft), there's not a whole lot of use in asking for a standard (i.e.,
platform-independant) compiler and library.  Since you have to use their API
anyway, just use all of it and save yourself some trouble.

In my limited experience, porting a program from MS-Windows to another
platform usually involves scrapping the code and starting from scratch,
since there are just /so darn many/ Windows-isms that making truly portable
code is actually more nightmarish than just doing parallel development on
two product lines.  This is hearsay from collegues; my little first-hand
experience in this regard has been the same, but I usually just walk away
from Windows code.


> Believe it or not, there are still quite a few of us non-Windows
> developers. It's not worthwhile arguing percentages, but there are
> definitely enough of us to justify not equating C++ with Windows C++.

Hear, hear!  I'm forced to use Windows NT on my desk, but the project I
currently work on is not targeted to NT.  So I use ming32's Win32 port of
egcs, and it's pretty decent.  The only thing preventing me from putting
a real development environment on my desktop (say, Linux) is corporate
policy, which is /definitely/ off-topic.  :-)

<insert grassroots take-back-the-net slogan here>


Luck++;
/dev/phil

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35F6FA64.ABD@wizard.net>, kuyper@wizard.net says...

> Tony wrote:

> > In article <njKO7eSO4UCT-pn2-VSOw4IzBqKU2@pn-dialkn1-17.primary.net>,
> > peter.garner@toward.com says...
> > > > Yeah, but only practical choices seem to come from there: BC++ (dead
> > > > now), VC++.

> > > There at least two others, KAI C++ and egcs.  The latter being free!
> > > Both run on Linux for the PC.  There is more to life than Windows.

> > Oops.  Windows is my target (as is probably true for most developers).

> Believe it or not, there are still quite a few of us non-Windows
> developers. It's not worthwhile arguing percentages, but there are
> definitely enough of us to justify not equating C++ with Windows C++.

But you guys HAVE tools (CAD UL, KAI etc).  Us Windows folks don't.  All
the Windows capable tools are trying to sell lock-in devices.

Tony


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tony wrote:
>
> In article <35F6FA64.ABD@wizard.net>, kuyper@wizard.net says...
...
> > Believe it or not, there are still quite a few of us non-Windows
> > developers. It's not worthwhile arguing percentages, but there are
> > definitely enough of us to justify not equating C++ with Windows C++.
>
> But you guys HAVE tools (CAD UL, KAI etc).  Us Windows folks don't.  All
> the Windows capable tools are trying to sell lock-in devices.

Ah! Tool envy! Well, then install Unix on your machines, so you can use
those C++ tools! PC-compatible unices have been available since the
first 386 came out (and possibly earlier). I have both NT and Solaris
x86 installed on my home machine ( despite some hardware incompatibility
issues :-{ ). If money's an issue, I believe you can get Linux for free
(ignoring the labor costs for the time it will take you to install and
maintain it).


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35F94A9F.2781@wizard.net>, kuyper@wizard.net says...

> Tony wrote:
> >
> > In article <35F6FA64.ABD@wizard.net>, kuyper@wizard.net says...
  ...
> > > Believe it or not, there are still quite a few of us non-Windows
> > > developers. It's not worthwhile arguing percentages, but there are
> > > definitely enough of us to justify not equating C++ with Windows C++.
> >
> > But you guys HAVE tools (CAD UL, KAI etc).  Us Windows folks don't.  All
> > the Windows capable tools are trying to sell lock-in devices.

> Ah! Tool envy!

LOL

> Well, then install Unix on your machines, so you can use
> those C++ tools!

That's silly.  I'm developing for Windows.  (And UNIX is too archaic for
me.  In theory it's a neat concept, in practice it really sucks.).

Tony


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tony wrote:

> In article <35F94A9F.2781@wizard.net>, kuyper@wizard.net says...

> > Tony wrote:
> > >
> > > In article <35F6FA64.ABD@wizard.net>, kuyper@wizard.net says...
    ...
> > > > Believe it or not, there are still quite a few of us non-Windows
> > > > developers. It's not worthwhile arguing percentages, but there are
> > > > definitely enough of us to justify not equating C++ with Windows C++.
> > >
> > > But you guys HAVE tools (CAD UL, KAI etc).  Us Windows folks don't.  All
> > > the Windows capable tools are trying to sell lock-in devices.

> > Ah! Tool envy!

> LOL

I'm unfamiliar with that abbreviation. Could you expand it for me?

[ moderator's note: "Laughing Out Loud." -sdc ]

> > Well, then install Unix on your machines, so you can use
> > those C++ tools!
>
> That's silly.  I'm developing for Windows.  (And UNIX is too archaic for
> me.  In theory it's a neat concept, in practice it really sucks.).

My response was meant to be humorous. I realize that many people are
forced for practical reasons to use the less convenient system ;-)
(It's all a matter of taste).


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tony<Tony@ask.me> wrote:
> kuyper@wizard.net says...
>> Tony wrote:
>> >  kuyper@wizard.net says...
>  ...
>> > > Believe it or not, there are still quite a few of us non-Windows
>> > > developers. It's not worthwhile arguing percentages, but there are
>> > > definitely enough of us to justify not equating C++ with Windows C++.
>> >
>> > But you guys HAVE tools (CAD UL, KAI etc).  Us Windows folks don't.
>> > All the Windows capable tools are trying to sell lock-in devices.
>
>> Ah! Tool envy! Well, then install Unix on your machines, so you can use
>> those C++ tools!
>
>That's silly.  I'm developing for Windows.

It's not silly.  As noted already in this thread, cross-compilation is
a mature technique, and well-supported for C++.   You can use the most
advanced available compiler on one system to generate code for another.
This process is most familiar to embedded-system developers, but works
just as well no matter how "big" the target is.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

devphil@my-dejanews.com wrote:

> Since you have to use their API
> anyway, just use all of it and save yourself some trouble.

It is possible to create code in such a way that the user interface is
separate from the internals. Such code could be easily ported. I
disagree that developing software for Windows means portability is not
required.

> since there are just /so darn many/ Windows-isms that making truly portable
> code

I haven't found this to be true in general. It's easy enough to
separate the truly Windows specific code from the rest, and wrap the
rest in an Automation DLL or a regular DLL. Rarely do you need
to interface with the operating system itself for anything other
than the GUI -- the C++ standard library encapsulates memory
management, data structures, etc.

Scott
--
Look at Softbase Systems' client/server tools, www.softbase.com
Check out the Essential 97 package for Windows 95 www.skwc.com/essent
All my other cool web pages are available from that site too!
My demo tape, artwork, poetry, The Windows 95 Book FAQ, and more.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]