RFD: comp.lang.c++.cross-platform

[Victor Bazarov]

Well, the stroke group seems to work with only one or two posters who
don't talk to each other.

I am awfully sorry, English is not my mother tongue. Could you please
put that in simpler words? For example, I don't know the term "the
stroke group". Thanks!

V

 

[Rick Pikul]

Brian Mailman wrote:

I am awfully sorry, English is not my mother tongue. Could you please
put that in simpler words? For example, I don't know the term "the
stroke group". Thanks!

He's referring to the group soc.support.stoke, he's being quite literal
when he describes it as "the stroke group" because that's pretty much what
the group is about.

 

[Victor Bazarov]

On Fri, 07 Dec 2007 13:32:10 -0500, Victor Bazarov wrote:

[bringing back the context: in response to]
[then I wrote]

He's referring to the group soc.support.stoke, he's being quite
literal when he describes it as "the stroke group" because that's
pretty much what the group is about.

Still, the meaning of Brian's statement escapes me. Here are the
possible meanings and I am not sure which one is applicable:

- the group 'soc.support.stroke' seems to work; there are one
or two posters (among many) who [refuse to] talk to each
other, but that doesn't stop the group from working [for
other people]. <this one makes sense, relevance?>

- the group 'soc.support.stroke' works (?), and it has only
one or two people (total), but they don't talk to each other.
<this one seems rather a stretch, again, relevance?>

- the proposed group can work (just like 's.s.stroke' does),
even if there will be people who don't talk to each other.

- the proponent better stay in comp.lang.c++ because it is
better for him even if there will be one or two people who
aren't going to talk to him.

- comp.lang.c++ works OK, just like 's.s.stroke', even though
there is a certain amount of disagreement, so why bother
creating the new group?

I understand that there is some overlap between the meanings, but
I am still puzzled.

V

 

[Rick Pikul]

Still, the meaning of Brian's statement escapes me. Here are the
possible meanings and I am not sure which one is applicable:

On that side of things, I think he was being sarcastic. Sort of like
saying that a ship is unsinkable, just like the Titanic.

 

[Brian Mailman]

On Fri, 07 Dec 2007 13:32:10 -0500, Victor Bazarov wrote:

[bringing back the context: in response to]
[then I wrote]

He's referring to the group soc.support.stoke, he's being quite
literal when he describes it as "the stroke group" because that's
pretty much what the group is about.

Still, the meaning of Brian's statement escapes me. Here are the
possible meanings and I am not sure which one is applicable:

(snip).

You're spending too much energy on that. Sarcasm, no matter how mild,
doesn't play well on Usenet and I was replying to Peter, who knew what I
meant. See my response to Peter J. Ross (news.groups only) regarding that.

It might also be instructive to subscribe to soc.support.stroke, and
download the messages available. See what happens when there's a
proposal when only the proponent is interested in the topic.

B/

 

[Art Deco]

In news.groups on Thu, 06 Dec 2007 09:56:12 -0800, Brian Mailman


As far as I can tell, that's not why the proponent wants the group.
The idea seems to have started here:

Message-ID: <[email protected]>

The proponent really wants to use the new group, but nobody else seems
to be particularly interested.

Everything listed in that post are really issues with c++ frameworks,
such as WxWindows, and as others have pointed out they don't belong in
comp.lang.c++. If there are people wanting a group to discuss how
frameworks are or should be constructed, I might suggest something
like:

comp.programming.c++.frameworks

 

[Victor Bazarov]

Everything listed in that post are really issues with c++ frameworks,
such as WxWindows, and as others have pointed out they don't belong in
comp.lang.c++. If there are people wanting a group to discuss how
frameworks are or should be constructed, I might suggest something
like:

comp.programming.c++.frameworks

That would be slightly better, but I would argue that such newsgroup
would still be the venue of disjointed discussions not really having
anything in common, except the language. The language discussion in
each of those, if it exists, does belong to comp.lang.c++, but other
aspects belong to other groups. Akin to trying to put discussions
specific for GM, Ferrari, Hyundai, Trabant, under something like
'alt.vehicles.cars.consumer'. Do you discuss gasoline there? Do
you discuss driving? Do you discuss racing events? Do you discuss
how to change oil? Yes, yes, yes, and yes. How is such newsgroup
going to be useful? How is the user of a Hyundai going to find any
relevant information if he has to weed through GM, Ferrari, Trabant,
and all other posts?

