Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #67243 > unrolled thread

An example: code to list exports of a Windows DLL.

Back to article view | Back to comp.lang.c++

Contents

  An example: code to list exports of a Windows DLL. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-02 03:36 +0200
    Re: An example: code to list exports of a Windows DLL. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-02 11:22 +0200
    Re: An example: code to list exports of a Windows DLL. rick.c.hodgin@gmail.com - 2019-08-02 02:33 -0700
      Re: An example: code to list exports of a Windows DLL. "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-02 16:54 -0700
        Re: An example: code to list exports of a Windows DLL. "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-02 19:09 -0700
    Now on Github; based ordinals in listing (Re: An example: code to list exports of a Windows DLL.) "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-02 20:20 +0200
    Re: An example: code to list exports of a Windows DLL. legalize+jeeves@mail.xmission.com (Richard) - 2019-08-19 19:44 +0000
      Re: An example: code to list exports of a Windows DLL. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-20 02:12 +0200
        Re: An example: code to list exports of a Windows DLL. Keith Thompson <kst-u@mib.org> - 2019-08-19 18:31 -0700
          Re: An example: code to list exports of a Windows DLL. David Brown <david.brown@hesbynett.no> - 2019-08-20 08:42 +0200
            Re: An example: code to list exports of a Windows DLL. Keith Thompson <kst-u@mib.org> - 2019-08-20 02:18 -0700
              Re: An example: code to list exports of a Windows DLL. Ian Collins <ian-news@hotmail.com> - 2019-08-20 22:22 +1200
                Re: An example: code to list exports of a Windows DLL. Keith Thompson <kst-u@mib.org> - 2019-08-20 14:21 -0700
              Re: An example: code to list exports of a Windows DLL. David Brown <david.brown@hesbynett.no> - 2019-08-20 13:00 +0200
                Re: An example: code to list exports of a Windows DLL. Keith Thompson <kst-u@mib.org> - 2019-08-20 14:59 -0700
                  Re: An example: code to list exports of a Windows DLL. David Brown <david.brown@hesbynett.no> - 2019-08-21 10:29 +0200
                    Re: An example: code to list exports of a Windows DLL. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-21 11:14 +0200
                      Re: An example: code to list exports of a Windows DLL. Keith Thompson <kst-u@mib.org> - 2019-08-21 02:55 -0700
                        Re: An example: code to list exports of a Windows DLL. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-21 12:30 +0200
                          Re: An example: code to list exports of a Windows DLL. David Brown <david.brown@hesbynett.no> - 2019-08-21 14:22 +0200
                          Re: An example: code to list exports of a Windows DLL. Keith Thompson <kst-u@mib.org> - 2019-08-21 12:41 -0700
                            Re: An example: code to list exports of a Windows DLL. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-22 03:38 +0200
                              Re: An example: code to list exports of a Windows DLL. Keith Thompson <kst-u@mib.org> - 2019-08-21 19:24 -0700
                                Re: An example: code to list exports of a Windows DLL. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-21 23:21 -0400
                                Re: An example: code to list exports of a Windows DLL. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-22 06:01 +0200
                                  Re: An example: code to list exports of a Windows DLL. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-22 00:26 -0400
                                    Re: An example: code to list exports of a Windows DLL. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-22 07:54 +0200
                                      Re: An example: code to list exports of a Windows DLL. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-22 09:08 -0400
                                        Re: An example: code to list exports of a Windows DLL. "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-22 19:37 +0200
                              Re: An example: code to list exports of a Windows DLL. scott@slp53.sl.home (Scott Lurndal) - 2019-08-22 13:17 +0000
                                Re: An example: code to list exports of a Windows DLL. David Brown <david.brown@hesbynett.no> - 2019-08-22 16:07 +0200
                    Re: An example: code to list exports of a Windows DLL. Keith Thompson <kst-u@mib.org> - 2019-08-21 02:42 -0700
    Re: An example: code to list exports of a Windows DLL. Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-08-20 04:09 -0700
      Re: An example: code to list exports of a Windows DLL. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-08-20 17:24 -0700

Page 2 of 2 — ← Prev page 1 [2]

