Re: These are identical, right? char const* and const char*

From: John Carson (donaldquixote_at_datafast.net.au)
Date: 03/23/04 

Date: Tue, 23 Mar 2004 15:12:33 +1100

"Hattuari" <susudata@setidava.kushan.aa> wrote in message
news:ApKdnRMSnZXhCMLdRVn-jg@speakeasy.net
> John Carson wrote:
>> You gain working directly with the platform API in your code and thus
>> fully exploiting API features, i.e., learning all of those extra
>> things that you don't want to learn gains you the full power of the
>> platform.
>
> All those extra things I don't want to learn? What exactly are
> those?

I have pretty much lost interest in this conversation. You appear more and
more like a troll. You earlier complained:

"The word 'Unicode' occurres once in the 2003 standard, and 'utf' is absent.
The word 'thread' likewise has only one occurrance. This means that, in
addition to mastering the core language, I have to learn a large amount of
external material in order to program in and for the 21st century."

Thus, the extra things you don't want to learn are obviously that "large
amount of external material". Note that you complain about the lack of
coverage of threads and yet when I said that Boost has a threads library,
you seemed to lose interest.

"Personally, I believe changing the default character set to UTF-8 would be
a lot more beneficial than native threading."

It seems that your only real interest is in complaining.

> I can work directly with the system API in Java as well.

I explicitly addressed this point, yet you ignore it. More troll behaviour.

>> Microsoft introduces a new set of APIs every time it brings out a new
>> version of Windows and these are instantly available to Windows C++
>> programmers.
>
> Uh, there's been some debate about that issue from time to time.
> <ROFLMAO>

Hilarious, but avoiding the issue.

>> Tradeoffs have to be made. C++ has chosen to focus on core features
>> that can run on a vast array of platforms. It then gives you the
>> choice of using third party cross platform libraries or of using
>> platform specific APIs for those things not covered by the standard.
>> That is the niche that C++ targets, and there seems to be plenty of
>> demand for it. Java targets a different niche but I am tired of
>> pointing out that it is not the only valid one.
>
> So how does this address the fact that some things that could be
> specified in the standard, are not?

Obviously it doesn't and obviously I never intended it too. I was referring
to things like support for threading, sophisticated memory management,
hardware support and so on. More troll behaviour.

> Such things as fixed ordering of
> modifiers in declarations, or default sizes for fundamental types? A
> bunch of handwaving generalities are not persuasive.

Fixed ordering of modifiers is your personal obsession. If we were to start
from a blank page, then I would prefer flexible orderings so I don't have to
remember fixed orderings. But it is a trivial issue either way. What is
important is that we are not starting from a blank page. Changing it would
break about half of all existing C++ code. How stupid would that be.
Fortunately, you aren't the one in charge of the standard and the people who
are don't break existing code without a good reason. The standard only has
force to the extent that people comply with it voluntarily. C++ compiler
vendors can and do ignore it if they think it is stupid. If the people
responsible for the C++ standard were so foolish as to adopt your
suggestion, then that aspect of the standard would simply be ignored.
(Microsoft, it might be pointed out, has ignored C99 entirely. This is for a
variety of reasons but illustrates the voluntary nature of standards
compliance.)

As for default sizes of fundamental types, the same issue of breaking
existing code arises. As for what would be ideal, I don't know enough to
confidently say. That stops me even though it apparently doesn't stop you. I
do know that, for example, there is hardware on which a character has to be
32 bits. Forcing char to be something different would cause problems for
people writing for that hardware. I think that there are problems either way
and don't know enough to make a judgement about where the problems are
greater. Those responsible for the C++ standard know vastly more than I do
and, in the absence of compelling evidence to the contrary, I trust their
judgement.

> Have you read _The_Java_Programming_Language_, by Arnold, Gosling &
> Holmes? I have, and I have it sitting right here. I've also read all
> but 60 pages of the core langueage part of TC++PL SE. When I get
> finished with this message, I intend to finish the last two chapters.
> C++ has far more subtelties than does Java, so I can't say I
> understand what I've read as well as I did the Java counterpart. I've
> also read K&R, as well as Cooper's _Standard_Pascal_, several
> sections of the ECMAScript standard, The introductory sections of the
> GNU Lisp Reference Manual, the core sections of the Mathematic Book,
> and probably other de facto, or actual language standard
> specifications.

