Will interest in C++ be revived after the Java fallout?

[James Kanze]

Interesting. Do you believe that that's true of WebLogic, TIBCO
Enterprise Message Service, TIBCO BusinessWorks, IBM Process Server,
Sonic, Mule, ServiceMix, Tomcat, JBOSS? They sure come with a lot of
jar files!

And a number of binaries and .so's as well, no? Those products
provide a complete framework. And a lot of the ancillary
functionality is written in Java. Things like managing the
configuration, for example. And of course helper classes for
the user supplied beans. I'm not familiar with all of the
above, but Tomcat characterizes itself as a "servlet", not
a server---and in fact, it is just a small plugin for a much
larger server, Apache, which is written in C (IIRC; it's either
C or C++). This is a common model for general purpose Web
servers, with most of the actual work done in C or C++, but
using Java for various plugins and other ancillary tasks.

 

[Dombo]

Op 26-Jan-11 12:30, James Kanze schreef:

That's not been my experience. I've moved several large (500
KLoc or more) applications from Windows or Solaris to Linux,
with no real problems. Given the way the language has evolved,
it's often been more work to move to a more recent version of
the compiler than to move from Windows to Unix.

In my experience that depends highly on the type of application and
whether or not it was designed with portability in mind. If a C++
application interacts with the outside world in in other ways than just
stdin/-out and basic file I/O, it becomes non-portable real quickly.
Many applications do require services that are not provided by the
standard library, and therefore have to either make direct OS calls use
a library.

At the beginning of this century I was involved with project which had
to support three different target platforms. Like many (probably most)
C++ applications we did require services that the standard library did
not provide. To isolate ourselves from platform specific issues we tried
to use libraries that were available for multiple platforms and
libraries that provided a platform independent interface for things like
networking.

The first problem we had was that for some services there were simply no
libraries that supported the combination of OS + compiler we needed, or
in other cases the few that did support the required platforms were
severely lacking in other aspects. (don't get me started on each C++
library having its own string and container classes). The second problem
we ran into was that we had to use different C++ compilers for the
various platforms. No C++ compiler we had to use at the time was very
standard compliant; each compiler supported a different subset of C++
standard and worse, certain parts that were supported on all compilers
behaved differently. Unfortunately the only way to figure what the safe
subset of C++ was, was finding it out the hard way.

These days things have improved with (much) better standard compliance
of the C++ compilers and more mature multi-platform libraries. However
these days it is not uncommon for projects to use code that was written
over a decade ago. Porting C++ code that is not written with portability
in mind (which might have been impractical at the time) is a lot more
involved that just recompiling it for a different platform. And even if
it was written with portability in mind you might be in for a couple of
nasty surprises.

 

[James Kanze]

"James Kanze" <[email protected]> wrote in message

[...]

Even a very basic windows winmain function and messsage loop cannot be
ported, your lucky if it runs on your version of windows nvm Linux.

What's a windows winmain function? I've never seen one.

As soon as you start adding code to make api calls you further add to
complexities.
I don't know about Solaris and linux but I know the whole structure of a
windows program is built arount the OS and I can't see how a C++ windows
program can be ported.

I've just ported one.

If you start getting into windows services and non GUI programs then its
going to be even more OS specific.

I don't see how porting a large windows program can be considered, over
rewriting a new program. I think you must have a had a very special one-off
case with your program with very little interaction with the OS.

It may surprise you, but a lot of programs don't have much
interaction with the OS, other than reading and writing files.

 

[James Kanze]

Contrary to James' claim, the growth of Java in the last decade has
largely been on the server domain, not the GUI domain.

Yes, but it still isn't widely used for the real working part of
the server. Servers are very complex applications, rarely
written in just one language. The work horse part of the server
is generally written in C or C++, but there's a lot of things
on the side for which Java is appropriate, and there's a lot of
internal glue where Java can be used as well.

 

[Rui Maciel]

Contrary to James' claim, the growth of Java in the last decade has
largely been on the server domain, not the GUI domain. The biggest
growth in Java has been in messaging, middle ware and workflow tooling
used by large enterprises, as exemplified in products like TIBCO
Business Works, IBM Process Server, and Sonic ESB, all of which have
been developed largely in Java. The reasons for this are not
difficult to understand.