#67855

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> On 21.08.2019 11:55, Keith Thompson wrote:
>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>> On 21.08.2019 10:29, David Brown wrote:
>>>> On 20/08/2019 23:59, Keith Thompson wrote:
>> [...]
>>>>> The effect is the same: a diagnostic is required.  (If the
>>>>> implementation chooses to produce an executable after printing the
>>>>> required diagnostic, I suppose the behavior is undefined by omission.)
>>>
>>> There's no need to print anything. /Not/ blinking the caps lock
>>> indicator for a millisecond is a valid diagnostic. The standard doesn't
>>> specify what a "diagnostic" or a "diagnostic message" is, that it should
>>> involve text at all, or that it should be context-independent...
>>>
>>> That may sound like a silly argument.
>> 
>> Yes, it does.
>> 
>> The standard requires a diagnostic message for certain errors, and
>> defines a "diagnostic message" as "a message belonging to an
>> implementation-defined subset of the implementation's output messages".
>> The phrase "implementation-defined" means the documentation has to
>> document it.
>> 
>> gcc's documentation, for example, says:
>> 
>>     * 'How a diagnostic is identified (C90 3.7, C99 and C11 3.10, C90,
>>       C99 and C11 5.1.1.3).'
>> 
>>       Diagnostics consist of all the output sent to stderr by GCC.
>> 
>> That's for C, but the "C++ Implementation-Defined Behavior" says "Some
>> choices are documented in the corresponding document for the C
>> language."
>> 
>> So no, for gcc/g++ not blinking the caps lock is not a diagnostic.
>
> I'm sorry, that's a simple fallacy.

No, that's what the documentation says.

> That g++ doesn't do that now, has no bearing on what it /can/ do.

How is that relevant?

The language standard requires each implementation to document what a
"diagnostic" is.  The gcc/g++ documentation clearly documents what a
"diagnostic" is, in a way that clearly excludes "non-blinking caps
lock".

A future version could change that, but I'd be willing to bet that it
won't.

By accepting identifiers with "$" without a diagnostic in what is
intended to be a conforming mode, g++ is violating the requirements of
the C++ standard.  If you disagree, what exactly is your argument?

> As far as the formal is concerned g++ can use the non-blinking caps lock 
> as a diagnostic.

The "formal" what?

Yes, the standard permits an implementation to use a non-blinking caps
lock as a diagnostic -- if and only if its documentation defines
"diagnostic" in a way that's consistent with that.  No implementation
does so or is likely to do so in the future.

I thought your argument was based on "common sense".

Here's an idea.  I'll just assume that, at some point in the future, you
might change your argument and agree with me.  Problem solved.

[...]

> For example, I remember `$` being used in the system API in the HP3000. 
> That's long ago, 1980s, but presumably use of `$` in system API function 
> names was part of the reasons why compilers supported it. And continue 
> to support it.

OpenVMS uses $ in identifiers (and C and C++ compilers for OpenVMS have
to allow for that).  Which is why, in my opinion, the standard *should*
allow compilers to accept $ in identifiers.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#67859