If you want to get specific, then you break them up:

comp.programming.frameworks.c++.qt ... Of course, there are many
online resources listed on http://trolltech.com/developer .

comp.programming.frameworks.c++.directx ... Oh wait, there is the
'microsoft.public.directx' hierarchy.

comp.programming.frameworks.c++.wxwindows ... Oh wait, it exists
already, 'comp.soft-sys.wxwindows'.

<shrug> I don't see any reason for creating it except to satisfy
the proponent's curiosity in the whole process and to prove his
efforts futile.

The point I'm trying to deliver is that since C++ has already been
around for twenty years or more, if there _were_ the need for the
newsgroup specific to C++ "frameworks", it would have been created
already. If there isn't any generic "C++ frameworks" group, it's
because there is *no need for it*.

V

 

[Tomás Ó hÉilidhe]

That would be slightly better, but I would argue that such newsgroup
would still be the venue of disjointed discussions not really having
anything in common, except the language.

Correct, cross-platform programming in C++. One thread could be about
Graphical User Interface, while another could be about Networking or
interfacing with USB devices. And then another thread could discuss
whether it's right to be storing application data within a settings file
in the application's directory.

The language discussion in
each of those, if it exists, does belong to comp.lang.c++, but other
aspects belong to other groups. Akin to trying to put discussions
specific for GM, Ferrari, Hyundai, Trabant, under something like
'alt.vehicles.cars.consumer'. Do you discuss gasoline there? Do
you discuss driving? Do you discuss racing events? Do you discuss
how to change oil? Yes, yes, yes, and yes. How is such newsgroup
going to be useful? How is the user of a Hyundai going to find any
relevant information if he has to weed through GM, Ferrari, Trabant,
and all other posts?

That analogy is poor, very poor, and I'm not going to resort to
analogies to get my point across that c.l.c++.cross-platform would be a
nice group.

If you want to get specific, then you break them up:

comp.programming.frameworks.c++.qt ... Of course, there are many
online resources listed on http://trolltech.com/developer .

comp.programming.frameworks.c++.directx ... Oh wait, there is the
'microsoft.public.directx' hierarchy.

comp.programming.frameworks.c++.wxwindows ... Oh wait, it exists
already, 'comp.soft-sys.wxwindows'.

And while we're at it, we should make other more specific groups:

alt.cars.repair.clutch.nissan.prelude.1983.saloon.petrol.all-
electrics.with-cupholders.green.retractable-sunroof.mileage-below-
55000.imported-from.Japan.during-the-decade-of.1970.name-of-first-
registered-owner.John

<shrug> I don't see any reason for creating it except to satisfy
the proponent's curiosity in the whole process and to prove his
efforts futile.

This caustic attitude is typical of Mr Bazarov, as you may imparitally
observe if you check over his recent posts on comp.lang.c++.

The point I'm trying to deliver is that since C++ has already been
around for twenty years or more, if there _were_ the need for the
newsgroup specific to C++ "frameworks", it would have been created
already. If there isn't any generic "C++ frameworks" group, it's
because there is *no need for it*.

You're definitely right Victor, there's no *need* for c.l.c++.cross-
platform, just like there's no need for electricity, or Usenet even.

I don't contest the fact that the world will still revolve if we don't
have c.l.c++.cross-platform, but I strongly do suggest that it would be
a great newsgroup to have.

 

[Art Deco]

That would be slightly better, but I would argue that such newsgroup
would still be the venue of disjointed discussions not really having
anything in common, except the language. The language discussion in
each of those, if it exists, does belong to comp.lang.c++, but other
aspects belong to other groups. Akin to trying to put discussions
specific for GM, Ferrari, Hyundai, Trabant, under something like
'alt.vehicles.cars.consumer'. Do you discuss gasoline there? Do
you discuss driving? Do you discuss racing events? Do you discuss
how to change oil? Yes, yes, yes, and yes. How is such newsgroup
going to be useful? How is the user of a Hyundai going to find any
relevant information if he has to weed through GM, Ferrari, Trabant,
and all other posts?