If I'm not mistaken, IBM Process Server runs on IBM's WebSphere
Application Server, which is frequently pointed out as IBM's flagship
product. That means that the reason why it was developed in Java may not
have been necessarily due to any technical reason but mainly due to IBM's
intention to build upon the company's previous work. Relying on a
completely separate code base written from scratch in an entirely
different programming language is not a smart move, no matter how many
features and improvements the new programming language brings to the
table.

At the same time,
standard C++ offered abysmal support for XML processing, Unicode, and
dates, at a time when standardized business workflow scripting was
being specified in XML.

I don't see how the absense of a XML parser in the definition of the C++
programming language can be seen as a hindrance to anyone, as no one was
ever stopped from using XML in their programs due to this non-issue. In
fact, as a parser is a very specialized component, which means that there
isn't a "one size fits all" solution, users are better off choosing the
solution that better fits their needs instead of being forced to use one
that fails to adequately address any use that is thrown at them.

The same is also applied to dates. If you want to output a date then you
just cout it. If you want to output it in a standard representation then
you just glance over ISO 8601 and tweak your cout line accordingly. If
you really need to parse dates then more often than not they are a part of
a domain-specific language that's you've adopted, which means that you
must already be using a parser that handles that. If not then, again,
open ISO 8601 and write a small parser that handles that.

Regarding the Unicode bit, that is indeed a thorn on C++'s side, and in
C's too. Nonetheless, the new C and C++ standards already incorporates
C's unicode TR.


<snip/>


Rui Maciel

 

[Paul]

[...]

C++ is not a portable programming language and any, non
trivial, program will only work on the system is was
designed to work on.
That's not been my experience. I've moved several large (500
KLoc or more) applications from Windows or Solaris to Linux,
with no real problems. Given the way the language has evolved,
it's often been more work to move to a more recent version of
the compiler than to move from Windows to Unix.

Even a very basic windows winmain function and messsage loop cannot be
ported, your lucky if it runs on your version of windows nvm Linux.

What's a windows winmain function? I've never seen one.

Standard entry point function for a windows process.

I've just ported one.



It may surprise you, but a lot of programs don't have much
interaction with the OS, other than reading and writing files.

--

I can't think of any programs that requires no user input and are neither
sub processes or a service that has some OS specific entry point function.
Only thing I can think of is some kind of console application that takes
command line arguments, but I don't think I've seen anything like that since
win95.

Maybe it is an exageration so say "alot" of programs do not interact with
the OS?

 

[Joshua Maurice]

Regarding the Unicode bit, that is indeed a thorn on C++'s side, and in
C's too.  Nonetheless, the new C and C++ standards already incorporates
C's unicode TR.

Links please? I'm curious how bad the support is.

In short, for any library purporting to supply Unicode "support", I /
want/ at least:
1- Iterators over Unicode strings - one that iterates by encoding
units, one that iterates by unicode code point, and one that takes a
locale and iterates by grapheme clusters.
2- Actual good collation and normalization support.
3- Functions to translate encodings from any "commonly" used encoding
to any of the UTF encodings, and vice versa.
4- Not implemented by a retarded monkey. An example of an
implementation by a retarded monkey is one using a virtual function
call per encoding unit for translation between encoding.

 

[Daniel]

And a number of binaries and .so's as well, no?

Java runtimes come with binaries. The list above includes some server
implementations that are entirely written in Java, and others that are
mixed.

 I'm not familiar with all of the above,

Judging from your next comment, you're not familiar with any of them

but Tomcat characterizes itself as a "servlet"

That doesn't make any sense at all. I've used Tomcat as a web server,
and used it as a container to host servlets that I've written. Tomcat
is a server that hosts servlets, among other things.

 This is a common model for general purpose Web
servers, with most of the actual work done in C or C++, but
using Java for various plugins and other ancillary tasks.

Sorry, but I don't think you know anything at all about the internals
of any of the products I've listed above, which I'm intimately
familiar with. You have beliefs, but those beliefs are demonstrably
wrong.

-- Daniel

 

[James]

Java runtimes come with binaries.