On 21.08.2019 21:41, Keith Thompson wrote:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>> On 21.08.2019 11:55, Keith Thompson wrote:
>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>>> On 21.08.2019 10:29, David Brown wrote:
>>>>> On 20/08/2019 23:59, Keith Thompson wrote:
>>> [...]
>>>>>> The effect is the same: a diagnostic is required.  (If the
>>>>>> implementation chooses to produce an executable after printing the
>>>>>> required diagnostic, I suppose the behavior is undefined by omission.)
>>>>
>>>> There's no need to print anything. /Not/ blinking the caps lock
>>>> indicator for a millisecond is a valid diagnostic. The standard doesn't
>>>> specify what a "diagnostic" or a "diagnostic message" is, that it should
>>>> involve text at all, or that it should be context-independent...
>>>>
>>>> That may sound like a silly argument.
>>>
>>> Yes, it does.
>>>
>>> The standard requires a diagnostic message for certain errors, and
>>> defines a "diagnostic message" as "a message belonging to an
>>> implementation-defined subset of the implementation's output messages".
>>> The phrase "implementation-defined" means the documentation has to
>>> document it.
>>>
>>> gcc's documentation, for example, says:
>>>
>>>      * 'How a diagnostic is identified (C90 3.7, C99 and C11 3.10, C90,
>>>        C99 and C11 5.1.1.3).'
>>>
>>>        Diagnostics consist of all the output sent to stderr by GCC.
>>>
>>> That's for C, but the "C++ Implementation-Defined Behavior" says "Some
>>> choices are documented in the corresponding document for the C
>>> language."
>>>
>>> So no, for gcc/g++ not blinking the caps lock is not a diagnostic.
>>
>> I'm sorry, that's a simple fallacy.
> 
> No, that's what the documentation says.
> 
>> That g++ doesn't do that now, has no bearing on what it /can/ do.
> 
> How is that relevant?
> 
> The language standard requires each implementation to document what a
> "diagnostic" is.  The gcc/g++ documentation clearly documents what a
> "diagnostic" is, in a way that clearly excludes "non-blinking caps
> lock".
> 
> A future version could change that, but I'd be willing to bet that it
> won't.
> 
> By accepting identifiers with "$" without a diagnostic in what is
> intended to be a conforming mode, g++ is violating the requirements of
> the C++ standard.  If you disagree, what exactly is your argument?

The above responds to what was a coherent /reductio ad absurdum/ 
argument, now lost in refocusing on and possibly misinterpreting one of 
the shattered pieces of it.

As pointed out by you up-thread it's not the case that accepting the `$` 
requires a diagnostic in all versions of the standard. g++ is simply not 
fully up to date regarding C++17 in this respect. But then few 
compilers, if any, are standard-conforming by default: one needs to 
cajole them into conformance by applying the relevant set of options.


>> As far as the formal is concerned g++ can use the non-blinking caps lock
>> as a diagnostic.
> 
> The "formal" what?
> 
> Yes, the standard permits an implementation to use a non-blinking caps
> lock as a diagnostic -- if and only if its documentation defines
> "diagnostic" in a way that's consistent with that.  No implementation
> does so or is likely to do so in the future.
> 
> I thought your argument was based on "common sense".

Yep.


> Here's an idea.  I'll just assume that, at some point in the future, you
> might change your argument and agree with me.  Problem solved.
> 
> [...]
> 
>> For example, I remember `$` being used in the system API in the HP3000.
>> That's long ago, 1980s, but presumably use of `$` in system API function
>> names was part of the reasons why compilers supported it. And continue
>> to support it.
> 
> OpenVMS uses $ in identifiers (and C and C++ compilers for OpenVMS have
> to allow for that).  Which is why, in my opinion, the standard *should*
> allow compilers to accept $ in identifiers.
> 
> [...]

Yes, I should have written MPE/IV, the OS we used on the HP3000. Sorry.

It's possible that all this is tied to the attempt to remove `$` in 
ASCII, as I recall instigated by Russia or France, a political thing. I 
mean, tied by the baffling decision to not include `$` in the C++ basic 
execution character set.

For the new ASCII that I don't remember the name of, we got the (hark) 
universal currency symbol `¤` as a replacement for `$`. Nobody uses 
that. It's meaningless except as a political statement, but it's there 
on my keyboard, taking up one key combination.


Cheers!,

- Alf

[toc] | [prev] | [next] | [standalone]

#67860

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> On 21.08.2019 21:41, Keith Thompson wrote:
[...]
>> By accepting identifiers with "$" without a diagnostic in what is
>> intended to be a conforming mode, g++ is violating the requirements of
>> the C++ standard.  If you disagree, what exactly is your argument?
>
> The above responds to what was a coherent /reductio ad absurdum/ 
> argument, now lost in refocusing on and possibly misinterpreting one of 
> the shattered pieces of it.

I still can't make any sense of what you've written so far in this
thread.  Perhaps I'll stop trying.

> As pointed out by you up-thread it's not the case that accepting the `$` 
> requires a diagnostic in all versions of the standard. g++ is simply not 
> fully up to date regarding C++17 in this respect. But then few 
> compilers, if any, are standard-conforming by default: one needs to 
> cajole them into conformance by applying the relevant set of options.