If you want to get specific, then you break them up:

comp.programming.frameworks.c++.qt ... Of course, there are many
online resources listed on http://trolltech.com/developer .

comp.programming.frameworks.c++.directx ... Oh wait, there is the
'microsoft.public.directx' hierarchy.

comp.programming.frameworks.c++.wxwindows ... Oh wait, it exists
already, 'comp.soft-sys.wxwindows'.

<shrug> I don't see any reason for creating it except to satisfy
the proponent's curiosity in the whole process and to prove his
efforts futile.

The point I'm trying to deliver is that since C++ has already been
around for twenty years or more, if there _were_ the need for the
newsgroup specific to C++ "frameworks", it would have been created
already. If there isn't any generic "C++ frameworks" group, it's
because there is *no need for it*.

Oh I agree completely. Frameworks are constructed for many different
purposes and goals, and having a newsgroup dedicated to frameworks and
how they are constructed would be pretty useless. These are large
libraries and at a certain point discussing the philosophies behind
them is pointless because those philosophies are etched in stone are
not going to change without starting over with a brand-new framework.

My impression is that the proposer wants to be able to ask what he
thinks are simple questions like: "how do I put up a window in Win32,
Linux, OSX in c++ with the same code?", i.e. what he calls "portable".
The answer is not contained in Stroustrup (and never will be), so
c.l.c++ isn't the place. The answer is that he has to use a framework,
so he needs to do his own research to select one that meets his design
goals. Software engineering, in other words. He shouldn't expect to
have other people on call to do this work for him at the flip of a
light switch in a specialized newsgroup.

 

[Art Deco]

Correct, cross-platform programming in C++. One thread could be about
Graphical User Interface, while another could be about Networking or
interfacing with USB devices. And then another thread could discuss
whether it's right to be storing application data within a settings file
in the application's directory.

These are all issues that frameworks are supposed to handle.

That analogy is poor, very poor, and I'm not going to resort to
analogies to get my point across that c.l.c++.cross-platform would be a
nice group.

On the contrary, it seems quite apt to me, and goes right to the
problem with your proposal.

And while we're at it, we should make other more specific groups:

alt.cars.repair.clutch.nissan.prelude.1983.saloon.petrol.all-
electrics.with-cupholders.green.retractable-sunroof.mileage-below-
55000.imported-from.Japan.during-the-decade-of.1970.name-of-first-
registered-owner.John

Those comp.* groups are all in existence. The WxWindows group is
pretty active, too. I haven't looked at the others, but I would guess
the directx group is as well.

Have you tried to use any of them?

This caustic attitude is typical of Mr Bazarov, as you may imparitally
observe if you check over his recent posts on comp.lang.c++.

I see nothing "caustic" in his sentence at all.

You're definitely right Victor, there's no *need* for c.l.c++.cross-
platform, just like there's no need for electricity, or Usenet even.

I think you missed his point.

I don't contest the fact that the world will still revolve if we don't
have c.l.c++.cross-platform, but I strongly do suggest that it would be
a great newsgroup to have.

To discuss all c++ frameworks? Or "generic" c++ frameworks? Or none
at all? You haven't been very specific.

 

[Jonathan Mcdougall]

Correct, cross-platform programming in C++. One thread could be about
Graphical User Interface, while another could be about Networking or
interfacing with USB devices. And then another thread could discuss
whether it's right to be storing application data within a settings
file in the application's directory.

I am not sure even you are able to pinpoint the exact description of
this newsgroup. You seem to be talking about "correct, cross-platform
programming in C++", but then you mention three completly different
and unrelated subjects: gui, networking and usb. In the OP, you also
mention scanners and wireless internet.

The scope of the newsgroup you propose seems to include all existent
libraries available that are considered "cross-platform" and use C++
bindings. Then,

