Saturday, December 28, 2019

Digest for comp.lang.c++@googlegroups.com - 25 updates in 7 topics

boltar@nowhere.org: Dec 28 12:05PM

On Fri, 27 Dec 2019 09:41:26 -0800 (PST)
 
>Then what exactly is your point? Are you suggesting that
>std::vector<std::optional<T>> is inferior to some other way of storing a
>collection of optional values? What other way are you thinking of?
 
I give up , its like talking to geese sometimes.
boltar@nowhere.org: Dec 28 12:06PM

On Fri, 27 Dec 2019 09:58:46 -0800 (PST)
>to help them and to warn about such things. So all arrays were
>definitely possible to allocate once if not to make with static
>compile-time known size.
 
Oh right, so now you want fixed sized arrays beforehand. Good idea, in fact
in that case why bother with containers or C++ at all, lets just use a good
old fashioned C style automatic array! That'll work for all situations I have
no doubt.
red floyd <no.spam@its.invalid>: Dec 27 03:35PM -0800

On 12/27/19 1:35 AM, Bonita Montero wrote:
>> Please ask your question in a Windows group, rather than here.
 
> When Qt-questions are appropriate here, this is also o.k..
> Hrhr. ;-)
 
Qt is also off topic. Please read the FAQ.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 28 07:26AM +0100


>> When Qt-questions are appropriate here, this is also o.k..
>> Hrhr. ;-)
 
> Qt is also off topic.  Please read the FAQ.
 
I've never seen complaints against Qt-questions.
And I've also never seen a FAQ.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 28 07:42AM +0100

On 28.12.2019 07:26, Bonita Montero wrote:
 
> [snip]
> And I've also never seen a FAQ.
 
The C++ FAQ now resides at
 
<url: https://isocpp.org/faq>
 
It's no longer specific to this group: the clc++-specific material has
been edited out of Marshall Cline's original FAQ.
 
That material is however still present in Dietmar Kuehl's mirror (and
other mirrors, there were a host of them once) of the original FAQ, at
 
<url: http://www.dietmar-kuehl.de/mirror/c++-faq/>
 
 
- Alf
Bonita Montero <Bonita.Montero@gmail.com>: Dec 28 07:45AM +0100

> That material is however still present in Dietmar Kuehl's mirror (and
> other mirrors, there were a host of them once) of the original FAQ, at
> <url: http://www.dietmar-kuehl.de/mirror/c++-faq/>
 
A FAQ that is valid for a newsgroup is regulary posted on this.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 28 07:59AM +0100

On 28.12.2019 07:45, Bonita Montero wrote:
>> other mirrors, there were a host of them once) of the original FAQ, at
>> <url: http://www.dietmar-kuehl.de/mirror/c++-faq/>
 
> A FAQ that is valid for a newsgroup is regulary posted on this.
 
It used to be posted, by Marshall.
 
Unfortunately he is now old and I would guess, not in best of health. He
essentially passed the FAQ maintenance over to Herb, Bjarne and Andrei.
And they removed the clc++-specific stuff and don't post the FAQ.
 
Dietmar Kuehls mirror of the original FAQ is the closest to a FAQ for
the group, because it was the FAQ for the group. Unlike many other
Usenet groups there was never a /charter/ for clc++, but re the original
discussion up-thread about Qt and Windows it's perhaps relevant that the
now defunct moderated sister group clc++m was created due to a too large
influx of Windows-specific postings in clc++, so that a group for more
pure C++ was needed -- a high s/n ratio is strongly desired. Alas, like
the FAQ postings, the group charter infrastructure has just ceased
functioning so the group will never get an official charter.
 
- Alf
Paavo Helde <myfirstname@osa.pri.ee>: Dec 28 11:39AM +0200

On 27.12.2019 23:31, T wrote:
> REGSAM samDesired,
> PHKEY phkResult
> );
 
The Win32 API is defined in C, but the same declaration can be used in
C++. So this declaration should actually be labelled "C and C++", but MS
has helpfully simplified it to "C++", for more user friendliness no doubt.
 
Note it's called "C++" not as opposed to "C", but as opposed to "Visual
Basic" and "C#".
 
> about 5 times more helpful with me configuring the
> proper data structures for Raku's NativeCall. Didn't
> think you guys were that smart, did you!
 
As the Win32 API is defined in C, I believe you cannot use it easily or
reliably from other languages without learning at least a bit of C
first. Especially regarding the pointers. Most parameters in the above
declaration are disguised pointers.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 28 12:10PM +0100

On 28.12.2019 10:39, Paavo Helde wrote:
> reliably from other languages without learning at least a bit of C
> first. Especially regarding the pointers. Most parameters in the above
> declaration are disguised pointers.
 