Is there a point to this? You seem to be at pains to demonstrate what a
knowledgeable fellow you are. Levels of knowledge are relative. The
collective knowledge that goes into the C++ standard makes what either of us
know trifling by comparison. It is clear from many of your observations that
you don't know enough to make sensible judgements. The knowledge that you
are lacking most of all is a knowledge of your own limitations.

> There are useless ugly features of C++ that are never changed because
> the advocates of change don't want to deal with the entrenched
> opposition who refuse to reexamine the reasoning that led to the
> original decision.

I don't trust your capacity to judge what is useless. You barely know the
C++ language at all. You barely know the contexts in which it is used. Yet
you think that you are qualified to pronounce on issues of C++ design and to
denigrate the efforts of those far more knowledgeable than yourself.

> Class level (or perhaps I should say 'object level') locking, or
> function level locking. I'll have to review the details, but it
> basically is the distinction between locking on the whole object or
> locking on a member function.

Which then raises the question of what you mean by "locking". But don't
bother to tell me. It appears to be just another case of you talking off the
top of your head without knowing the details.

>
> OK, I'll play along. Make UCS-2 the standard, and provide support in
> the library to convert to UTF-8. AFAIK, that's pretty much a
> compressed form of UCS-2.

You know very little. It is a radically different system. UCS-2 uses two
bytes for everything. UTF-8 uses from 1 to 6 bytes per character. Another
example of clueless arrogance. And you actually expect your opinions on
these matters to be taken seriously? I don't claim to any expertise on these
matters, but a couple of minutes research turns up the fact that UCS-2 would
be a big problem on Unix systems.

> Uh, so far as I know, Microsoft is using Unicode in everything NT
> based, and has support for it in all their WinDOS OS's as well.
> Note
> I didn't say Mathematica is UTF-8 at the core. When I installed
> Windows NT on my system in October 1992, its native character set was
> Unicode. Has that changed?

Unicode is not one set of character encoding standards. A quick check
suggests that there are 13 different possible encoding methods with some
reasonable usage, namely

UCS-2, UCS-2BE, UCS-2LE, UCS-4, UCS-4LE, UCS-4BE, UTF-8, UTF-16, UTF-16BE,
UTF-16LE, UTF-32, UTF-32BE, UTF-32LE.

There are also another 3 which never achieved any real popularity.

I suggest you spend more time learning and less time trying to teach what
you don't know. 

-- 
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

Relevant Pages

  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... These days I don't do compiler maintenance, but I HAVE done in the past, so ... You had a chance to point out how adherence to the standard can improve ... >> compile it WITH MINOR MODIFICATIONS for a specific platform. ... > platform-specific extension to COBOL ...
    (comp.lang.cobol)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... > implementations that purport to conform to a COBOL standard is to write ... I DID think any old compiler would be able to ... compile it WITH MINOR MODIFICATIONS for a specific platform. ... >> Portability depends on where you plan to port (or more likely where ...
    (comp.lang.cobol)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... I DID think any old compiler would be able to ... > compile it WITH MINOR MODIFICATIONS for a specific platform. ... > not going to go to the Standard to see what SHOULD work. ... If you write your COBOL code avoiding the things that are marked as ...
    (comp.lang.cobol)
  • Re: C portability is a myth
    ... > solicitation for the availability of a compiler for a given platform. ... If the source is pure Standard C ... can be successfully ported to all implementations. ...
    (comp.lang.c)
  • Re: O_TEXT, in microsoft environment
    ... We tend to concentrate on the C language as defined by the ISO standard, ... as lseek read write and open). ... documentation for your platform. ... the functions that the standard specifies) is that when a file is written in text mode, the character represented by '\n' will be ...
    (comp.lang.c)