«

On Jan 26, 1:30 pm, Daniel <danielapar...@gmail.com> wrote:
> On Jan 25, 2:43 pm, James Kanze <james.ka...@gmail.com> wrote:

> > One place C++ very definitely rules is large scale servers. The
> > HTML formatting may (and often is) deferred to Java, since
> > that's what the web server implementation supports, but the web
> > server implementation, and all of the programs that Java
> > interrogates to get the data, are written in C++. (The new
> > ones, anyway...)

> 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.

--
James Kanze

Op 26-Jan-11 12:30, James Kanze schreef:
> On Jan 25, 10:28 pm, "Paul"<pchris...@yahoo.co.uk> wrote:
>> "Nomen Nescio"<nob...@dizum.com> 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.

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.

On Jan 26, 1:49 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "James Kanze" <james.ka...@gmail.com> 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.

> 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

On Jan 26, 3:48 pm, Daniel <danielapar...@gmail.com> wrote:
> On Jan 26, 6:30 am, James Kanze <james.ka...@gmail.com> wrote:

> > On Jan 25, 10:28 pm, "Paul" <pchris...@yahoo.co.uk> wrote:

> > > Your original question seems to imply that C++ is
> > > currently less popular than Java. I don't know if this is
> > > the case or not but Java seems to be the language of
> > > choice for most application programming.

> > It depends on the domain. I've mostly worked on large scale
> > servers, and I've never seen Java there.

> 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.

--
James Kanze

Daniel wrote:

> 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.


<snip/>
> 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

"James Kanze" <> wrote in message
news:657bc0a5-8454-4d89-9141-...
> On Jan 26, 1:49 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>> "James Kanze" <james.ka...@gmail.com> 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.


>> 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.
>
> --
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?

On Jan 26, 12:29*pm, Rui Maciel <rui.mac...@gmail.com> wrote:
> 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.

On Jan 26, 1:51*pm, James Kanze <james.ka...@gmail.com> wrote:
> On Jan 26, 1:30 pm, Daniel <danielapar...@gmail.com> wrote:
>
> > On Jan 25, 2:43 pm, James Kanze <james.ka...@gmail.com> wrote:
> > > One place C++ very definitely rules is large scale servers. *The
> > > HTML formatting may (and often is) deferred to Java,
> > 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?

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

"Daniel" <> wrote in message
news:49b752fc-dd3e-4672-a70e-...
On Jan 26, 1:51 pm, James Kanze <james.ka...@gmail.com> wrote:
> > On Jan 26, 1:30 pm, Daniel <danielapar...@gmail.com> wrote:
> >
> > > On Jan 25, 2:43 pm, James Kanze <james.ka...@gmail.com> wrote:
> > > > One place C++ very definitely rules is large scale servers. The
> > > > HTML formatting may (and often is) deferred to Java,
> > > 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?

> Java runtimes come with binaries.

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


> The list above includes some server
> implementations that are entirely written in Java, and others that are
> mixed.

On Jan 26, 10:15 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message

> news:657bc0a5-8454-4d89-9141-...

> > On Jan 26, 1:49 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> >> "James Kanze" <james.ka...@gmail.com> 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