As I said, I did apply the relevant set of options.

C++17 does not permit '$' in identifiers, and requires a diagnostic
for any program that attempts to use a '$' in an identifier.
Earlier editions of the standard do permit implementations to support
'$' in identifiers.  gcc's lack of a diagnostic in conforming mode
"gcc -std=c++17 -Wpedantic" makes it non-conforming.  If you agree
with that, I don't know what we're arguing about.  If you don't,
I have yet to see an explanation.

I've also suggested that the committee probably did not intend to
make a significant change in this area.

[...]

> It's possible that all this is tied to the attempt to remove `$` in 
> ASCII, as I recall instigated by Russia or France, a political thing. I 
> mean, tied by the baffling decision to not include `$` in the C++ basic 
> execution character set.

I've never heard of any attempt to remove '$' from ASCII, which I
believe has not changed since 1967.  Do you have a citation for that?

'$' is not in the source or execution basic character set, a decision
that was made a long time ago.  Apparently '$' is not supported in
all versions of EBCDIC, or at least doesn't have a consistent code
(see the Wikipedia article).  And there are no tokens in C or C++
that required $ (or @ or `, the only three printable ASCII characters
not in the C or C++ basic character set).

> For the new ASCII that I don't remember the name of, we got the (hark) 
> universal currency symbol `¤` as a replacement for `$`. Nobody uses 
> that. It's meaningless except as a political statement, but it's there 
> on my keyboard, taking up one key combination.

There is no "new ASCII".  ASCII is a 7-bit character set.  '¤' is part
of Unicode (and Latin-1).  Unicode calls it "CURRENCY SIGN".  It's not a
replacement for '$' (DOLLAR SIGN), which still exists in ASCII, Latin-1,
and Unicode.  (DOLLAR SIGN is 0x24.  CURRENCY SIGN is 0xA4.)  If there's
a political issue, it's not one that interests me unless it's relevant
to C++.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#67862

On 8/21/19 10:24 PM, Keith Thompson wrote:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
...
>> It's possible that all this is tied to the attempt to remove `$` in 
>> ASCII, as I recall instigated by Russia or France, a political thing. I 
>> mean, tied by the baffling decision to not include `$` in the C++ basic 
>> execution character set.
> 
> I've never heard of any attempt to remove '$' from ASCII, which I
> believe has not changed since 1967.  Do you have a citation for that?
> 
> '$' is not in the source or execution basic character set, a decision
> that was made a long time ago.

To be more precise, that decision predates the C++ standard, which
inherited it from the C standard. It had already been made by the time
C89 was approved. K&R did not allow '$' in identifiers, and didn't use
it anywhere in the C grammar, but didn't say anything about whether an
implementation was required to accept such characters if they appeared
in header names, comments, character constants, or string literals. The
decision to not include $ in either the source or execution basic
character sets was presumably made at the same time that it was decided
that the standard should specify those sets.

[toc] | [prev] | [next] | [standalone]

#67865

On 22.08.2019 04:24, Keith Thompson wrote:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>> On 21.08.2019 21:41, Keith Thompson wrote:
> 
> [...]
> 
>> It's possible that all this is tied to the attempt to remove `$` in
>> ASCII, as I recall instigated by Russia or France, a political thing. I
>> mean, tied by the baffling decision to not include `$` in the C++ basic
>> execution character set.
> 
> I've never heard of any attempt to remove '$' from ASCII, which I
> believe has not changed since 1967.  Do you have a citation for that?

Wikipedia's article on `¤` mentions that the replacement was formally 
proposed by Italy.

It cites an article on the web, written by an unknown *nix administrator 
in the 1990s, but with easily checkable facts:

<url: http://czyborra.com/charsets/iso646.html>
[quote]
ASCII and its national variants were declared international standard ISO 
646 in 1972. Back then, the socialist countries managed to substitute 
the international currency sign ¤ for ASCII's capitalist dollar sign $ 
in the the first international reference version ISO-646-IRV but this 
was revised in 1991 and now ISO-646-IRV is a synonym for ISO-646-US or 
US-ASCII as it is used in the core Internet protocols.
[/quote]

I guess this is where I remembered Russia from.

Or some other source discussing the same history. It was all political.

The 1991 6th edition of that standard confirms in its annex C the above 
claim that the new ASCII, ISO-646 (note: the codes of Unicode are 
ISO-10646), "was revised" back to its former `$`-glory:

[quote]
3) In the G0 set of the IRV the character DOLLAR SIGN replaces the 
character CURRENCY SIGN in position 2/4.
Otherwise this G0 set is unchanged.
[quote]


> '$' is not in the source or execution basic character set, a decision
> that was made a long time ago.  Apparently '$' is not supported in
> all versions of EBCDIC, or at least doesn't have a consistent code
> (see the Wikipedia article).  And there are no tokens in C or C++
> that required $ (or @ or `, the only three printable ASCII characters
> not in the C or C++ basic character set).
> 
>> For the new ASCII that I don't remember the name of, we got the (hark)
>> universal currency symbol `¤` as a replacement for `$`. Nobody uses
>> that. It's meaningless except as a political statement, but it's there
>> on my keyboard, taking up one key combination.
> 
> There is no "new ASCII".

