Board index » cppbuilder » Re: It's Wednesday, and...

Re: It's Wednesday, and...


2003-11-09 05:21:03 AM
cppbuilder72
David B. Held < XXXX@XXXXX.COM >wrote:
Quote
[...]
>>When will wxWindows support .Net?
>
>???
>You're asking _me_???

Sure.
I don't know much about wxWindows as it is
today, let alone their plans. And I certainly
cannot look into the future.
You might want to try the wxWindows mailing
list, though.
Quote
Does this sound familiar?

>For the users, the VCL is a set of
>interfaces. What these are implemented
>with, users shouldn't care. And these
>interfaces aren't affected by MS at all.
Yep.
Quote
Isn't wx a "set of interfaces"?
Yep.
Quote
And should the user "not care"
how they are implemented?
Of course, they shouldn't. However,
what I know about our usage of it
here (I don't do much GUI stuff.)
Quote
And are the interfaces "not
affected by MS at all"?
Since they are implemented on a bunch
of other platforms, they should be
platform-independend (up to a certain
point, that is).
Quote
They're both GUI frameworks, after
all.
Both? wx and wx?
I cant follow you here.
Quote
And the fact that Borland is replacing one with the other
pretty much says that Borland thinks they do essentially the
same thing.
Replacing what with what?
Quote
So why not set the same standard for everyone?
Which standard?
Quote
Dave
Schobi
"And why should I know better by now/When I'm old enough not to?"
Beth Orton
 
 

Re:Re: It's Wednesday, and...

Mike < XXXX@XXXXX.COM >wrote:
Quote
[...]
boost.sourceforge.net/regression-logs/cs-win32.html
You shouldn't take boost's regressions to
compare compilers. Whether a specific test
succeeds on a specific compiler is more a
question of how many people where willing
to make the feature working on that compiler.
For example, many tests run on VC6, but not
on some other compilers. Since VC6 is most
probably the worst compiler in the list,
the reason for that is just that so much
manpower went into it.
OTOH, the reason BCC fails these tests is
most likely that noone puts enough effort
into checking why that is.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers org
"And why should I know better by now/When I'm old enough not to?"
Beth Orton
 

Re:Re: It's Wednesday, and...

Edward Diener < XXXX@XXXXX.COM >wrote:
Quote
[...]
2) MS is interested in promoting their own languages, most notably
C#. If C# dominated the world and C++ was forgotten, I think they
would be ecstatic.
Except that then they'd have forgotten about
the language most of their programs are
written in. <g>
Quote
[...]
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers org
"And why should I know better by now/When I'm old enough not to?"
Beth Orton
 

{smallsort}

Re:Re: It's Wednesday, and...

Hendrik Schober wrote:
Quote
You shouldn't take boost's regressions to
compare compilers. Whether a specific test
succeeds on a specific compiler is more a
question of how many people where willing
to make the feature working on that compiler.
For example, many tests run on VC6, but not
on some other compilers. Since VC6 is most
probably the worst compiler in the list,
the reason for that is just that so much
manpower went into it.
OTOH, the reason BCC fails these tests is
most likely that noone puts enough effort
into checking why that is.
The failure rate for bcc has been increasing for the last couple
releases. .28 (regex) could be made to work by updating the ifdefs for
5.6.4 and that was that. Borland isn't updating the compiler to be more
ISO compliant and IMO that's what's showing up there. At some point the
boost folks may just have given up on it, because it makes for too much
work to work around bugs in the compiler.
 

Re:Re: It's Wednesday, and...

"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message
Quote
>>[...]
>>For the users, the VCL is a set of
>>interfaces. What these are implemented
>>with, users shouldn't care. And these
>>interfaces aren't affected by MS at all.
>[...]
>And are the interfaces "not
>affected by MS at all"?

Since they are implemented on a bunch
of other platforms, they should be
platform-independend (up to a certain
point, that is).
Which means that wx won't support most of the .Net
functionality, because it only exists in .Net?
Quote
>They're both GUI frameworks, after
>all.

Both? wx and wx?
I cant follow you here.
That's because you trimmed too many quotes and lost the
context. Obviously, I'm comparing wx to the VCL.
Quote
>And the fact that Borland is replacing one with the other
>pretty much says that Borland thinks they do essentially the
>same thing.

Replacing what with what?
Replacing the VCL with wx.
Quote
>So why not set the same standard for everyone?

Which standard?
More context:
[Remy said:]
Quote
>That is not all Borland's fault, though. Microsoft is changing
>the C++ market for the Windows platform. [...]

For the users, the VCL is a set of
interfaces. What these are implemented
with, users shouldn't care. And these
interfaces aren't affected by MS at all.
So if VCL has to keep up with MS, then so should wx. But
wx also has to keep up with Apple, the X Consortium, and
everyone else too.
Dave
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 10/27/2003
 

Re:Re: It's Wednesday, and...

Peter Agricola wrote:
Quote
This is not a solution. The wxWindows library is still Win32 and will run in
the compatability layer on .NET, and will suffer from the same problems as
our native Win32 apps. And why use wxWindows in a .NET program when there is
already Winforms?