A (very) small part of the API is written for use in scripting
languages. E.g. there's a dictionary, a text file class, and a scripting
language interface to the Windows File Explorer. And I believe the only
message box with a timeout offered by the API, resides in this part.
 
Also this part is no doubt defined in C, but the abstraction level
presented in the documentation is as a set of OLE Automation classes.
 
OLE Automation classes are easily consumed from scripting languages with
Windows bindings, and they can be (rather laboriously) defined in C. So
that's an example where C code can be easily consumed at the scripting
level, although this is C code especially crafted for the purpose.
Another and more portable example is the Python C interface, which can
consume most any C code whatsoever.
 
- Alf
Bonita Montero <Bonita.Montero@gmail.com>: Dec 28 12:48PM +0100

> As the Win32 API is defined in C, ...
 
There are a lot of IDispatch COM-APIs which can be easily used
in a scripting-language.
Bart <bc@freeuk.com>: Dec 28 01:46AM

On 27/12/2019 21:55, T wrote:
 
>> - Alf
 
> Since Kernel32.dll uses 32 bit words as pointers, a 32 bit
> word will all zero's it is.  Thank you!
 
It will be 32 bits on Win32 and 64 bits on Win64. How those 32 or 64
bits are passed also depends on the system ABI.
 
At what level are you coding, assembly? In a well-supported HLL and
using all the myriad headers that are provided, you don't normally need
to worry about that.
 
(I do because I have to use WinAPI from home-made languages and don't
use the system ABI, but most people don't.)
James Kuyper <jameskuyper@alumni.caltech.edu>: Dec 27 08:50PM -0500

On 12/27/19 4:36 PM, Ian Collins wrote:
 
> The C standard defines a null pointer as
 
> "An integer constant expression with the value 0, or such an expression
> cast to type void *, is called a null pointer constant."
 
That's the definition of a "null pointer constant". The definition of a
null pointer comes on the immediately following line:
 
"If a null pointer constant is converted to a pointer type, the
resulting pointer, called a _null pointer_, is guaranteed to compare
unequal to a pointer to any object or function."
Note that the second occurrence of the phrase "null pointer" in that
sentence is in italics, an ISO convention indicating that this sentence
constitutes the official definition of the italicized phrase. In this
case, it's a little unclear; the first part of that sentence is not
actually the definition, it's a one of several ways to obtain a null
pointer (other ways include calling various standard library functions
that are documented as returning null pointers under certain
circumstances). It's actually the end of that sentence that defines what
null pointer is: a pointer guaranteed to compare unequal to a pointer to
any object or function.
 
The C standard says nothing about how null pointers are represented. A
null pointer of type T* has a size in bytes equal to sizeof(T*), a
number that is implementation-defined, not standard-defined. It is
commonplace for null pointers to have all bits 0, but that's not
guaranteed, and there have been a fair number of real-world
implementations that have used other representations. At least one
popular system I've used had a segment-offset structure for addresses,
and any pointer with an offset of 0 was defined by that implementation
to be a null pointer, regardless of what the segment portion of the
address was.
 
Finally, note that the OP asked about NULL. NULL is the name of a macro,
#defined in several standard headers, which is required to expand into a
null pointer constant. There's a huge variety of other ways to write a
null pointer constant, so you shouldn't confuse "NULL" with "null
pointer constant". While any null pointer constant (and therefore, in
particular, NULL) will be converted into a null pointer if used in a
context where it will be converted to a pointer type, it's also
important to understand that null pointer constants are not the same
thing as null pointers.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Dec 28 02:14AM -0800

> and it wants a NULL for one or more of its parameters,
> what exactly is the structure of a NULL? A 32 bit
> word full of zeros?
 
You might get better answers if you explained why you want to know.
 
If you're making a call from C++, you can just pass a null pointer
value such as nullptr or NULL. The compiler needs to know how
it's represented. You probably don't.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Bo Persson <bo@bo-persson.se>: Dec 28 11:28AM +0100

On 2019-12-27 at 22:55, T wrote:
>> expression cast to type void *, is called a null pointer constant."
 
> Since Kernel32.dll uses 32 bit words as pointers, a 32 bit
> word will all zero's it is.  Thank you!
 
Please note that, historically, the "32" was added to indicate that it
is no longer a 16-bit Windows (like Windows 1, 2, and 3 was).
 
When moving from 32 to 64 bits, the names were *not* changed. :-)
 
So, the suffix 32 just means "not 16".
 
 
Bo Persson
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 27 11:52PM -0800

On 12/24/2019 5:30 PM, Bonita Montero wrote:
 
>> https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf
>> Section 3.7.3, Hardware Prefetching for Second-Level Cache.
 
> Alignment of prefetches is a totally different topic.
 
Imvvho, it can present an insight into deeper levels of the cache
architecture.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 28 08:54AM +0100


>> Alignment of prefetches is a totally different topic.
 
> Imvvho, it can present an insight into deeper levels of the cache
> architecture.
 