I'm sorry, that's just wrong, although that statement is literally true 
by using the word "is" instead of "never was".


>  ASCII is a 7-bit character set.  '¤' is part
> of Unicode (and Latin-1).  Unicode calls it "CURRENCY SIGN".  It's not a
> replacement for '$' (DOLLAR SIGN), which still exists in ASCII, Latin-1,
> and Unicode.  (DOLLAR SIGN is 0x24.  CURRENCY SIGN is 0xA4.)

Yes, it's back in place. Since 1991. Apparently the international 
currency sign idiocy was adopted in 1972, but even Wikipedia contradicts 
itself on this matter, so I'm not 100% sure when it started.


> If there's
> a political issue, it's not one that interests me unless it's relevant
> to C++.

I think it's quite possibly relevant to the original decision to not 
include `$`.

A mistaken political correctness stance where `$` was seen as just too 
Western-ish, as a kind of discrimination.


Cheers!,

- Alf

[toc] | [prev] | [next] | [standalone]

#67866

On 8/22/19 12:01 AM, Alf P. Steinbach wrote:
> On 22.08.2019 04:24, Keith Thompson wrote:
>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
...
>>> For the new ASCII that I don't remember the name of, we got the (hark)
>>> universal currency symbol `¤` as a replacement for `$`. Nobody uses
>>> that. It's meaningless except as a political statement, but it's there
>>> on my keyboard, taking up one key combination.
>>
>> There is no "new ASCII".
> 
> I'm sorry, that's just wrong, although that statement is literally true 
> by using the word "is" instead of "never was".

ASCII was first standardized as ASA X3.4-1963, and was revised in 1965,
1967, 1968, 1977, and 6 different versions came out in 1986
<https://en.wikipedia.org/wiki/ASCII#History>. So you're right - there
has been a "new ASCII" - a total of 10 of them, in fact. However, that
was all a long time ago, and every one of those versions included $.
What you're referring to is an early version of ISO/IEC 646, which was
based on ASCII and was ASCII's successor, but is not, itself, ASCII.

[toc] | [prev] | [next] | [standalone]

#67867

On 22.08.2019 06:26, James Kuyper wrote:
> On 8/22/19 12:01 AM, Alf P. Steinbach wrote:
>> On 22.08.2019 04:24, Keith Thompson wrote:
>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> ...
>>>> For the new ASCII that I don't remember the name of, we got the (hark)
>>>> universal currency symbol `¤` as a replacement for `$`. Nobody uses
>>>> that. It's meaningless except as a political statement, but it's there
>>>> on my keyboard, taking up one key combination.
>>>
>>> There is no "new ASCII".
>>
>> I'm sorry, that's just wrong, although that statement is literally true
>> by using the word "is" instead of "never was".
> 
> ASCII was first standardized as ASA X3.4-1963, and was revised in 1965,
> 1967, 1968, 1977, and 6 different versions came out in 1986
> <https://en.wikipedia.org/wiki/ASCII#History>. So you're right - there
> has been a "new ASCII" - a total of 10 of them, in fact.

