«

On Jan 26, 11:13 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> 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.

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.

--
James Kanze

On Jan 25, 9:43*pm, James Kanze <james.ka...@gmail.com> wrote:
> On Jan 25, 6:25 pm, Carlo Milanesi <carlo.nospam.milan...@libero.it>
> wrote:
>
> > Nomen Nescio wrote:
> > > I wonder if the enormous fallout between Oracle and the open-source
> > > community over Java will lead to a renewed interest in C++.
> > I think Java and C++ belong to different camps, and therefore they are
> > not in competition. A relatively low level language like C++ has always
> > been and will keep to be a competitor of C language and of Fortran language.
> > I think that in the future C++ will be used less and less for GUI-based
> > or Web-based applications, and more and more for embedded software,
> > device drivers, numerical analysis libraries, and high-performance video
> > games engines.
>
> 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.

On Jan 27, 11:15*am, James Kanze <james.ka...@gmail.com> wrote:
> On Jan 26, 10:15 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > 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.)

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.

On Jan 27, 1:30*am, James Kanze <james.ka...@gmail.com> wrote:
> On Jan 26, 11:13 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
> > 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.
>
> 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.

> > In short, for any library purporting to supply Unicode "support", I /
> > want/ at least:
> > 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.

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.

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

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.

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

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

"James Kanze" <> wrote in message
news:bcbca8c1-5bc4-41e0-937c-...
> 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.
>

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.



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

* Pete Becker, on 27.01.2011 13:46:
> On 2011-01-27 04:15:00 -0500, James Kanze said:
>
>> 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
>>
>>>> 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.
>
> 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

--
blog at <url: http://alfps.wordpress.com>

On Jan 27, 10:16 am, Öö Tiib <oot...@hot.ee> wrote:
> On Jan 27, 11:15 am, James Kanze <james.ka...@gmail.com> wrote:

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

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

> 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

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

> news:bcbca8c1-5bc4-41e0-937c-...

> 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

On Jan 27, 10:28 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On Jan 27, 1:30 am, James Kanze <james.ka...@gmail.com> wrote:

> > On Jan 26, 11:13 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:

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

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

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.

> > > In short, for any library purporting to supply Unicode "support", I /
> > > want/ at least:
> > > 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.

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

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

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

--
James Kanze