Mose Java runtimes (JVM) are written with a mixture of C/C++/ASM...

 

[James Kanze]

news:657bc0a5-8454-4d89-9141-6369602e8640@j32g2000prh.googlegroups.com...

"James Kanze" <[email protected]> wrote in message

[...]

C++ is not a portable programming language and any, non
trivial, program will only work on the system is was
designed to work on.
That's not been my experience. I've moved several large (500
KLoc or more) applications from Windows or Solaris to Linux,
with no real problems. Given the way the language has evolved,
it's often been more work to move to a more recent version of
the compiler than to move from Windows to Unix.
Even a very basic windows winmain function and messsage loop cannot be
ported, your lucky if it runs on your version of windows nvm Linux.

What's a windows winmain function? I've never seen one.

Standard entry point function for a windows process.

It's certainly not standard, and I've never seen it used.

[...]

I can't think of any programs that requires no user input

User input is often, if not always, from a file.

and are neither
sub processes or a service that has some OS specific entry point function.

A lot of Windows "applications" are plugins (e.g. to Excel). In
which case, there isn't really any entry point; they're DLL's,
which require some sort of registration (not just system
dependent, but application dependent) with the hosting
application.

Interestingly enough, you can port such programs to another
system, provided you can find an application which can host it.

Only thing I can think of is some kind of console application that takes
command line arguments, but I don't think I've seen anything like that since
win95.

Maybe it is an exageration so say "alot" of programs do not interact with
the OS?

They all ultimately interact with the OS. But not in the layers
you write: you call into a library (the C++ standard library,
Boost, whatever), and the library interacts with the OS. If
you're writing a GUI , then you need some sort of GUI library.
But as I've said, hand written GUI's are rather out of date
today---the current trend is to simply output HTML, and let
a browser be your GUI. (I'm not sure that this is a good trend,
but it does seem to be prevalent.)

 

[James Kanze]

Links please? I'm curious how bad the support is.

I'm not familiar with the TR, but if I had to do serious text
handling in Unicode in C or C++ (or in Java), I'd probably use
ICU. (I can't be sure; I've never had to do serious text
handling in Unicode. But I've heard good things about it from
people who have used it. And I do know that the native support
in C, C++ and Java is insufficient.)

In short, for any library purporting to supply Unicode "support", I /
want/ at least:
1- Iterators over Unicode strings - one that iterates by encoding
units, one that iterates by unicode code point, and one that takes a
locale and iterates by grapheme clusters.

Agreed. I don't know of a language which has this, however
(except for the one that iterates by encoding units, which seems
to be universally present for one particular encoding format,
chosen by the implementation).

Ideally, too, such iterators would exist for all of the
different Unicode encoding formats (UTF-8, UTF-16 and UTF-32).

2- Actual good collation and normalization support.

The framework is present in C++, although whether a complete
implementation for Unicode is provided depends on the C++
implementation, and the framework is not particularly simple or
convenient to use.

3- Functions to translate encodings from any "commonly" used encoding
to any of the UTF encodings, and vice versa.

Same response as for 2, except that in this case, it's not that
difficult to use.

4- Not implemented by a retarded monkey. An example of an
implementation by a retarded monkey is one using a virtual function
call per encoding unit for translation between encoding.

But you can't get away from a virtual function call per string,
which is what C++'s ctype and codecvt require.

What support C++ provides is through the various locale facets,
and there isn't (at least at present) any requirement that
facets supporting Unicode are provided (although one would
expect it from a QoI point of view). The interface to facets is
a bit twisted, I'm afraid, but I've not seen anything simpler in
other languages.

 

[Öö Tiib]

Do people still write GUI applications?  I thought that everyone
used html and a browser for user interaction.  (And I'm being
faceous.  I hope.)

It is still hard to imagine anything-engineering tools browser-based.
Something where displayed and manipulated data is larger and bit more
complex than small lists, tables or trees, where interface has to
respond quickly and where user has to do something more meaningful
than choosing from few choices or filling few forms. Certainly someone
may squeeze CAD-like or SCADA-like tool into browser, but i think it
will terribly drag down its users productivity. About like formating a
piece of illustrated text in some wiki editor is doable but usually
aggravatingly slow and tedious.

 