You're talking about the US national variant of ISO-646.

That's a meaningless interpretation of what I wrote.

What the fuck could I have meant when I wrote "the new ASCII that I 
don't remember the name of"? Could it be that I didn't remember the name 
ASCII that I mentioned in that very sentence? Yes, that must surely have 
been what I meant.

But wait, that's already clarified up-thread, in the parts you snipped: 
it was ISO 646, the international, ISO version of ASCII.

Removing significant context and introducing one's own apparent context 
instead, is not like debate or clarification.

That's instead a common trolling technique.


> However, that
> was all a long time ago, and every one of those versions included $.

Yes, and as you well know that's irrelevant to anything in this thread.

Perhaps there were reasons that caused you to not see as relevant the 
stuff that you snipped, but a debate or clarification can't be your goal 
because you can't be unaware of the facts: you're presenting some.

The stuff that you snipped included reference to ISO 646, the 
international version of ASCII, which from (apparently) 1972 to 
(verified) 1991 had the `$` replaced with an unusable international 
currency symbol `¤`.


> What you're referring to is an early version of ISO/IEC 646, which was
> based on ASCII and was ASCII's successor, but is not, itself, ASCII.

Yes, and again, as you well know that's irrelevant to anything.

Not sure if I should plink you, you're not usually trolling this way,

- Alf

[toc] | [prev] | [next] | [standalone]

#67874

On 8/22/19 1:54 AM, Alf P. Steinbach wrote:
> On 22.08.2019 06:26, James Kuyper wrote:
>> On 8/22/19 12:01 AM, Alf P. Steinbach wrote:
>>> On 22.08.2019 04:24, Keith Thompson wrote:
>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>> ...
>>>>> For the new ASCII that I don't remember the name of, we got the (hark)
>>>>> universal currency symbol `¤` as a replacement for `$`. Nobody uses
>>>>> that. It's meaningless except as a political statement, but it's there
>>>>> on my keyboard, taking up one key combination.
>>>>
>>>> There is no "new ASCII".
>>>
>>> I'm sorry, that's just wrong, although that statement is literally true
>>> by using the word "is" instead of "never was".
>>
>> ASCII was first standardized as ASA X3.4-1963, and was revised in 1965,
>> 1967, 1968, 1977, and 6 different versions came out in 1986
>> <https://en.wikipedia.org/wiki/ASCII#History>. So you're right - there
>> has been a "new ASCII" - a total of 10 of them, in fact.
> 
> You're talking about the US national variant of ISO-646.

No, ASCII and ISO-646 have been developed cooperatively, and there is a
US national variant of ISO-646 that is identical in content to one of
the versions of ASCII, but that doesn't make ASCII a national variant of
ISO-646.

> That's a meaningless interpretation of what I wrote.
> 
> What the fuck could I have meant when I wrote "the new ASCII that I 
> don't remember the name of"? Could it be that I didn't remember the name 
> ASCII that I mentioned in that very sentence?

No, each version of ASCII had it's own name, such as
ASA X3/4-1963 and ANSI-INCITS 4-1986. It was quite clear, since you
describe it as having replaced the dollar sign with the currency symbol,
that the only thing you could have been referring to was ISO 646 IRV.
However, given your usual sloppiness of thought, I assumed that you
actually meant what you said - that you were under the impression that
ISO 646 IRV was the name of a "... new [version of] ASCII ..." but that
you couldn't remember the name of that particular version.

I'm glad to hear that this was only sloppy wording on your part, and
that you're actually aware that it's a different standard, issued by an
international standards organization, rather than a merely national one.

[toc] | [prev] | [next] | [standalone]

#67882

