Friday, January 1, 2021

Digest for comp.lang.c++@googlegroups.com - 16 updates in 4 topics

Brian Wood <woodbrian77@gmail.com>: Jan 01 03:05PM -0800

On Sunday, September 27, 2020 at 9:57:50 AM UTC-5, Öö Tiib wrote:
> Case closed.
 
> What about other remarks of Alf? Let me restore:
> * The need for an account number in invocations. Huh.
 
I took his advice and made my ReadMe a markdown file.
I don't know what to say to "Huh". Accounts are common.
Someone may say that Compiler Explorer doesn't have
accounts. My guess is they will probably add them before
long. When I started, I had a web service and didn't require
accounts. After a few years of that someone on a Boost
list, suggested having a command line interface. That
made sense and when I changed to that approach I added
support for accounts. It would be nice to be able to
maintain both a CLI and a web interface, but I decided not
to attempt that. I think the CLI is more important.
 
> * No link to example.
 
I added that now. Thanks.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 01 09:59AM

On Thu, 2020-12-31, TDH1978 wrote:
> *a++ = 0;
> *a = 0;
> }
 
As an aside, a std::array<uint8_t, 6> would be a better choice for a
MAC address. If some API wants a C array, it's easy to write a
conversion function.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
spudisnotyourbuddy@grumpysods.com: Jan 01 10:33AM

On 1 Jan 2021 09:59:38 GMT
>> *a = 0;
>> }
 
>As an aside, a std::array<uint8_t, 6> would be a better choice for a
 
Why? A MAC is a fixed size which will never change. A C array is efficient and
does the job.
Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Jan 01 12:10PM +0100

>> As an aside, a std::array<uint8_t, 6> would be a better choice for a
 
> Why? A MAC is a fixed size which will never change. A C array is efficient and
> does the job.
 
std::array is fixed size, too, but provides strict type safety, provides
bounds checking and allows the use of the standard algorithms library.
 
The classic C syntax can not safely distinguish between an actual array
and a bare pointer, which might not point to an array of the appropriate
size in some special case missed by the developer.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 01 02:19PM +0100

On 01.01.2021 12:10, Hergen Lehmann wrote:
>> does the job.
 
> std::array is fixed size, too, but provides strict type safety, provides
> bounds checking and allows the use of the standard algorithms library.
 
The standard algorithms work nicely with raw arrays. `std::end(a)` gives
you an end iterator for the array whether `a` is `std::array` or a raw
array. But when `a` is a pointer one must usually calculate an end
pointer like `a+n`, which means that `std::array` is more /practical/.
 
 
> The classic C syntax can not safely distinguish between an actual array
> and a bare pointer, which might not point to an array of the appropriate
> size in some special case missed by the developer.
 
Additionally, `std::array` can be easily returned from a function.
 
- Alf
David Brown <david.brown@hesbynett.no>: Jan 01 02:46PM +0100

On 01/01/2021 12:10, Hergen Lehmann wrote:
 
> The classic C syntax can not safely distinguish between an actual array
> and a bare pointer, which might not point to an array of the appropriate
> size in some special case missed by the developer.
 
An alternative for C is to put the array in a struct:
 
typedef struct {
uint8_t d[6];
} mac_address_t;
 
That is better than using a std::array in C++, because it gives a name
to the type - and functions dealing with mac addresses can be restricted
to taking only mac address types. Putting the array into the struct
makes it a fixed size and type-safe.
 
(Of course, for C++ you would make it a class, and put a std::array in
the class instead of a C array.)
spudisnotyourbuddy@grumpysods.com: Jan 01 04:18PM

On Fri, 1 Jan 2021 12:10:31 +0100
>> does the job.
 
>std::array is fixed size, too, but provides strict type safety, provides
>bounds checking and allows the use of the standard algorithms library.
 
If a piece of code is checking MAC addresses its probably very low level
and could be in a tight loop where performance matters. Constantly doing
bounds checking on a fixed size array in this situation is a waste of
CPU cycles and needlessly slows the program down.
 
>The classic C syntax can not safely distinguish between an actual array
>and a bare pointer, which might not point to an array of the appropriate
>size in some special case missed by the developer.
 
I doubt it would need to. I can't imagine you'd pass a MAC address to a
function that takes a generic pointer as input. It needs special attention.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 01 05:24PM

On Fri, 1 Jan 2021 14:46:23 +0100
> (Of course, for C++ you would make it a class, and put a std::array in
> the class instead of a C array.)
 
Or in C++ you could enforce the size as part of the type by preventing
array to pointer decay:
 
void clear_mac(uint8_t (&a)[6]);
Bonita Montero <Bonita.Montero@gmail.com>: Jan 01 07:12PM +0100

> and could be in a tight loop where performance matters. Constantly doing
> bounds checking on a fixed size array in this situation is a waste of
> CPU cycles and needlessly slows the program down.
 
I think he has in mind the iterator-debugging facility when you arm
them with the proper #defines.
Ian Collins <ian-news@hotmail.com>: Jan 02 08:21AM +1300