1) What is "cross-platform"? How many platforms does a library need to
cross to be "cross-platform"?

2) What are the libraries that would be on-topic? What subjects will
be
accepted? Is it your intention of imposing any limit concerning the
purpose of the libraries that are discussed? If not, do you realize
the extreme range of subjects you might be accepting? If you do,
what kind of limits?

3) Do you plan on restricting subjects based on the popularity of
libraries? Can any library, as obscure as it might be, be discussed
on this newsgroup?

Your answer might be "Yes, the less obscure, the more answers".
Fine, but you might find that traffic may become low when people
realize that not all libraries can actually be discussed there if
answers are hoped for.

The natural conclusion would be that only well-known libraries
would
be discussed there, such as gtkmm, boost, curlpp, libxml++, etc.
The
problem is that most of these well-known libraries have been around
for years and already have other means of communication, either by
mailing lists, web-based forums or other newsgroups.

4) For a newsgroup to be interesting, active and to provide good
support, there needs to be regular users that have good knowledge
of
the subject at hands. To have these experts around, your newsgroup
needs to be focused and specialized.

For example (pardon the weasel words),

a) Many of the Microsoft newsgroups are regularily visited by
"MVPs". These newsgroups are very specialized (perhaps a
little
bit too much, I agree) and usually provide very good support.

b) many mailing lists (boost and gtkmm come to mind) include not
only regular users, but also the makers or maintainers of
these
libraries;

c) newsgroups related to languages often have compiler writers
or people involved in the standardization process.

If you propose a newsgroup that's so general any library that has
C++ bindings and is supported on at least two distinct platforms
can
be discussed, you are doomed to failure.

That analogy is poor, very poor, and I'm not going to resort to
analogies to get my point across that c.l.c++.cross-platform would be a
nice group.

If you replace car-related words with programming-related words, you
actually come up with something quite good:

"Akin to trying to put discussions specific for Windows, Linux, Mac,
QNX, under something like 'comp.lang.c++.cross-platform'. Do you
discuss the language there? Do you discuss compilers? Do you discuss
design patterns? Do you discuss the internal of the cross-platform
libraries? Yes, yes, yes, and yes. How is such newsgroup going to be
useful? How is the Windows user going to find any relevant
information
if he has to weed through Linux, Mac, QNX, and all other posts?"

And while we're at it, we should make other more specific groups:

alt.cars.repair.clutch.nissan.prelude.1983.saloon.petrol.all-
electrics.with-cupholders.green.retractable-sunroof.mileage-below-
55000.imported-from.Japan.during-the-decade-of.1970.name-of-first-
registered-owner.John

Exactly! The more specific, the easier it is for people to
participate.
Take this newsgroup, c.l.c++, as an example: its name is not specific
enough (to newcomers, at least). Many, many posts come from people who
do not distinguish the language from the libraries from the compiler
from the platform. Regulars are trying very hard to maintain the very
high quality of the postings. By doing this, they also make sure that
other experts (such as those who write compilers or actively
participate to the standardization process) stay around to help.

By creating a "general" newsgroup, you won't get "everybody", you'll
get "no one".

This caustic attitude is typical of Mr Bazarov, as you may
imparitally observe if you check over his recent posts on
comp.lang.c++.

As many have said before, I have no power on whether you decide to
continue or not. At the end, you might even want to create a public
Google Group or host a web-based forum yourself.

However, it seems you wanted some feedback on your proposal. You have
some now, albeit not what you might have expected. Take it into
consideration and try to keep the discussion polite and constructive.

 

[Brian Mailman]

The traditional procedure for creating newsgroups is to have a proponent
propose a group that makes sense to them and have a discussion about
whether the group is correctly named and has sufficient support to
develop a viable core group of participants. That's exactly what is
happening in this case.

No, it isn't.

Most of what pjr said: Message-ID: <[email protected]>

and I'll add the precedent has already been set (many times, not just
with the "obvious" groups), unless there's different rules for different
groups.* The precedent is that neither support nor traffic
justification is important. This is what John Stanley talked about in
the past--that if you have a rule for one, you have a rule for all and
constantly special-casing will eventually cause a problem when someone
says "well, why can't *I*...."