On 22.08.2019 15:08, James Kuyper wrote:
> On 8/22/19 1:54 AM, Alf P. Steinbach wrote:
>> On 22.08.2019 06:26, James Kuyper wrote:
>>> On 8/22/19 12:01 AM, Alf P. Steinbach wrote:
>>>> On 22.08.2019 04:24, Keith Thompson wrote:
>>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>> ...
>>>>>> For the new ASCII that I don't remember the name of, we got the (hark)
>>>>>> universal currency symbol `¤` as a replacement for `$`. Nobody uses
>>>>>> that. It's meaningless except as a political statement, but it's there
>>>>>> on my keyboard, taking up one key combination.
>>>>>
>>>>> There is no "new ASCII".
>>>>
>>>> I'm sorry, that's just wrong, although that statement is literally true
>>>> by using the word "is" instead of "never was".
>>>
>>> ASCII was first standardized as ASA X3.4-1963, and was revised in 1965,
>>> 1967, 1968, 1977, and 6 different versions came out in 1986
>>> <https://en.wikipedia.org/wiki/ASCII#History>. So you're right - there
>>> has been a "new ASCII" - a total of 10 of them, in fact.
>>
>> You're talking about the US national variant of ISO-646.
> 
> No, ASCII and ISO-646 have been developed cooperatively, and there is a
> US national variant of ISO-646 that is identical in content to one of
> the versions of ASCII, but that doesn't make ASCII a national variant of
> ISO-646.
> 
>> That's a meaningless interpretation of what I wrote.
>>
>> What the fuck could I have meant when I wrote "the new ASCII that I
>> don't remember the name of"? Could it be that I didn't remember the name
>> ASCII that I mentioned in that very sentence?
> 
> No, each version of ASCII had it's own name, such as
> ASA X3/4-1963 and ANSI-INCITS 4-1986.

"It's" is spelled "its".

That's pretty sloppy spelling from you.


> [snip]
> However, given your usual sloppiness of thought,

You don't say.


> I assumed that you
> actually meant what you said - that you were under the impression that
> ISO 646 IRV was the name of a "... new [version of] ASCII ..." but that
> you couldn't remember the name of that particular version.

That explanation does not address the precision of snipping all mention 
of ISO 646 in the text your replied to, which appeared to be designed to 
mislead.

Not addressing your snipping of significant context is a sloppiness of 
deception, an art that you don't quite master.


> I'm glad to hear that this was only sloppy wording on your part,

And that's associative, like an associative mind. It's true that the 
wording was intentionally imprecise. It communicated exactly what I 
meant to say, notwithstanding your unconvincing attempt to put it in a 
different context, remove all mention of what it meant, and so on.


> and
> that you're actually aware that it's a different standard, issued by an
> international standards organization, rather than a merely national one.

You didn't learn that now.

You snipped those parts of the quoted text, remember.

To do that snipping you had to recognize what it was about, which you 
now pretend to have understood, which means you are now conveying an 
incorrect impression that you /know/ is incorrect, which there is a word 
for.


Cheers!,

- Alf

[toc] | [prev] | [next] | [standalone]

#67875

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>On 21.08.2019 21:41, Keith Thompson wrote:
>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:

>>> For example, I remember `$` being used in the system API in the HP3000.
>>> That's long ago, 1980s, but presumably use of `$` in system API function
>>> names was part of the reasons why compilers supported it. And continue
>>> to support it.
>> 
>> OpenVMS uses $ in identifiers (and C and C++ compilers for OpenVMS have
>> to allow for that).  Which is why, in my opinion, the standard *should*
>> allow compilers to accept $ in identifiers.
>> 
>> [...]
>
>Yes, I should have written MPE/IV, the OS we used on the HP3000. Sorry.

Which HP3000 language allowed '$' in identifiers?   On most HP3000
compilers the $ was used in column 1 to introduce compiler control
commands, for example in SPL/3000:

$TITLE "SON OF OVERLORD (SOO)"
$CONTROL USLINIT,NOWARN,MAP,CODE
$CONTROL SEGMENT=SOO
BEGIN ...

SPL did allow apostrophes in identifiers:

  INTEGER PRIORITY, XDS'SUB, MAXPCB', MODE;

The engineers that designed the HP3000 were mostly ex-burroughs
engineers, which is where the use of $ as a compiler control
originated.

>
>It's possible that all this is tied to the attempt to remove `$` in 
>ASCII, as I recall instigated by Russia or France, a political thing.

C'est what?

> I 
>mean, tied by the baffling decision to not include `$` in the C++ basic 
>execution character set.