[Öö Tiib]

They all ultimately interact with the OS.  But not in the layers
you write: you call into a library (the C++ standard library,
Boost, whatever), and the library interacts with the OS.  If
you're writing a GUI , then you need some sort of GUI library.
But as I've said, hand written GUI's are rather out of date
today---the current trend is to simply output HTML, and let
a browser be your GUI.  (I'm not sure that this is a good trend,
but it does seem to be prevalent.)

It is i think sort of self-defense of developers. Imagine several
hours of data measured from a patient with various instruments 100
times per second. Medic who has to analyze it expects the user
interface to do complex scientific analysis over that data snip and
snip and curses the "slow" and "crappy" software. Now you put that
data into some mainframe, do the analysis there and pass the results
to user as jpg or png into browser. Outcome is not actually quicker.
It is even slower if to measure. However ... for medic everything is
suddenly OK ... internet is expected to be slow and non-
responsive.

 

[Joshua Maurice]

I'm not familiar with the TR, but if I had to do serious text
handling in Unicode in C or C++ (or in Java), I'd probably use
ICU.  (I can't be sure; I've never had to do serious text
handling in Unicode.  But I've heard good things about it from
people who have used it.  And I do know that the native support
in C, C++ and Java is insufficient.)

Indeed. My current company uses ICU handling for its server-side data
layer.

I'm reasonably familiar with Java, and while its interface is not
ideal, I find it much more usable and complete than C++'s standard
library in this regard.

The only minor point I know offhand is I don't know how portable in
practice the encodings of Java are. Howwever, at least Java requires
that the UTF encodings must be supported for a conforming
implementation.

The framework is present in C++, although whether a complete
implementation for Unicode is provided depends on the C++
implementation, and the framework is not particularly simple or
convenient to use.

Well, yes and no. When you collate Unicode strings, you don't do
lexicographic comparisons of the actual string data. Instead, you
convert the string according to some rather complex and locale
specific rules to a bit string, and then you do simple lexicographic
comparisons on the resulting bit string. You'd have to implement that
logic from basically the ground up in C++ with just the standard
library at your disposal AFAIK.

But you can't get away from a virtual function call per string,
which is what C++'s ctype and codecvt require.

What support C++ provides is through the various locale facets,
and there isn't (at least at present) any requirement that
facets supporting Unicode are provided (although one would
expect it from a QoI point of view).  The interface to facets is
a bit twisted, I'm afraid, but I've not seen anything simpler in
other languages.

I bring this point up because it's my understanding from my colleagues
that at least one version of ICU, the one my company uses, actually
does virtual function calls per code unit for some of its important
operations.

When I said my company uses ICU, I meant that my company uses a house
modified version of ICU which reworked the code to avoid the costly
virtual function calls per code point. My predecessors ran profilers,
which told them that an excessive portion of time was spent in those
virtual calls. It was a really big speedup to rework it as they did.

 

[Daniel]

If I'm not mistaken, IBM Process Server runs on IBM's WebSphere
Application Server, which is frequently pointed out as IBM's flagship
product.  That means that the reason why it was developed in Java may not
have been necessarily due to any technical reason but mainly due to IBM's
intention to build upon the company's previous work.  

I think you're mistaken in your suggestion that the IBM "WebSphere"
stack is following a rational systematic development track with one
layer developed upon another Rather, over the past decade, IBM
has acquired a huge heterogeneity of tooling from various sources, and
is attempting to patch it all together somehow under the "WebSphere"
brand, with various degrees of success. Some duct tape is required.
It's not a dissimilar situation with other vendors.

-- Daniel

 

[Paul]

news:657bc0a5-8454-4d89-9141-6369602e8640@j32g2000prh.googlegroups.com...

[...]
C++ is not a portable programming language and any, non
trivial, program will only work on the system is was
designed to work on.
That's not been my experience. I've moved several large (500
KLoc or more) applications from Windows or Solaris to Linux,
with no real problems. Given the way the language has evolved,
it's often been more work to move to a more recent version of
the compiler than to move from Windows to Unix.
Even a very basic windows winmain function and messsage loop cannot be
ported, your lucky if it runs on your version of windows nvm Linux.
What's a windows winmain function? I've never seen one.