This has nothing to do with false or true sharing if the higher level
cache with a larger line-size is shared.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 27 11:57PM -0800

On 12/27/2019 11:54 PM, Bonita Montero wrote:
>> architecture.
 
> This has nothing to do with false or true sharing if the higher level
> cache with a larger line-size is shared.
 
It did with earlier models.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 27 11:59PM -0800

On 12/27/2019 11:57 PM, Chris M. Thomasson wrote:
 
>> This has nothing to do with false or true sharing if the higher level
>> cache with a larger line-size is shared.
 
> It did with earlier models.
 
The split 128... Best to keep things padded and properly aligned on
boundaries. The two halfs are interesting.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 28 09:53AM +0100

>> It did with earlier models.
 
> The split 128... Best to keep things padded and properly aligned on
> boundaries. The two halfs are interesting.
 
That was only relevant to MP P4-Xeons but not to the P4 desktop-CPUs.
On the latter all threads shared a single L2-cache.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 28 12:30AM -0800

On 12/18/2019 10:19 PM, Mr Flibble wrote:
 
>> vec4 v4 = vec4(v3.xyz, 1.0);
 
>> v4 now equals { v3.x, v3.y, v3.z, 1.0 }
 
> That is the goal, yes.
 
Looking forward to using C++ with swizzles, using your work, to render
something like the following experiment of mine:
 
https://youtu.be/TLd64a4gdZQ
Mr Flibble <flibble@i42.removethisbit.co.uk>: Dec 28 12:42AM

On 27/12/2019 19:05, Alf P. Steinbach wrote:
 
> Why do you prefer to repeat a bit of text ad nauseam? It's more to
> write, more to read, recommended against by a number of generally
> accepted guidelines like DRY, and just plain freaking dumb. So, why?
 
Taking your really bad analogy of DRY to its logical conclusion you can
only use a vector once in your entire program so you don't fucking
repeat yourself. Bad analogies are "just plain freaking dumb".
 
/Flibble
 
--
"You won't burn in hell. But be nice anyway." – Ricky Gervais
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens."
– Ricky Gervais
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 28 07:37AM +0100

On 28.12.2019 01:42, Mr Flibble wrote:
 
> Taking your really bad analogy of DRY to its logical conclusion you can
> only use a vector once in your entire program so you don't fucking
> repeat yourself.  Bad analogies are "just plain freaking dumb".
 
I can agree with the last sentence.
 
Regarding the rest, consider:
 
 
#include <array>
 
void leigh()
{
const int board_size = 8;
std::array<std::array<int, board_size>, board_size> board =
{
std::array<int, board_size>{}, std::array<int, board_size>{},
std::array<int, board_size>{}, std::array<int, board_size>{},
std::array<int, board_size>{}, std::array<int, board_size>{},
std::array<int, board_size>{}, std::array<int, board_size>{}
};
(void) board; // Whatever
}
 
void alf()
{
using std::array;
 
const int width = 8;
const int height = width;
 
using Row = array<int, width>;
using Board = array<Row, height>;
 
Board board{};
(void) board; // Whatever
}
 
 
Here the two functions manage to create a local variable called `board`,
of the exact same type in the code as by your argumentation you would
have written it, and in corresponding code by me.
 
In the assumed-like-Leigh code the `std::` qualification and the type
builder `array` is repeated ad nauseam, because you argue that even when
it's known that all textual instances are a given text it should better
be spelled out; and the focus, what's communicated to a reader, is on
the details of the data representation and not on what it models.
 
In the more DRY (Don't Repeat Yourself) Alf code the relevant namespace
`std::` is mentioned only once; the type builder `array` is mentioned
only in a `using` declaration and for the two types that it builds here,
that is, three times; and the focus, what's communicated to a reader, is
on what the structure models.
 
- Alf
red floyd <no.spam@its.invalid>: Dec 27 03:36PM -0800

On 12/27/19 1:36 PM, T wrote:
 
> Is it bitwise OR'ing the three constants?
 
> Many thanks,
> -T
 
Please take your windows question to a windows group. This group is
for discussing the C++ language as defined by ISO 14882.
T <T@invalid.invalid>: Dec 27 04:43PM -0800

On 2019-12-27 15:36, red floyd wrote:
>> -T
 
> Please take your windows question to a windows group.  This group is
> for discussing the C++ language as defined by ISO 14882.
 
Red,
 
Read my question a little more closely. That was a C++
question
 
-T
James Kuyper <jameskuyper@alumni.caltech.edu>: Dec 27 08:52PM -0500

On 12/27/19 6:36 PM, red floyd wrote:
>> -T
 
> Please take your windows question to a windows group. This group is
> for discussing the C++ language as defined by ISO 14882.
 
The meaning of "|" in that context is a C++ question, not a windows
question.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)