why use static_cast ?

[Lynn McGuire]

I put the following cast into my code and one of my programmers wants me
to use static cast. Why ?
https://en.cppreference.com/w/cpp/language/static_cast

longint nfac [8];
fem::str <8> * nfac_str = (fem::str <8> *) nfac;

fem::str <8> is an 8 character object that acts like a Fortran
character*8. longint is a long long.

Thanks,
Lynn

[daniel...@gmail.com]

On Wednesday, October 19, 2022 at 10:01:35 PM UTC-4, Lynn McGuire wrote:

> I put the following cast into my code and one of my programmers wants me
> to use static cast.

I'm pretty sure static_cast would give an invalid type conversion error.

> longint nfac [8];
> fem::str <8> * nfac_str = (fem::str <8> *) nfac;
>
> fem::str <8> is an 8 character object that acts like a Fortran
> character*8. longint is a long long.
>

I think that's undefined behaviour.

Daniel

[Andrey Tarasevich]

`static_cast`? `static_cast` cannot do this. One of your programmers
probably meant `reinterpret_cast`. That would still be barely kosher
assuming the resultant type is actually an array of `[signed/unsigned]
char`.

In reality you need `std::bit_cast` here (C++20). Or the good old
`std::memcpy`.

--
Best regards,
Andrey.

[Lynn McGuire]

Why ? They are both pointers to 8 byte objects. I am just declaring
that I want to use the same address as a 8 byte character string (no
null !) or a long long integer.

Thanks,
Lynn

[Juha Nieminen]

Lynn McGuire <lynnmc...@gmail.com> wrote:
> I put the following cast into my code and one of my programmers wants me
> to use static cast. Why ?