Maybe because the '$' symbol was often substited with a national
symbol (e.g. the british pound symbol); it wasn't a fixed glyph
worldwide.

[toc] | [prev] | [next] | [standalone]

#67876

On 22/08/2019 15:17, Scott Lurndal wrote:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>> On 21.08.2019 21:41, Keith Thompson wrote:
>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> 
>>>> For example, I remember `$` being used in the system API in the HP3000.
>>>> That's long ago, 1980s, but presumably use of `$` in system API function
>>>> names was part of the reasons why compilers supported it. And continue
>>>> to support it.
>>>
>>> OpenVMS uses $ in identifiers (and C and C++ compilers for OpenVMS have
>>> to allow for that).  Which is why, in my opinion, the standard *should*
>>> allow compilers to accept $ in identifiers.
>>>
>>> [...]
>>
>> Yes, I should have written MPE/IV, the OS we used on the HP3000. Sorry.
> 
> Which HP3000 language allowed '$' in identifiers?   On most HP3000
> compilers the $ was used in column 1 to introduce compiler control
> commands, for example in SPL/3000:
> 
> $TITLE "SON OF OVERLORD (SOO)"
> $CONTROL USLINIT,NOWARN,MAP,CODE
> $CONTROL SEGMENT=SOO
> BEGIN ...
> 
> SPL did allow apostrophes in identifiers:
> 
>   INTEGER PRIORITY, XDS'SUB, MAXPCB', MODE;
> 
> The engineers that designed the HP3000 were mostly ex-burroughs
> engineers, which is where the use of $ as a compiler control
> originated.
> 
>>
>> It's possible that all this is tied to the attempt to remove `$` in 
>> ASCII, as I recall instigated by Russia or France, a political thing.
> 
> C'est what?
> 
>> I 
>> mean, tied by the baffling decision to not include `$` in the C++ basic 
>> execution character set.
> 
> Maybe because the '$' symbol was often substited with a national
> symbol (e.g. the british pound symbol); it wasn't a fixed glyph
> worldwide.
> 

It was the # symbol that was replaced by £ in the GB version of ISO-646,
and on British keyboards.  The $ sign remained.  (Also ~ was replaced by
an overbar ‾, but I've no idea why.)

The $ symbol was kept in most, but not all, ISO-646 character sets.  It
was more common to replace characters like # { } [ ] | and ~ , all of
which are still there in C (but have trigraphs).

On a related topic, what is the rationale behind the choice of
characters allowed in universal character identifiers?  There seems to
be a vague attempt to allow "letters" but not "symbols".  Surely
allowing symbols like ¤ £ and § would be ideal for the kind of thing Alf
has in his library - characters that would not conflict with anything
else, stand out clearly, and can by typed easily on many keyboard
layouts (even with Windows).

Perhaps € would be a good choice - it is in the list of allowed Unicode
identifier characters.

[toc] | [prev] | [next] | [standalone]

#67840

David Brown <david.brown@hesbynett.no> writes:
> On 20/08/2019 23:59, Keith Thompson wrote:
[...]
> I wonder if the change in C++17 was with a view to future uses of $ for
> other purposes in C++ (such as for metaclasses)?  Has the status here
> changed in C++20 ?

I doubt it.  The DR that led to the "other implementation-defined
characters" wording being dropped
    http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1963
doesn't specifically mention the '$' character.  (It could apply equally
to '`' and '@', the other two printable ASCII characters that are
outside the basic source character set).  It was removed because it was
thought that it wasn't needed.

As for C++20, there's a git repo for the C++ standard at
    https://github.com/cplusplus/draft
The "other implementation-defined characters" wording was dropped in
commit fcde0c485c4, 2015-05-03, file source/lex.tex .  There are no
changes to the syntax of "identifier" after that.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#67807

For the past 15 years or so, I've been using "Dependency Walker" for this on MS-Windows and it works great.

[toc] | [prev] | [next] | [standalone]

#67830

On 8/20/2019 4:09 AM, Frederick Gotham wrote:
> 
> For the past 15 years or so, I've been using "Dependency Walker" for this on MS-Windows and it works great.
> 

Big time. Iirc, it was bundled up with Visual Studio a long time ago.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web