*I'm being polite here, and not naming the group with the special
privileges, the one that has crapped in its own food bowl.

B/

 

[Art Deco]

(e-mail address removed) (Mark Kramer) wrote in news.groups.proposals:


Again you're talking about cross-compiling. Here's an example of cross-
compiling:

I have code for a Linux program. I compile the code to run for
Linux, and the only thing special is that I will compile it
using a compiler that's running under Windows. The executable
file produced will be no different from if I had compiled it
on a comiler running under Linux.

Your words here: "The executable file produced will be no different..."

This is not cross-compiling or porting -- different operating systems
require vastly different executable files and file format.

Or do you mean that the behavior of the various OS-specific executables
are identical?

Your language is not clear.

Cross-platform programming is about using cross-plaform libraries so that
an application's code can be compiled for different systems.

What do you mean by "using cross-platform libraries"? Linking against
them to create OS-specific executable files? Or producing some kind of
single, universal executable file that runs on multiple operating
systems? Again, you need to make this clear.

1) The first case seems like what you are called "cross-compiling"
above.

2) The second case seems like it would produce what is called
"Least-Common Denominator" executables -- i.e. programs that do not
behave like native applications. I hate to call up the demons of the
Language Wars, but compiled Java applications tend to be this way.
They are oddballs to users on whichever computer they are run, and
experience has shown that people tend to hate them.

The two terms are unrelated, please stop confusing them.

You may need to extricate compiling and linking in your proposal, I
think you have them all tossed together.

Are you talking about special compilers that produce a "universal"
p-code which is then linked with the "cross-platform libraries"?

I've tried to read all of your posts about this proposal and I still do
not understand exactly what it is you want to discuss.

I assume you're talking about simple commandline programs, yes? Because
if you wanted a graphical user interface, you'd need to use a cross-
platform library for GUI.

If you simply take your Windows code and try to compile it for Linux
you'll get an error firstly saying that windows.h doesn't exist. And even
if you get by that, you'll get linker errors saying MessageBoxA can't be
found anywhere. And even if you get by that, the program will run and
fail because Linux hasn't got MessageBoxA.

I'm talking about bigger and better things than commandline programs --
I'm talking about applications with a GUI, that can print pages, that can
do networking. The C++ Standard is no help to you in this, and so you'll
have to go a layer above it to cross-platform programming.

Are you trying to advocate for a single standard c++ way of
implementing windows and interface controls?

All of the systems I list above can retrieve a page from the web, yet the
C++ Standard has no means of doing this. That's why we use a cross-
platform library to retrieve a page from the web. Here's an example of a
cross-platform application consisting of a single source file:

#include <some_library\http.hpp>

int main()
{
HTTPget("google.com");
}

Are you really having that much difficulty getting your head around this?

I hope you realize that this little program is not at all portable or
"cross-platform": file references in preprocessor directives (like
your #include) are notoriously hard to port, and your hard-wired
character string is also non-portable (encodings, storage, etc.).

If the program is written using cross-platform libraries, then it *can*
be compiled for use on Linux, Solaris, XBox 360, etc.

If I understand what you mean by this statement, in essence you want
something like WxWindows added to c++. Am I correct?

Can you say why you think the existing cross-platform frameworks are
unsuitable?

Do you want some kind of cross-platform framework added to the c++
standard?

How will this new framework be different from the existing ones?

How will the framework cover operating system calls that aren't in the
standard?

Exactly.

After reading many of your posts, it seems to me like you are
advocating that some standard way of doing user interface, networking,
hardware, etc. be added to the c++ standard, and that your attempts to
discuss these were rebuffed in comp.lang.c++. While a new newsgroup
will give you a location to discuss these issues, I am skeptical that
these changes will ever be implemented into the c++ standard.

But I see no harm in a group dedicated to discussing such changes,
however futile.

No. The "layer" of which you speak has a flavour for Linux, for Solaris,
etc., and therefore it can be compiled for and will run on Linux,
Solaris, etc.

So you are talking about a pseudo-code compiler then.