Standard entry point function for a windows process.

It's certainly not standard, and I've never seen it used.

[...]

I can't think of any programs that requires no user input

User input is often, if not always, from a file.

and are neither
sub processes or a service that has some OS specific entry point
function.

A lot of Windows "applications" are plugins (e.g. to Excel). In
which case, there isn't really any entry point; they're DLL's,
which require some sort of registration (not just system
dependent, but application dependent) with the hosting
application.

Interestingly enough, you can port such programs to another
system, provided you can find an application which can host it.

Windows DLL's still have entry point functions namely DLLMain.
They may be similar across OS's, but the loading/registration process and
function signatures all create a different program structure that cannot be
ported.
Here is a *very* simple winodws DLL program (at bottom of page). Please tell
me how it is possible to make this code portable.
http://msdn.microsoft.com/en-us/library/ms682583.aspx

Since it's necessarry to include windows.h I'd say this is a good indication
it's not going to be portable.

They all ultimately interact with the OS. But not in the layers
you write: you call into a library (the C++ standard library,
Boost, whatever), and the library interacts with the OS. If
you're writing a GUI , then you need some sort of GUI library.
But as I've said, hand written GUI's are rather out of date
today---the current trend is to simply output HTML, and let
a browser be your GUI. (I'm not sure that this is a good trend,
but it does seem to be prevalent.)

The C++ iostream libs are simply convenience libs. In reality you aren't
going to put text to the screen using cout, It's going to be in a message
box or part of a window or something. Its a good idea to have language
extensions that provide convenience utilities like this but the problem is
that C++ is trying to incorporate all this into being part of the language
so it can be defined by the C++ standard. Back in the days of Borland
turboC++ when we all used getch() and stuff was fun to see the arguments
with people saying "what is getch()?, thats not C++". C++ seems so confused
at the moment it's trying to expand in all directions with no clear
direction at all.

If C++ wants a share of the app programming out there its not going to
happen unless the wide variety of implementations are embraced.
By this I mean C++ needs to acknowledge imp-specific stuff and embrace it
perhaps as a language extension or utility library. But the general attitude
in the C++ community seems to be that all this stuff is not covered by the
standards therefore irrellevant and nothing to do with C++, this is not good
for C++.
You need to go OT and imp-specific to deal with networking or telephony or
video cards or GPS devices or whatever specific programming task you are
taking on.

 

[Alf P. Steinbach /Usenet]

* Pete Becker, on 27.01.2011 13:46:

It's standard on Windows. <g> When you write a GUI application, the entry point
is WinMain with, if I recall correctly, four arguments. That function gets
called after the GUI stuff gets initialized. GUI libraries for Windows typically
provide WinMain internally, and run their event loop from inside it.
Command-line applications use main(), of course.

Note that that is just Microsoft's old, meaningless convention. It's only
Microsoft's toolchain that ties startup functions to Windows subsystem, and then
only by obfuscation and by being non-standard by default. Differentiating
between subsystems in that way has no advantages and a lot of disadvantages.

However, all of the four startup functions offered by the MS runtime (main,
wMain, WinMain and wWinMain) can be useful in various situations.

So, as I imagine it, they had one smart guy inventing the startup functions, and
one idiot guy responsible for the toolchain.


Cheers,

- Alf

 

[James Kanze]

It is i think sort of self-defense of developers. Imagine several
hours of data measured from a patient with various instruments 100
times per second. Medic who has to analyze it expects the user
interface to do complex scientific analysis over that data snip and
snip and curses the "slow" and "crappy" software. Now you put that
data into some mainframe, do the analysis there and pass the results
to user as jpg or png into browser. Outcome is not actually quicker.
It is even slower if to measure. However ... for medic everything is
suddenly OK ... internet is expected to be slow and non-
responsive.

But I wasn't really thinking of using the internet. Just doing
all of the calculations in a C++ program, which acts like an
HTTP server (on the local machine). But graphic applications
are probably an exception---you might want a native GUI for
those. I'm not sure: I don't know what the possibilities for
displaying graphics are in a browser. But I can easily imagine
that for quality graphics, you want to be able to control each
pixel yourself. Similarly for quality typesetting. But who
expects quality typesetting for text today? And what GUI
program gives it? And for that matter, how many users would
even accept it: it certainly wouldn't have the "look and feel"
of other applications on the system.

 

