Re: OT Java, C#, C++



"Richard" <riplin@xxxxxxxxxxxx> wrote in message
news:83d2deaa-8d27-48d2-987e-ff53596b79f2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jan 15, 9:58 am, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"Richard" <rip...@xxxxxxxxxxxx> wrote in message

news:c870ef8d-4cd4-4f97-a757-fa706a81aaa4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



On Jan 12, 1:01 pm, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"William M. Klein" <wmkl...@xxxxxxxxxxxxxxxxx> wrote in
messagenews:I%Phj.255354$He.247582@xxxxxxxxxxxxxxxxxxxxxxxxx

Although still off-topic, I was just wondering, ...

In the threads on Java, it seems to me that some of those embracing
OO
are
moving from Java to C# (not C++).

I know that the CLI run-time (I think that is what is still called
outside
Microsoft) is available on other platforms, but I was wondering how
"portable" those using C# is in practice.

Are those using C# mostly doing Windows applications?

Speaking for myself, "Yes". (Its where the market is...)

If you wanted to do OO for a "portable to where CLI isn't"
environment,
would you use Java or C++ - or something else (and why)?

Possibly Java, but more likely C#. It has arguably better facilities
than
Java (although this is subjective; both languages are excellent), but
I
specifically like certain features of C# (better IDE and Debugging,
FOREACH
for iterating over collections... SO easy, and very easy-to-write
event
handlers. Mainly, I like the succinct, easy-to-read code and the fact
that
everything is typed. Stuff (even complex machine oriented stuff) just
works...

If the User had Java already, and/or expressed a preference for NO C#,
then
I'd use Java.

Just curious.

Based on a sample of one :-) written totally as an experiment, but a
real
application...:

1. C# developed on a Windows platform and NOT using unmanaged code
(specifically, InterOp Services) or platform-specific Classes, runs
perfectly on any Windows platform running the appropriate version of
DotNET.

2. The SAME C# Assembly runs correctly on a machine running
Mono/Linux,
WITHOUT recompile or reconfiguring.

While it is possible to write C# programs that will run identically on
both, it is also possible to write perfectly good programs which are
locked to 'Windows only'.

Partly this is because Mono will always be behind the latest Windows
stuff, but also because Mono doesn't/can't use the Windows API as can
be done.

If, however, one used the GTK+ windowing subsystem then it will run on
both.

C# is accelerating in popularity for a number of reasons, and
cross-platform
capability is just one aspect of it.

When MS implemented their Java as J++ they added 'Windows Only' stuff
into it and failed to indicate that this was not cross-platform in the
expectation that they could have it both ways: alleged 'cross-
platform' _and_ Windows Only lockin.

Mono is supplying that for MS. In theory cross-platform, in practice
Windows only (unless special care is taken).

I only wish I had got into it sooner; I could have saved myself a lot
of
aggravation with OO COBOL.

Pete.
--
"I used to write COBOL...now I can do anything."

I really don't know enough about Mono to argue this, Richard, and I
accept
what you say.

It seems a pity.

"""Support for Winforms 1.1 has been completed and was released in
Mono 1.2. It is now in a maintenance/bug fixing state. Support for
Winforms 2.0 is currently under development."""

"""some applications (and especially third party controls)
occasionally bypass the API and P/Invoke straight to the Win32 API.
These calls will likely have to changed to work on Mono."""


I decided some time ago NOT to use P/Invoke unless there was an absolutely
compelling reason (so far I haven't found one...)



Not familiar with GTK+ either. How could I access this from a Windows
environment in C# (thought I might give it a try...)?


Thanks for the link. I'll check it out and have a dabble as soon as I clear
the current workload.

Pete.
--
"I used to write COBOL...now I can do anything."



.

Relevant Pages

  • Re: These are identical, right? char const* and const char*
    ... > Java was originally an embedded systems programming language, ... You gain working directly with the platform API in your code and thus fully ... Windows and these are instantly available to Windows C++ programmers. ...
    (comp.lang.cpp)
  • Re: OT Java, C#, C++
    ... would you use Java or C++ - or something else? ... locked to 'Windows only'. ... platform' _and_ Windows Only lockin. ... I notice that it also supports the Glade interface designer. ...
    (comp.lang.cobol)
  • Re: OT Java, C#, C++
    ... would you use Java or C++ - or something else? ... locked to 'Windows only'. ... platform' _and_ Windows Only lockin. ... occasionally bypass the API and P/Invoke straight to the Win32 API. ...
    (comp.lang.cobol)
  • Re: Strange problem when using a class module in VBScript
    ... > problems and is faster than Windows and VB/VBA. ... > which is essentially their version of Java. ... > The Wintel platform has been a series of compromises to preserve backwards ... Unix boxes are often faster, but it has nothing to do with Java. ...
    (microsoft.public.vb.general.discussion)
  • Re: What is the counterpart of javaxmail api in linux?
    ... > javaxmail api from java on Windows to java on Linux. ...
    (comp.lang.java.developer)