static_cast protects you from accidentally converting between incompatible
types. (If you don't intend to convert between incompatible types, yet that
still happens, it's most certainly a bug.)

If you intentionally do want to convert between incompatible types, it's
a good idea to use reinterpret_cast instead of a C style cast. That's
because it expresses intent better (it kind of self-documents the code
saying "yes, I intend to cast between incompatible types here, it's
not an oversight or error"). It also makes it easier to find such
casts in the code.

(Also, I believe reinterpret_cast is still more restrictive than a
C style cast. I think it doesn't allow you to remove constness, which
is also a good idea even when converting between incompatible types.
Accidentally removing constness can easily change a well-defined
behavior into undefined.)

> https://en.cppreference.com/w/cpp/language/static_cast
>
> longint nfac [8];
> fem::str <8> * nfac_str = (fem::str <8> *) nfac;
>
> fem::str <8> is an 8 character object that acts like a Fortran
> character*8. longint is a long long.

Technically speaking that's UB, but I'm not aware of any modern system
it will cause problems. Well, at least if you use a proper 'alignas'
qualifier with that 'nfac'. (Since the type is long long, the alignas
might be superfluous, but it doesn't hurt.)

[Andrey Tarasevich]

On 10/19/2022 10:21 PM, Lynn McGuire wrote:
>
> Why ?  They are both pointers to 8 byte objects.  I am just declaring
> that I want to use the same address as a 8 byte character string (no
> null !) or a long long integer.
>

You can't, neither in C nor in C++. An object (lvalue) of type `T` can
only be accessed as an object (lvalue) of type `T` (with few
exceptions). This is well known as the "strict aliasing" rule.

--
Best regards,
Andrey.

[Bonita Montero]

I don't use static-cast at all. It provides some kind of child
proof lock in a a sense that you can less mistakes because you
can only convert to in a compatible type, but this never happened
to me before and normal C-style casts are readable better for me.

[Juha Nieminen]

AFAIK any value of any type can always be safely read with an (unsigned)
char pointer (as long as you remain within the limits of the type size).

If if weren't, it would be impossible to eg. create your own version
of memcmp().

[Andrey Tarasevich]

That is one of the exceptions.

--
Best regards,
Andrey.

[Paul N]

On Thursday, October 20, 2022 at 6:21:25 AM UTC+1, Lynn McGuire wrote:
> They are both pointers to 8 byte objects. I am just declaring
> that I want to use the same address as a 8 byte character string (no
> null !) or a long long integer.

Isn't that exactly what a union is for? Though if you are hoping to put in values of one type and read them out as values of the other then you would need to check that this is actually defined in your implementation.

[Ben Bacarisse]

Paul N <gw7...@aol.com> writes:

> On Thursday, October 20, 2022 at 6:21:25 AM UTC+1, Lynn McGuire wrote:
>> They are both pointers to 8 byte objects. I am just declaring
>> that I want to use the same address as a 8 byte character string (no
>> null !) or a long long integer.
>
> Isn't that exactly what a union is for?

I'd say the main purpose is to save space by storing objects of
different types in the space required by the largest. This inevitably
raises the question accessing an object in a union that was no the last
object stored in a union -- so called type punning.

This is defined /in C/, though the result is obviously not defined by
the C standard which only says that the bytes are interpreted as an
object of the type used for access.

However it's undefined in C++.

--
Ben.

[Scott Lurndal]

Young C++ programmers don't understand C, so they think
that static_cast<fem::str<8>*> is more "readable". Heh.

[Gawr Gura]

>> I put the following cast into my code and one of my programmers wants
me
>> to use static cast. Why ?
>
> static_cast protects you from accidentally converting between
incompatible
> types. (If you don't intend to convert between incompatible types, yet
that
> still happens, it's most certainly a bug.)
>
> If you intentionally do want to convert between incompatible types, it's
> a good idea to use reinterpret_cast instead of a C style cast. That's
> because it expresses intent better (it kind of self-documents the code
> saying "yes, I intend to cast between incompatible types here, it's
> not an oversight or error"). It also makes it easier to find such
> casts in the code.

This is the correct answer. The C-style cast is one cast to rule them all.
You can do things you don't intend to with it (e.g., cast away qualifiers)
and your compiler won't stop you. If you try to do the wrong thing with
static/dynamic/const/reinterpret casts you will get an error. Do what you
prefer but if you have to ask why one would use a static_cast then I think
the C++ casts are preferable.

[JiiPee]

but boost::numberi_cast is something to consider, because it checks
more... it checks if the number is valid in the conversation.

[JiiPee]

Especially dynamic_cast can help alot, because we might make human
mistakes in polymorhism.

[JiiPee]

On 20/10/2022 16:55, Scott Lurndal wrote:
> Young C++ programmers don't understand C, so they think
> that static_cast<fem::str<8>*> is more "readable". Heh.

its surely not more readable.
but dynamic_cast is surely useful checking class hierarkies.

[Scott Lurndal]

dynamic_cast provides some level of introspection, which can
be useful; albeit at a small cost (for the typeid metadata).

[daniel...@gmail.com]

On Thursday, October 20, 2022 at 1:21:25 AM UTC-4, Lynn McGuire wrote:
> On 10/19/2022 9:40 PM, daniel...@gmail.com wrote:
> > On Wednesday, October 19, 2022 at 10:01:35 PM UTC-4, Lynn McGuire wrote:
> >
> >> longint nfac [8];
> >> fem::str <8> * nfac_str = (fem::str <8> *) nfac;
> >>
> >> fem::str <8> is an 8 character object that acts like a Fortran
> >> character*8. longint is a long long.
> >>
> > I think that's undefined behaviour.
> >

> Why ? They are both pointers to 8 byte objects. I am just declaring
> that I want to use the same address as a 8 byte character string (no
> null !) or a long long integer.
>

ubsan will complain about load of misaligned address. In these cases you
need to use memcpy instead of cast and assignment.

See https://stackoverflow.com/questions/47619944/load-of-misaligned-address-and-ubsan-finding

[JiiPee]

On 20/10/2022 18:01, Scott Lurndal wrote:
> dynamic_cast provides some level of introspection, which can
> be useful; albeit at a small cost (for the typeid metadata).

sure, although about 99.9% in cases the speed is not an issue in these
object oriented programs. But sure, if speed is in essence, one should
consider not using it.

[Scott Lurndal]

JiiPee <kerrttuPo...@gmail.com> writes:
>On 20/10/2022 18:01, Scott Lurndal wrote:
>> dynamic_cast provides some level of introspection, which can
>> be useful; albeit at a small cost (for the typeid metadata).
>
>sure, although about 99.9% in cases the speed is not an issue in these
>object oriented programs.

I would argue against this viewpoint, myself.

[Andrey Tarasevich]

"Exactly what a union is for"?

It is true that unions have been used for type punning from time to
time, but this is not "what a union is for". Union is a
memory-time-sharing feature that exists for reducing memory usage. You
don't normally "put in values of one type and read them out as values of
the other". That's not exactly what union is for.

--
Best regards,
Andrey.

[Keith Thompson]

Agreed.

K&R1 (1978) introduces unions in section 6.8. It discusses holding
objects of different types at different times; it says nothing about
type punning. (The version of C discussed in the 1975 manual didn't
have unions.)

Of course programmers, being programmers, do not tend to restrict
themselves to the original intent of any feature.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[JiiPee]

On 20/10/2022 19:07, Scott Lurndal wrote:
> I would argue against this viewpoint, myself.

I mean, using static_cast is not slowing down a program in about 99.9%
of cases against not using it. Talking about the slowness of static cast
here. But of course I would not put a static cast in a tight loop
looping millions of things a second.

[Scott Lurndal]

static_cast is an annotation. It should not cause any significant
differences in the generated code. dynamic_cast, on the other
hand, will at a minimum add a lookup to the typeinfo.

[JiiPee]

On 20/10/2022 20:30, Scott Lurndal wrote:
> static_cast is an annotation. It should not cause any significant
> differences in the generated code. dynamic_cast, on the other
> hand, will at a minimum add a lookup to the typeinfo.

sorry mistake, I meant dynamic_cast. But the code I have been doing and
seen, I rarely see a place where dynamic cast would slow down
signifantly. Because many of the loops are looping something maybe
20-100 times so it does not slow down significantly there.

[Lynn McGuire]

The programmer in question is 39 and has been writing C and C++ since he
was 13 or 14.

His actual comment was that static_cast's are easier to grep which I
find hard to believe.

Thanks,
Lynn

[Lynn McGuire]

On 10/19/2022 9:01 PM, Lynn McGuire wrote:
> I put the following cast into my code and one of my programmers wants me
> to use static cast.  Why ?
>    https://en.cppreference.com/w/cpp/language/static_cast
>
>    longint nfac [8];
>    fem::str <8> * nfac_str = (fem::str <8> *) nfac;
>
> fem::str <8> is an 8 character object that acts like a Fortran
> character*8.  longint is a long long.
>

> Thanks,
> Lynn

Thanks to all for the views ! They were good.

Lynn

[Manfred]

If by grep you mean grep(1), then yes, static_cast is definitely easier
to grep than a C-style cast.
However, the advantage of reinterpret_cast (static_cast wouldn't work)
is not that it is more readable. It is that it hurts the eye.

Depending on which compiler you use, I'd verify that what you intend to
do actually works. As far as the standard is concerned, at least one
necessary condition is that fem::str<8> is effectively an unsigned char[8].
Otherwise it's UB unless your compiler says otherwise (although it
probably Just Works on any of them, in practice.)

>
> Thanks,
> Lynn

[Bonita Montero]

Am 20.10.2022 um 17:32 schrieb JiiPee:

> sure, although about 99.9% in cases the speed is not an issue in these
> object oriented programs. But sure, if speed is in essence, one should
> consider not using it.

That's nonsense. OOP doesn't cost more than procedural programming since
with the latter you have context like this also. Virtual functions have
some slight overhead but it is very small.

[Bonita Montero]

A virtual function that gives some type-capabiliy information
is usually much faster.

[Lynn McGuire]

I am using Visual Studio 2015 on Windows 10 Pro x64.

fem::str<8> is an array of unsigned char [8] that I pass around the
place to hold a Fortran string of given length that is blank filled
rather than null terminated.
https://cci.lbl.gov/fable/sources/fable/fem/str.hpp

And yes, I will be able to tell rather quickly if the cast is working
properly or not. I am minimizing usage though as I prefer char * and
std::string.

Thanks,
Lynn

[Lynn McGuire]

I am always concerned about speed. My calculation engine needs to have
responses in seconds if needful for large online rotating equipment up
to 55,000 hp in size.

My other case is the endless recycle calculations of refinery or large
natural gas plants that can go 20 or 30 minute on a modern 4 Ghz cpu.

When we finish our C++ port then we will be looking at selected speedups
using limited parallelization and memset.

Lynn

[JiiPee]

On 21/10/2022 22:05, Lynn McGuire wrote:
>> I mean, using static_cast is not slowing down a program in about
>> 99.9% of cases against not using it. Talking about the slowness of
>> static cast here. But of course I would not put a static cast in a
>> tight loop looping millions of things a second.
>
> I am always concerned about speed.

IN my coding, also professional, very rarely this kind of thing would
slow down essentially. I have very rarely time critical situations.

[JiiPee]

On 21/10/2022 22:05, Lynn McGuire wrote:

> I am always concerned about speed.

Me also if needed. But... for example in a user interface programming
speed it not important. I mean, when opening a dialog box takes 0.0001
seconds or 0.0002 seconds makes no difference :). And I am mostly doing
this kind of programming, when small things are processed.

[Bo Persson]

If it is always 8 bytes, I would use memcpy between two buffers and skip
the pointer indirection.

The memcpy based implementation of C++20 bit_cast, as shown here

https://en.cppreference.com/w/cpp/numeric/bit_cast

is known to inline and optimize into

mov rax, From

for 64-bit values on common 64-bit compilers.

[Lynn McGuire]

I am porting a 700,000 line Fortran 77 + 50,000 line C++ engineering
software application to pure C++. I am trying to not lose any speed in
the process.

Thanks,
Lynn

[Lynn McGuire]

Nope, that is a lot of extra work for the thousands of places that this
interaction occurs.

Thanks,
Lynn

[Lynn McGuire]

On 10/22/2022 11:31 AM, Bo Persson wrote:

But, I will keep it in mind for the future.

Our memory sharing technology was developed back in the late 1970s when
we were having severe memory problems on the mainframes. Over the
years, we used it all over the place. We create 300 to 20,000 (depends
on size of the simulation) memory blocks that we use all over the place
for each software run.

Thanks,
Lynn

[Mut...@dastardlyhq.com]

700K lines?? Unless you have some autotranslation tool you'll reach retirement
age long before you've finished so the speed will be someone elses problem.

[JiiPee]

On 23/10/2022 10:35, Mut...@dastardlyhq.com wrote:
> speed will be someone elses problem.

Yes, optimization is not always the first thing to do. although surely
good to keep in mind when developing that makes it easy to change later
on faster.

[Manfred]

On 10/22/2022 10:03 PM, Lynn McGuire wrote:
> On 10/22/2022 12:47 AM, JiiPee wrote:
>> On 21/10/2022 22:05, Lynn McGuire wrote:
>>> I am always concerned about speed.
>>
>> Me also if needed. But... for example in a user interface programming
>> speed it not important. I mean, when opening a dialog box takes 0.0001
>> seconds or 0.0002 seconds makes no difference :). And I am mostly
>> doing this kind of programming, when small things are processed.
>
> I am porting a 700,000 line Fortran 77 + 50,000 line C++ engineering
> software application to pure C++.

This sounds even more as a reason to get to very stable C++ in the
process. I'd not want to have any chance of obscure UB hidden deeply in
the result code.

Which begs the question from the original post:

> longint nfac [8];
> fem::str <8> * nfac_str = (fem::str <8> *) nfac;
>
> fem::str <8> is an 8 character object that acts like a Fortran character*8. longint is a long long.

Is the cast to/from 8 char string and long long really the best you want
here?
Unless I am missing something, if you want e.g. to compare those
strings, I'd expect that in any decent implementation memcmp is
optimized just fine.

  I am trying to not lose any speed in
> the process.

Sure, but correctness always comes first.

>
> Thanks,
> Lynn

[Lynn McGuire]

I am using a very customized version of the good old f2c tool. I have
converted 8,000 lines so far in two weeks.

Lynn

[Michael S]

What is your motivation for such huge effort?
What's wrong with Fortran 77 as long as it is working?
And *if* there is really something wrong with working Fortran 77,
then why do you port to C++?
Is not it easier to port to Modern Fortran (F20xx) or, may be, to port
majority of code to Modern Fortran and minority to Julia ?

[Lynn McGuire]

The maintenance on the mixed code is becoming cumbersome. And I cannot
find a good Fortran / C++ compiler mix that meets my needs. And I need
a 64 bit version of our software yesterday. Seven of my users have now
tried to move to 64 bit Excel.

I prefer C++. I've been programming in Fortran since 1975, Pascal since
1983, C since 1987, Smalltalk since 1993, and C++ since 1999. I will
miss Fortran but not totally since we have a Fortran interpreter
embedded in our software since 1983.

I and two of my programmers converted our Smalltalk Windows user
interface to C++ in 2001/2002. The port was great, the code base only
increased from 250,000 lines to 350,000 lines.

Lynn

[Tim Rentsch]

If a construct is described by the standard as being undefined
behavior, said construct is still undefined behavior no matter
what the implementation does. The condition of being undefined
behavior is only a statement of what is mandated (or not) by
the standard; it has nothing to do with whether something
"defines" the behavior.

[Öö Tiib]

The effect of undefined behavior is that compilers are allowed
to do whatever these please when running a program that contains it
as far C++ standard is concerned. However if particular compiler
documents outcome of particular situation (described as undefined
behavior by standard) more narrowly then that compiler can't anymore
do whatever it pleases without contradicting its documentation.
So the effect is gone ... whatever words one uses about it does not
matter.

[Juha Nieminen]

Scott Lurndal <sc...@slp53.sl.home> wrote:
> Young C++ programmers don't understand C, so they think
> that static_cast<fem::str<8>*> is more "readable". Heh.

So your opinion on what's "readable" and what isn't is better than my
opinion on the subject because... why?

I'm 99% certain that the main (if not even only) reason why you don't like
static_cast is because it's longer. That's it. No other reason.

I have noticed a very common psychological phenomenon that for some
reason beginner programmers try to write code that's as short as possible,
even when that comes at the cost of legibility (a phenomenon that I have
named "the brevity-over-clarity style of programming"). Way too many
programmers never learn out of this bad habit.

[Scott Lurndal]

Juha Nieminen <nos...@thanks.invalid> writes:
>Scott Lurndal <sc...@slp53.sl.home> wrote:
>> Young C++ programmers don't understand C, so they think
>> that static_cast<fem::str<8>*> is more "readable". Heh.
>
>So your opinion on what's "readable" and what isn't is better than my
>opinion on the subject because... why?

It's an opinion. You know the old saying.

>
>I'm 99% certain that the main (if not even only) reason why you don't like
>static_cast is because it's longer. That's it. No other reason.

Actually, I don't like it because it doesn't add anything useful over
a plain c-style cast.

>
>I have noticed a very common psychological phenomenon that for some
>reason beginner programmers try to write code that's as short as possible,
>even when that comes at the cost of legibility (a phenomenon that I have
>named "the brevity-over-clarity style of programming"). Way too many
>programmers never learn out of this bad habit.

Some of us learned by punching programs on cards and on 110 baud teletypes on computers
with 4k words of memory. Brevity was to be celebrated.

[Keith Thompson]

Wouldn't it be better to call it the BOCSOP? 8-)}

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[Vir Campestris]

On 04/11/2022 13:47, Scott Lurndal wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
>> Scott Lurndal <sc...@slp53.sl.home> wrote:
>>> Young C++ programmers don't understand C, so they think
>>> that static_cast<fem::str<8>*> is more "readable". Heh.
>>
>> So your opinion on what's "readable" and what isn't is better than my
>> opinion on the subject because... why?
>
> It's an opinion. You know the old saying.
>
>>
>> I'm 99% certain that the main (if not even only) reason why you don't like
>> static_cast is because it's longer. That's it. No other reason.
>
> Actually, I don't like it because it doesn't add anything useful over
> a plain c-style cast.
>

I don't like it because it's longer. But sometimes it is better. You
know exactly what it will do.

>>
>> I have noticed a very common psychological phenomenon that for some
>> reason beginner programmers try to write code that's as short as possible,
>> even when that comes at the cost of legibility (a phenomenon that I have
>> named "the brevity-over-clarity style of programming"). Way too many
>> programmers never learn out of this bad habit.
>
> Some of us learned by punching programs on cards and on 110 baud teletypes on computers
> with 4k words of memory. Brevity was to be celebrated.

You had a card punch? You didn't have to shade in the fields with a 6B
pencil? Luxury...

I too learned back in the bad old days. These days I can touch type on a
nice light keyboard I can use for hours. Not like the ASR33 keyboard
that really needed two fingers to press the keys.

The world is in some ways a better place.

Andy

[James Kuyper]

On 11/4/22 09:47, Scott Lurndal wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:

..

>> I'm 99% certain that the main (if not even only) reason why you don't
>> like
>> static_cast is because it's longer. That's it. No other reason.
>
> Actually, I don't like it because it doesn't add anything useful over
> a plain c-style cast.

It's advantage over the plain c-style cast lies in what it won't do: it
won't do any of the things for which const_cast<> or reinterpret_cast<>
are needed instead. It also won't do what dynamic_cast<> does, but
that's also true of the c-style cast.
Particularly in a language that allows overloading and template type
parameters, the consequences of a c-style cast can be hard to
anticipate. The named casts help ensure that only the desired type of
change can occur without triggering a mandatory diagnostic.

>> I have noticed a very common psychological phenomenon that for some
>> reason beginner programmers try to write code that's as short as
>> possible,
>> even when that comes at the cost of legibility (a phenomenon that I have
>> named "the brevity-over-clarity style of programming"). Way too many
>> programmers never learn out of this bad habit.
>
> Some of us learned by punching programs on cards and on 110 baud
> teletypes on computers
> with 4k words of memory. Brevity was to be celebrated.

In 1974 my high school provided computer programming classes, when
almost no one else did, because an alumnus donated a long-obsolete IBM
1620 with a Fortran I compiler, using punched cards and a teletype. It
being a decimal machine, I seem to recall it had 10000 decimal digits of
memory.

While I learned touch typing at an early age, I was always prone to
errors. On punched cards, that meant a lot of wasted cards. Cards that
were correctly punched were a precious resource for me. I took to using
some really bad policies when writing my programs. I used very short
generic variable names, allowing me to re-use them for very different
purposes in different programs. If I typed a variable name incorrectly
on my first try, that incorrect spelling became the new correct spelling
for the variable. I gave statements widely spaced statement numbers,
allowing me to insert new statements between them.

I dropped all of these absurd policies like hot potatoes the instant I
started working on a computer which allowed me to save and edit programs.

[Paavo Helde]

04.11.2022 15:47 Scott Lurndal kirjutas:
> Juha Nieminen <nos...@thanks.invalid> writes:
>> Scott Lurndal <sc...@slp53.sl.home> wrote:
>>> Young C++ programmers don't understand C, so they think
>>> that static_cast<fem::str<8>*> is more "readable". Heh.
>>
>> So your opinion on what's "readable" and what isn't is better than my
>> opinion on the subject because... why?
>
> It's an opinion. You know the old saying.
>
>>
>> I'm 99% certain that the main (if not even only) reason why you don't like
>> static_cast is because it's longer. That's it. No other reason.
>
> Actually, I don't like it because it doesn't add anything useful over
> a plain c-style cast.

But it does. If I get e.g. constness wrong in my casting, a C-style cast
won't bat an eye whereas static_cast will complain loudly. Ditto for
many other mistakes which I might make. If you never make any mistakes
when typing code, then it does not matter, but for me it does.

[Juha Nieminen]

Indeed. In some cases eg. casting away constness may not only lead to bugs,
but in fact be UB. Such as casting away the constness of a char pointer
pointing to a string literal, and then trying to modify the contents of
that string.

With static_cast the compiler will tell you that you are trying to
cast away constness, and it may immediately indicate your error. With
a C style cast you might never notice, and the program may even seem
to work fine... until one day it doesn't.

[Tim Rentsch]

> The effect of undefined behavior [...]

Undefined behavior is a classification; it doesn't have effects.
Moreover the classification holds regardless of how an
implementation might treat constructs that are so classified.

[Tim Rentsch]

Keith Thompson <Keith.S.T...@gmail.com> writes:

> Andrey Tarasevich <andreyta...@hotmail.com> writes:
>
>> On 10/20/2022 4:23 AM, Paul N wrote:
>>
>>> On Thursday, October 20, 2022 at 6:21:25 AM UTC+1, Lynn McGuire wrote:
>>>
>>>> They are both pointers to 8 byte objects. I am just declaring
>>>> that I want to use the same address as a 8 byte character string
>>>> (no null !) or a long long integer.
>>>
>>> Isn't that exactly what a union is for? Though if you are hoping
>>> to put in values of one type and read them out as values of the
>>> other then you would need to check that this is actually defined
>>> in your implementation.
>>
>> "Exactly what a union is for"?
>>
>> It is true that unions have been used for type punning from time to
>> time, but this is not "what a union is for". Union is a
>> memory-time-sharing feature that exists for reducing memory usage.
>> You don't normally "put in values of one type and read them out as
>> values of the other". That's not exactly what union is for.
>
> Agreed.
>
> K&R1 (1978) introduces unions in section 6.8. It discusses holding
> objects of different types at different times; it says nothing
> about type punning. (The version of C discussed in the 1975 manual
> didn't have unions.)

Even so, clearly it was expected that unions would be used for
type punning, and that type punning would work the same way it
works now, even during the early days of C between K&R1 and when
the original ANSI C committee was formed. Evidence for this
assertion may be found in the C Rationale document, which says
nothing about using unions for type punning. The lack of any
mention in the Rationale document means it must have been common
practice in the early days, otherwise it would have been new
behavior and surely would have been discussed and debated and
written up in the Rationale document. Because it wasn't, unions
obviously were being used that way all along.

[Öö Tiib]

You managed to read 5 words?
I meant effect to people/organizations who implement a
compiler as specified by standard.

[Juha Nieminen]

Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
> Even so, clearly it was expected that unions would be used for
> type punning,

I'm not sure it's that evident.

'union' in C sounds a lot more like a space optimization. A way to
reuse the same memory location to store different types. Like a tuple
which can only hold one value at a time (and the main impetus in this
existing is to save valuable memory, if you indeed only need one type
of value for that object at a time).

I don't see how it's so obvious that 'union' was designed from the
get-go with the intent of using it for type punning. Could just as
well be an unintended or semi-intended "side effect" (which may be
platform-specific, ie. not guaranteed to work if the target platform
doesn't support such a thing).

[David Brown]

It's worth noting that in C++, unions specifically cannot be used for
type-punning. If type-punning were considered a major use of unions at
the time C++ was being standardised, I think it is reasonable to suppose
C++ would have allowed it (perhaps with restrictions to POD types)
rather than clearly disallowing it. I realise that reasoning is weak -
but no weaker than Tim's reasoning that C supported type-punning from an
early stage.

In general, I do not think it is right to think "the standard doesn't
ban it, so it is allowed", or "the rationale doesn't mention it, so it
must have been viewed as obvious". The C standard makes it clear that
behaviour that is not described is as much "undefined behaviour" as
things that are explicitly marked as "undefined behaviour". So in C90,
AFAICS, using a union for type punning is just like dereferencing a null
pointer, or calling a function with the wrong number or type of
parameters, or any other undefined behaviour.

That is why we have a language /standard/ - not just some interesting
rationale documents.

[Tim Rentsch]

Juha Nieminen <nos...@thanks.invalid> writes:

> Tim Rentsch <tr.1...@z991.linuxsc.com> wrote:
>
>> Even so, clearly it was expected that unions would be used for
>> type punning,
>
> I'm not sure it's that evident.
>

> [...]

>
> I don't see how it's so obvious that 'union' was designed from the
> get-go with the intent of using it for type punning.

I didn't say anything about how the union construct was designed.
What I did say was that it was expected that unions would be used
for type punning, and that expectation was evident long before the
first C standard. It isn't relevant to what I was saying whether
unions were designed that way or not.

[Tim Rentsch]

> I meant [...]

If you can't be bothered to say what you mean in the first
place, don't expect people to waste their time trying to
figure out what you do mean.

[Alf P. Steinbach]

On 20 Nov 2022 14:59, Tim Rentsch wrote:
> Tiib <oot...@hot.ee> writes:

>> [snip]

>>
>> You managed to read 5 words?
>> I meant [...]
>
> If you can't be bothered to say what you mean in the first
> place, don't expect people to waste their time trying to
> figure out what you do mean.

It's silly of you to pretend that you read just the first 5 words of a
sentence.

Even more silly to turn that around and demand that any contributor here
should sum up what they mean in the first 5 words of each sentence,
presumably with the rest of each sentence clarifying the first 5 words.

That position reminds me of Molbo-land, Moronia, Infantilia and other
such places.


- Alf

[Tim Rentsch]

"Alf P. Steinbach" <alf.p.s...@gmail.com> writes:

> On 20 Nov 2022 14:59, Tim Rentsch wrote:
>
>> Tiib <oot...@hot.ee> writes:
>>
>>> [snip]
>>>
>>> You managed to read 5 words?
>>> I meant [...]
>>
>> If you can't be bothered to say what you mean in the first
>> place, don't expect people to waste their time trying to
>> figure out what you do mean.
>
> It's silly of you to pretend that you read just the first 5 words of a
> sentence.

I am neither claiming nor pretending that I read only the first
five words of Tiib's comment. Those words are simply all that I
was responding to.

When given a bad omelette, I don't need to eat the whole thing to
discover it is bad.

> [...]

The rest of what you wrote seems irrelevant since your initial
assumption was wrong. In most cases it's better if you don't
read things into what I say that aren't there.

[Öö Tiib]

On Sunday, 20 November 2022 at 17:23:06 UTC+2, Tim Rentsch wrote:
> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes:
>
> > On 20 Nov 2022 14:59, Tim Rentsch wrote:
> >
> >> Tiib <oot...@hot.ee> writes:
> >>
> >>> [snip]
> >>>
> >>> You managed to read 5 words?
> >>> I meant [...]
> >>
> >> If you can't be bothered to say what you mean in the first
> >> place, don't expect people to waste their time trying to
> >> figure out what you do mean.
> >
> > It's silly of you to pretend that you read just the first 5 words of a
> > sentence.
> I am neither claiming nor pretending that I read only the first
> five words of Tiib's comment.

You left such impression. And improved it by saying that if 5
first words do not manage to say everything, then you should
not read rest of the sentence.

>> Those words are simply all that I was responding to.

Your response only misrepresented these five words.

>
> When given a bad omelette, I don't need to eat the whole thing to
> discover it is bad.

Look who's talking? What you post is mixture of lies,
misrepresentations and other sad garbage. Can be you have
nothing better to do but that is not my fault.

[Tim Rentsch]

Tiib <oot...@hot.ee> writes:

> On Sunday, 20 November 2022 at 17:23:06 UTC+2, Tim Rentsch wrote:
>
>> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes:
>>
>>> On 20 Nov 2022 14:59, Tim Rentsch wrote:
>>>
>>>> Tiib <oot...@hot.ee> writes:
>>>>
>>>>> [snip]
>>>>>
>>>>> You managed to read 5 words?
>>>>> I meant [...]
>>>>
>>>> If you can't be bothered to say what you mean in the first
>>>> place, don't expect people to waste their time trying to
>>>> figure out what you do mean.
>>>
>>> It's silly of you to pretend that you read just the first 5 words of a
>>> sentence.
>>
>> I am neither claiming nor pretending that I read only the first
>> five words of Tiib's comment.
>
> You left such impression.

That is your problem, not mine.