Well, I haven't been overly keen on using TObject derived classes in C++
with the VCL but have put up with it. I'm as unkeen to start using
managed C++ so wxWindows has some attractions over this solution.
Also, people who are targetting other OSes than just windows, can't use
.net so wxWindows may well be a viable solution for them
Thanks
Russell
 

Re:Re: It's Wednesday, and...

David B. Held < XXXX@XXXXX.COM >wrote:
Quote
[...]
>
>Since they are implemented on a bunch
>of other platforms, they should be
>platform-independend (up to a certain
>point, that is).

Which means that wx won't support most of the .Net
functionality, because it only exists in .Net?
Why? AFAIK, wx supports some things on
some platforms that aren't supported on
others.
Quote
[...]
>>And the fact that Borland is replacing one with the other
>>pretty much says that Borland thinks they do essentially the
>>same thing.
And essentially they do: They're GUI
frameworks.
Quote
[...]
[Remy said:]
>>That is not all Borland's fault, though. Microsoft is changing
>>the C++ market for the Windows platform. [...]
>
>For the users, the VCL is a set of
>interfaces. What these are implemented
>with, users shouldn't care. And these
>interfaces aren't affected by MS at all.

So if VCL has to keep up with MS, then so should wx. But
wx also has to keep up with Apple, the X Consortium, and
everyone else too.
Just to make this clear: I think, the way
Borland let their VCL costumers down is a
stupid thing to do (unless they want to
get rid of them, of course). For most of
the customer base they had, the VCL is
what's needed. I so sympathize with their
intention to get away from the MS-only Win
platform and gain customers that work on
other platforms. But I don't think doing
this by dissing their existing users is
overly clever.
Now, the question at hand: I don't know
anything about the .NET GUI. I would,
probably naively, expect it to be "just
another GUI API". And I would expect a
GUI lib, that is already ported to a
couple of different GUI APIs, to be
portable to just another one.
Also, I don't see why beeing portable
in general excludes platform-specific
extensions. There could be a portable
subset plus platform-specific stuff around
it. As top whether this is wanted (by the
wx community) -- that's another question.
Quote
Dave
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers org
"And why should I know better by now/When I'm old enough not to?"
Beth Orton
 

Re:Re: It's Wednesday, and...

Mike < XXXX@XXXXX.COM >wrote:
Quote
[...] Borland isn't updating the compiler to be more
ISO compliant and IMO that's what's showing up there.
IMO that'S _one_ thing showing up there.
Quote
At some point the
boost folks may just have given up on it, because it makes for too much
work to work around bugs in the compiler.
And that's another thing showing up. They
never gave up on VC6, even though it was a
lot worse than Borland (and worse than just
about everything else).
Why that is so, is another thing to speculate
about. However, I stand to that: You cannot
take boost regression tests as conformance
measures.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers org
"And why should I know better by now/When I'm old enough not to?"
Beth Orton
 

Re:Re: It's Wednesday, and...

Hendrik Schober wrote:
Quote

Why? AFAIK, wx supports some things on
some platforms that aren't supported on
others.

This is true. It supports wxTaskBarIcon (or something) that is only
available on wxMSW for example
Cheers
Russell
 

Re:Re: It's Wednesday, and...

"Russell Hind" wrote:
Quote
Peter Agricola wrote:
>This is not a solution. The wxWindows library is still Win32 and will
run in
>the compatability layer on .NET, and will suffer from the same problems
as
>our native Win32 apps. And why use wxWindows in a .NET program when
there is
>already Winforms?
>

Well, I haven't been overly keen on using TObject derived classes in C++
with the VCL but have put up with it. I'm as unkeen to start using
managed C++ so wxWindows has some attractions over this solution.
Yes, it certainly has.
Quote
Also, people who are targetting other OSes than just windows, can't use
.net so wxWindows may well be a viable solution for them
For people who target other OSes wxWindows is a solution, but that takes you
nowhere on .NET as long as your C++ can't be compiled to .NET. Your
wxWindows app will run in the compatibility layer and you don't benefit from
the wxWindows .NET binding (you don't need it). People who write for .NET
can use the wx.NET binding but that doesn't help them because their
(managed) .NET code can not be compiled on another OS.
At this moment you have to choose for .NET or for The Others. Guess what
most developers choose.
If one day it is possible to compile standard C++ to MSIL then wxWindows can
be ported to .NET and implemented using WinForms. wxWindows MSW will become
obsolete then.
Peter
 

Re:Re: It's Wednesday, and...

Hendrik Schober wrote:
Quote
And that's another thing showing up. They
never gave up on VC6, even though it was a
lot worse than Borland (and worse than just
about everything else).
True, marketshare is marketshare. Boost could have decided not to
support VC6 (back then) and they would have pretty much gone unnoticed
in the Winsnot segment.
Quote
Why that is so, is another thing to speculate
about. However, I stand to that: You cannot
take boost regression tests as conformance
measures.
No, I don't use it as a conformance test, just one for the library
(boost) with the compiler I own (5.6.4). Borland's lack of support makes
it impossible for me to use new revs of the boost library. By the same
token using BCB6 for development of Win32 apps becomes harder and harder.