[James Kanze]

The C++ iostream libs are simply convenience libs. In reality you aren't
going to put text to the screen using cout,

In reality, you aren't going to output text to the screen
directly, period. You'll output text to some front-end, which
will take care of the formatting and display. Or you'll output
it to a log.

I'll agree that a lot of programs won't use ostream for much
other than logging, but the other accesses will be to data
bases, or to other programs, or whatever. And a lot of other
programs will be designed to be invoked from scripts, with their
output being read by another program. And even more programs
won't have any text input or output at all.

[...]

If C++ wants a share of the app programming out there its not going to
happen unless the wide variety of implementations are embraced.
By this I mean C++ needs to acknowledge imp-specific stuff and embrace it
perhaps as a language extension or utility library.

That's more or less what C++ does. It leaves a lot of things
"implementation defined". Generally, things which make no sense
being defined as part of the language standard (but there are
exceptions---a standard GUI-interface would be a good idea).

But the general attitude
in the C++ community seems to be that all this stuff is not covered by the
standards therefore irrellevant and nothing to do with C++, this is not good
for C++.
You need to go OT and imp-specific to deal with networking or telephony or
video cards or GPS devices or whatever specific programming task you are
taking on.

I think the general point of view is that you need to know more
than just C++ to program in C++. I think that this is true for
just about any language; you can't really write useful programs
without some domain knowledge as well. And given the extension
of this knowledge, it seems reasonable to have it discussed in
various forums: if someone is writing a GUI for Windows, and
needs help with the GUI library, it's really no different than
if someone needs specialized knowledge of derivitive trading
(the case where I work): neither really have much to do with
C++, nor should they.

 

[James Kanze]

Indeed. My current company uses ICU handling for its server-side data
layer.

I'm reasonably familiar with Java, and while its interface is not
ideal, I find it much more usable and complete than C++'s standard
library in this regard.

I'm not sure. I don't find the Java stuff that easy to use, and
used correctly, C++'s locale stuff can be pretty complete. The
big difference, I suspect, is documentation: if there's one
place where Java beats C++ (and every other language I know)
hands down, it's documentation: it's very easy to find tutorial
trails and the API documentation for just about anything that
Java supports, where as I wouldn't even know where to point you
to for good explications of C++'s locale support.

The only minor point I know offhand is I don't know how portable in
practice the encodings of Java are. Howwever, at least Java requires
that the UTF encodings must be supported for a conforming
implementation.

The next version of C++ will require some support for UTF-8,
UTF-16 and UTF-32. But I don't think that requirement has
propagated into anything concrete in locale---I agree that that
is a bother.

Well, yes and no. When you collate Unicode strings, you don't do
lexicographic comparisons of the actual string data. Instead, you
convert the string according to some rather complex and locale
specific rules to a bit string, and then you do simple lexicographic
comparisons on the resulting bit string. You'd have to implement that
logic from basically the ground up in C++ with just the standard
library at your disposal AFAIK.

C++ supports lexicographic comparison in any locale it supports.
If the implementation supports Unicode locales (and from a QoI
point of view, it surely should), then you can compare two
strings, or convert them into something which will give correct
results using bitwise comparison, or get a hash of a string
which is compatible with the comparison. See the collate facet
in locale.

I bring this point up because it's my understanding from my colleagues
that at least one version of ICU, the one my company uses, actually
does virtual function calls per code unit for some of its important
operations.

When I said my company uses ICU, I meant that my company uses a house
modified version of ICU which reworked the code to avoid the costly
virtual function calls per code point. My predecessors ran profilers,
which told them that an excessive portion of time was spent in those
virtual calls. It was a really big speedup to rework it as they did.

I'm not completely surprised. IIUC, ICU originated in the Java
world, where virtual function calls are the standard. At least
in most cases (the ones I've looked at), the C++ interface in
facets has two versions of the functions, one which takes
characters, and one which takes strings. (Regretfully, strings
represented by a pair of char const*---because the functions are
virtual, templates can't be used.)