> and could be in a tight loop where performance matters. Constantly doing
> bounds checking on a fixed size array in this situation is a waste of
> CPU cycles and needlessly slows the program down.
 
std::array is no less efficient in this situation. The bounds checking
is a compile time operation.
 
--
Ian.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 01 08:35PM +0100

>> CPU cycles and needlessly slows the program down.
 
> std::array is no less efficient in this situation.
> The bounds checking is a compile time operation.
 
Bounds-checking can be compile-time only if the index is a constant.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 01 09:06PM


> Or in C++ you could enforce the size as part of the type by preventing
> array to pointer decay:
 
> void clear_mac(uint8_t (&a)[6]);
 
For the record, you can so something very similar in C:
 
void clear_mac(uint8_t (*a)[6])
{
memset(a, 0, sizeof *a);
}
 
--
Ben.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 01 10:45AM -0500

Happy 2021 to everyone. 2020 brought much drama and stress. May 2021
bring peace.
 
<3 :) <((><
:) <3 <((><
 
-----
[Jesus Loves You]
 
I've reading back through the book of Exodus these past days, after
having begun again through Genesis before that. I noted a few things
this morning:
 
It was in the ancient Hebrew calendar month of Abib that Moses, led by
God, led the people out of Egypt, and the Egyptians were destroyed in
the Red Sea (Exodus 13:4).
 
The Red Sea has been likened to the blood of Christ, and that through
the Red Sea we gain salvation from our enemies, and witness their
destruction. The red blood, the read sea. The red sea closing back up
on the Egyptians who were bent on destroying the children of Israel
(Exodus 14:27-28).
 
It's the month of Abib I found interesting.
 
On our modern calendar, the month of Abib in 2021 would be the
March-April time frame, and modern / current month of Nisan. It is
indicated in scripture that the children of Israel were to observe the
first Passover, which was in this month beginning on the 14th day, and
proceeding seven days through to the 21st.
 
On that night, at midnight, the Lord sent His angel through to kill all
the firstborn in Egypt, and it was after this that Pharaoh let the
children of Israel go. Pharaoh summoned Moses by night (Exodus 12:31)
and instructed them to leave! To get out! So the Exodus would've begun
on the 22nd.
 
The ancient month of Abib, current month of Nisan, occurs in 2021 in
March through April. Passover begins on March 28, and the last day of
Passover is April 4.
 
Given all that's happening in our world, given the age of Israel (since
May 14, 1948), given the coming seven-year great tribulation, given that
Israel's government is in limbo, given the pronouncement in December
that the U.S. military and intelligence agencies have a maximum of 180
days to hand over everything they know about aliens, given the fact that
our election is in dispute (and our presidency may go into limbo for a
time before the courts and Congress and whatever other issues there are
resolve it as President Trump believes solidly the election was stolen
by fraud and evil forces at work against truth), and given the fact it
will take some time between the Rapture and the start of the seven-year
tribulation ... it's looking like there is a definite season of the
Rapture coming up.
 
No one knows the day or hour, and this season may not be the correct
one. How many people have predicted dates that have come and gone?
Still, we are commanded to be watchmen, to keep our eyes peeled, to
always be looking for the season, which Jesus said we would know.
 
Once again many signs aligning. This trek out of Egypt occurring at
this time of the year, aligning with world events today, is interesting.
It piques the curiosity and brings some resolution and focus online.
 
-----
Peace to each of you in 2021. The time to come to Jesus is now.
Whether the rapture comes or not, none of us are promised tomorrow.
Today is the day of our salvation. Ask Jesus to forgive your sin, and
enter in to eternal life today, right now even.
 
Peace.
 
--
Rick C. Hodgin
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Jan 01 03:47PM

On 01/01/2021 15:45, Rick C. Hodgin wrote:
[snip - tl;dr]
 
And Satan invented fossils, yes?
 
/Flibble
 
--
😎
Thomas Koenig <tkoenig@netcologne.de>: Jan 01 04:01PM


> And Satan invented fossils, yes?
 
According to some, he invented fossil fuels, at least.
olcott <NoOne@NoWhere.com>: Jan 01 09:40AM -0600

On 1/1/2021 5:01 AM, André G. Isaak wrote:
> that it always returns a value. That means that it must be constructed
> in such a way that it is not possible for it to get stuck in an infinite
> loop or in infinite recursion.
 
Bullshit. Your dogma is logically incoherent.
 
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
return;
}
 
int main()
{
HERE goto HERE;
u32 Input_Halts = Halts((int)H_Hat, (int)H_Hat);
Output("Input_Halts = ", Input_Halts);
}
 
(1) If it is not possible for it to get stuck in an infinite loop that
rules out local halt deciding.
 
(2) If we rule out local halt deciding then when the global halt decider
aborts main() because of the infinite loop it has no where to return a
value to.
 
Your dogma is logically incoherent, therefore provably incorrect.
 
 
--
Copyright 2020 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
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)