Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #44630 > unrolled thread
| Started by | Melzzzzz <mel@zzzzz.com> |
|---|---|
| First post | 2016-08-31 14:59 +0200 |
| Last post | 2016-09-05 21:25 +0100 |
| Articles | 20 on this page of 123 — 25 participants |
Back to article view | Back to comp.lang.c++
This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-08-31 14:59 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-08-31 15:20 +0200
Re: This will work or not? mark <mark@invalid.invalid> - 2016-08-31 16:05 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-08-31 16:19 +0200
Re: This will work or not? scott@slp53.sl.home (Scott Lurndal) - 2016-08-31 14:20 +0000
Re: This will work or not? Bo Persson <bop@gmb.dk> - 2016-08-31 18:53 +0200
Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 09:03 -0700
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-01 22:45 +0200
Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 18:08 -0700
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 09:24 +0200
Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 06:31 -0700
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-04 20:19 +0200
Re: This will work or not? Manfred <noname@invalid.add> - 2016-08-31 15:45 +0200
Re: This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-08-31 15:59 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-08-31 16:22 +0200
Re: This will work or not? Manfred <noname@invalid.add> - 2016-08-31 17:06 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-08-31 19:29 +0200
Re: This will work or not? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2016-08-31 21:52 +0100
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-01 09:07 +0200
Re: This will work or not? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2016-09-01 12:30 +0100
Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 09:01 -0700
Re: This will work or not? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2016-09-01 18:16 +0100
Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 18:37 -0700
Re: This will work or not? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2016-09-02 10:42 +0100
Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 06:59 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 23:17 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-01 09:35 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 15:34 -0400
Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-01 13:50 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 21:01 -0400
Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-01 19:02 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 22:17 -0400
Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-02 08:19 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 12:39 -0400
Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-02 12:26 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 16:38 -0400
Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-02 13:51 -0700
Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-02 14:16 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 19:58 -0400
Re: This will work or not? Paavo Helde <myfirstname@osa.pri.ee> - 2016-09-02 23:56 +0300
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-03 17:58 +0200
Re: This will work or not? Manfred <noname@invalid.add> - 2016-09-02 11:41 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 12:27 +0200
Re: This will work or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-02 12:37 +0100
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 17:39 +0200
Re: This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-09-02 17:40 +0200
Re: This will work or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-02 16:54 +0100
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 20:22 +0200
Re: This will work or not? Richard Damon <Richard@Damon-Family.org> - 2016-09-02 08:04 -0400
Re: This will work or not? BartC <bc@freeuk.com> - 2016-09-02 13:51 +0100
Re: This will work or not? Richard Damon <Richard@Damon-Family.org> - 2016-09-02 21:48 -0400
Re: This will work or not? Manfred <noname@invalid.add> - 2016-09-02 15:17 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 17:46 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-01 23:14 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 21:02 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 09:35 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 08:50 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 17:59 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 12:49 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 20:36 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 16:32 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-03 18:08 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 18:25 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-03 23:51 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 21:48 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 03:48 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 23:05 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 05:02 +0100
Re: This will work or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-04 10:57 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 09:40 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 16:39 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 12:46 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 17:51 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 13:07 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 18:37 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 17:16 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 22:23 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 18:54 -0400
Re: This will work or not? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-04 09:58 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 13:08 -0400
Re: This will work or not? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-04 10:21 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 17:18 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 22:24 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 18:56 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 00:27 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 22:53 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 18:18 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-05 15:27 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 20:32 +0100
Re: This will work or not? woodbrian77@gmail.com - 2016-09-05 14:07 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-05 18:15 -0400
Re: This will work or not? Ike Naar <ike@iceland.freeshell.org> - 2016-09-05 20:12 +0000
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 22:05 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-05 18:16 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-06 08:47 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-06 09:12 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-06 16:31 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-06 11:20 -0400
Re: This will work or not? bighe.trole@gmail.com - 2016-09-04 18:55 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 22:55 -0400
Re: This will work or not? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-04 17:17 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 22:57 -0400
Re: This will work or not? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-05 11:20 -0700
Re: This will work or not? Luuk <luuk@invalid.lan> - 2016-09-04 18:54 +0200
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 17:59 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 13:08 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-04 20:25 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 17:20 -0400
Re: This will work or not? Öö Tiib <ootiib@hot.ee> - 2016-09-04 02:36 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 09:41 -0400
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 21:49 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 03:49 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 23:06 -0400
Re: This will work or not? woodbrian77@gmail.com - 2016-09-03 21:16 -0700
Re: This will work or not? Vir Campestris <vir.campestris@invalid.invalid> - 2016-08-31 21:08 +0100
Re: This will work or not? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2016-09-01 02:28 +0200
Re: This will work or not? Öö Tiib <ootiib@hot.ee> - 2016-09-01 01:28 -0700
Re: This will work or not? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-02 12:06 -0700
Re: This will work or not? Öö Tiib <ootiib@hot.ee> - 2016-09-05 02:21 -0700
Re: This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-09-05 13:38 +0200
Re: This will work or not? Juha Nieminen <nospam@thanks.invalid> - 2016-09-05 11:34 +0000
Re: This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-09-05 13:36 +0200
Re: This will work or not? Vir Campestris <vir.campestris@invalid.invalid> - 2016-09-05 21:25 +0100
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-09-04 17:17 -0700 |
| Message-ID | <8402799f-27d4-4362-bb8d-73a0607036f7@googlegroups.com> |
| In reply to | #44838 |
Jerry Stuckle wrote: > Real Christians know when religious discussions are > appropriate and when they are not. When a person is saved, they are changed by the born again nature. They are transformed from within to become servants of Jesus Christ. We remember that He came to save the lost, that He went into the places of the world where the nonbelievers were, to teach them about sin, about salvation, and about God's plan for their lives. We remember that the enemy spirit is at work 24/7 to squelch the message of the need for salvation, the need for repentance, the need to teach others the same. We remember the Lord's command to love one another, and His Great Commission to go out into all the world and teach and make disciples. Jesus came to the Earth to save men's souls. His work continues in us. Our lives are not our own. We were bought at a price, and there is a calling upon us unto Him which precedes everything we do in our lives. He is to always be our primary going concern, with all other things coming after. I'm sorry you've had difficulty with Mr. Flibble. But remember the Lord sometimes puts stumbling blocks ahead of us to knock us to our knees, so that we will press in more to meet the needs of the circumstance. You might begin by showing Mr. Flibble some proper respect by referring to him by the correct name, and look up the lyrics to the song, "Follow Me" by Ira Stanphill to place your efforts, your successes, your failures, and your tasks, into proper perspective. And remember who it was who bought you, Jerry ... and in what state He bought you, and in what condition He intends for you. It is important to remember who He is, what He's done, and what His purpose was for coming to the Earth, so that our purpose will be continually considered within the proper light. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-04 22:57 -0400 |
| Message-ID | <nqimun$llq$3@jstuckle.eternal-september.org> |
| In reply to | #44846 |
On 9/4/2016 8:17 PM, Rick C. Hodgin wrote: > Jerry Stuckle wrote: >> Real Christians know when religious discussions are >> appropriate and when they are not. > > When a person is saved, they are changed by the born again nature. > They are transformed from within to become servants of Jesus Christ. > We remember that He came to save the lost, that He went into the > places of the world where the nonbelievers were, to teach them > about sin, about salvation, and about God's plan for their lives. > > We remember that the enemy spirit is at work 24/7 to squelch the > message of the need for salvation, the need for repentance, the need > to teach others the same. > > We remember the Lord's command to love one another, and His Great > Commission to go out into all the world and teach and make > disciples. > > Jesus came to the Earth to save men's souls. His work continues in > us. Our lives are not our own. We were bought at a price, and there > is a calling upon us unto Him which precedes everything we do in > our lives. He is to always be our primary going concern, with all > other things coming after. > > I'm sorry you've had difficulty with Mr. Flibble. But remember the Lord > sometimes puts stumbling blocks ahead of us to knock us to our knees, > so that we will press in more to meet the needs of the circumstance. > You might begin by showing Mr. Flibble some proper respect by > referring to him by the correct name, and look up the lyrics to the > song, "Follow Me" by Ira Stanphill to place your efforts, your successes, > your failures, and your tasks, into proper perspective. > > And remember who it was who bought you, Jerry ... and in what > state He bought you, and in what condition He intends for you. > > It is important to remember who He is, what He's done, and what > His purpose was for coming to the Earth, so that our purpose will be > continually considered within the proper light. > > Best regards, > Rick C. Hodgin > I'm not going to debate religion with you, Rick. But you need to remember who HE is. But He is not the one you worship. Satan is very insidious, and he has you in his clutches. Real Christians know where discussion on religion is appropriate and where it is not. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-09-05 11:20 -0700 |
| Message-ID | <d225f05a-90ff-4313-a70d-43351cf4d59e@googlegroups.com> |
| In reply to | #44852 |
On Sunday, September 4, 2016 at 10:57:35 PM UTC-4, Jerry Stuckle wrote: > I'm not going to debate religion with you, Rick. That is wise, Jerry. However, it's of no consequence because I do not debate. I teach. It is up to each person to receive Him ... or not. When I have taught, and explained things as clearly as I'm able, I am then free of any unfinished business before God (in that circumstance) and will stand without guilt or shame before Him, having opened my mouth to speak when He called me to do so. There is no inappropriate place to teach people about Jesus Christ, Jerry. It is only the enemy who teaches that message. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Luuk <luuk@invalid.lan> |
|---|---|
| Date | 2016-09-04 18:54 +0200 |
| Message-ID | <57cc51c3$0$939$e4fe514c@news.xs4all.nl> |
| In reply to | #44819 |
On 04-09-16 17:39, Mr Flibble wrote:
> On 04/09/2016 14:40, Jerry Stuckle wrote:
>> On 9/4/2016 5:57 AM, Ben Bacarisse wrote:
>>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
>>>
>>>> On 04/09/2016 04:05, Jerry Stuckle wrote:
>>> <snip>
>>>>>>>> On 03/09/2016 23:25, Jerry Stuckle wrote:
>>>>>>>>>
>>>>>>>>> ... Starting when you claimed you couldn't determine
>>>>>>>>> whether a machine was big endian or little endian at compiler
>>>>>>>>> time, and
>>>>>>>>> I showed you wrong there, also.
>>>
>>>>> Sorry. Look back in this newsgroup. I proved it was possible. Look
>>>>> back for yourself and see. I'm not going to bother to repeat it for a
>>>>> troll.
>>> <snip>
>>>> Nope, it is not possible to determine endianness with a standard
>>>> conformant C++ compiler at compile time.
>>>
>>> Just to remind people, Jerry Stuckle's "solution" is to write a program
>>> to determine the byte order, and to use its output in the build of the
>>> program that needs to know. This is, of course, not what people mean by
>>> determining something "at compile time". He likely know this because it
>>> removes any meaning from the phrase --- anything that can be determined
>>> at run time can be determined at "Jerry Stuckle compile time".
>>>
>>
>> It satisfied the requirement. The determination was made at compile
>> time, and the result of the compile was dependent on whether the order
>> was little endian or big endian.
>>
>> It's not my fault you didn't think of it. And people use external
>> programs during compile all the time. "make" is a good example, and it
>> can also set compile options.
>
> LOL. Obviously using code generation tools is not what people mean when
> they say "determine at compile time". Determining something at compile
> time is what can be achieved by the C++ compiler whilst it is compiling
> an individual translation unit. So again you remain incorrect and we
> remain correct:
>
> It is not possible to determine endianness with a standard conformant
> C++ compiler at compile time.
>
> /Flibble
If the answer from Mr Stuckle is not correct, maybe the answer from
Stackoverflow is better?
http://stackoverflow.com/questions/4239993/determining-endianness-at-compile-time
bool isLittleEndian()
{
short int number = 0x1;
char *numPtr = (char*)&number;
return (numPtr[0] == 1);
}
Create an integer, and read its first byte (least significant byte). If
that byte is 1, then the system is little endian, otherwise it's big endian.
(less than 5 minutes of Google...)
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> |
|---|---|
| Date | 2016-09-04 17:59 +0100 |
| Message-ID | <9s-dnaNpzrlOz1HKnZ2dnUU7-KudnZ2d@giganews.com> |
| In reply to | #44824 |
On 04/09/2016 17:54, Luuk wrote:
> On 04-09-16 17:39, Mr Flibble wrote:
>> On 04/09/2016 14:40, Jerry Stuckle wrote:
>>> On 9/4/2016 5:57 AM, Ben Bacarisse wrote:
>>>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
>>>>
>>>>> On 04/09/2016 04:05, Jerry Stuckle wrote:
>>>> <snip>
>>>>>>>>> On 03/09/2016 23:25, Jerry Stuckle wrote:
>>>>>>>>>>
>>>>>>>>>> ... Starting when you claimed you couldn't determine
>>>>>>>>>> whether a machine was big endian or little endian at compiler
>>>>>>>>>> time, and
>>>>>>>>>> I showed you wrong there, also.
>>>>
>>>>>> Sorry. Look back in this newsgroup. I proved it was possible. Look
>>>>>> back for yourself and see. I'm not going to bother to repeat it
>>>>>> for a
>>>>>> troll.
>>>> <snip>
>>>>> Nope, it is not possible to determine endianness with a standard
>>>>> conformant C++ compiler at compile time.
>>>>
>>>> Just to remind people, Jerry Stuckle's "solution" is to write a program
>>>> to determine the byte order, and to use its output in the build of the
>>>> program that needs to know. This is, of course, not what people
>>>> mean by
>>>> determining something "at compile time". He likely know this
>>>> because it
>>>> removes any meaning from the phrase --- anything that can be determined
>>>> at run time can be determined at "Jerry Stuckle compile time".
>>>>
>>>
>>> It satisfied the requirement. The determination was made at compile
>>> time, and the result of the compile was dependent on whether the order
>>> was little endian or big endian.
>>>
>>> It's not my fault you didn't think of it. And people use external
>>> programs during compile all the time. "make" is a good example, and it
>>> can also set compile options.
>>
>> LOL. Obviously using code generation tools is not what people mean when
>> they say "determine at compile time". Determining something at compile
>> time is what can be achieved by the C++ compiler whilst it is compiling
>> an individual translation unit. So again you remain incorrect and we
>> remain correct:
>>
>> It is not possible to determine endianness with a standard conformant
>> C++ compiler at compile time.
>>
>> /Flibble
>
> If the answer from Mr Stuckle is not correct, maybe the answer from
> Stackoverflow is better?
>
> http://stackoverflow.com/questions/4239993/determining-endianness-at-compile-time
>
>
> bool isLittleEndian()
> {
> short int number = 0x1;
> char *numPtr = (char*)&number;
> return (numPtr[0] == 1);
> }
>
> Create an integer, and read its first byte (least significant byte). If
> that byte is 1, then the system is little endian, otherwise it's big
> endian.
>
> (less than 5 minutes of Google...)
No because isLittleEndian() cannot be called at COMPILE TIME. Try
paying attention.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-04 13:08 -0400 |
| Message-ID | <nqhkf5$cbp$3@jstuckle.eternal-september.org> |
| In reply to | #44824 |
On 9/4/2016 12:54 PM, Luuk wrote:
> On 04-09-16 17:39, Mr Flibble wrote:
>> On 04/09/2016 14:40, Jerry Stuckle wrote:
>>> On 9/4/2016 5:57 AM, Ben Bacarisse wrote:
>>>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
>>>>
>>>>> On 04/09/2016 04:05, Jerry Stuckle wrote:
>>>> <snip>
>>>>>>>>> On 03/09/2016 23:25, Jerry Stuckle wrote:
>>>>>>>>>>
>>>>>>>>>> ... Starting when you claimed you couldn't determine
>>>>>>>>>> whether a machine was big endian or little endian at compiler
>>>>>>>>>> time, and
>>>>>>>>>> I showed you wrong there, also.
>>>>
>>>>>> Sorry. Look back in this newsgroup. I proved it was possible. Look
>>>>>> back for yourself and see. I'm not going to bother to repeat it
>>>>>> for a
>>>>>> troll.
>>>> <snip>
>>>>> Nope, it is not possible to determine endianness with a standard
>>>>> conformant C++ compiler at compile time.
>>>>
>>>> Just to remind people, Jerry Stuckle's "solution" is to write a program
>>>> to determine the byte order, and to use its output in the build of the
>>>> program that needs to know. This is, of course, not what people
>>>> mean by
>>>> determining something "at compile time". He likely know this
>>>> because it
>>>> removes any meaning from the phrase --- anything that can be determined
>>>> at run time can be determined at "Jerry Stuckle compile time".
>>>>
>>>
>>> It satisfied the requirement. The determination was made at compile
>>> time, and the result of the compile was dependent on whether the order
>>> was little endian or big endian.
>>>
>>> It's not my fault you didn't think of it. And people use external
>>> programs during compile all the time. "make" is a good example, and it
>>> can also set compile options.
>>
>> LOL. Obviously using code generation tools is not what people mean when
>> they say "determine at compile time". Determining something at compile
>> time is what can be achieved by the C++ compiler whilst it is compiling
>> an individual translation unit. So again you remain incorrect and we
>> remain correct:
>>
>> It is not possible to determine endianness with a standard conformant
>> C++ compiler at compile time.
>>
>> /Flibble
>
> If the answer from Mr Stuckle is not correct, maybe the answer from
> Stackoverflow is better?
>
> http://stackoverflow.com/questions/4239993/determining-endianness-at-compile-time
>
>
> bool isLittleEndian()
> {
> short int number = 0x1;
> char *numPtr = (char*)&number;
> return (numPtr[0] == 1);
> }
>
> Create an integer, and read its first byte (least significant byte). If
> that byte is 1, then the system is little endian, otherwise it's big
> endian.
>
> (less than 5 minutes of Google...)
That's not done at compile time - which is what the requirement was.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-04 20:25 +0200 |
| Message-ID | <nqhoub$tof$1@dont-email.me> |
| In reply to | #44824 |
On 04/09/16 18:54, Luuk wrote:
> On 04-09-16 17:39, Mr Flibble wrote:
>> On 04/09/2016 14:40, Jerry Stuckle wrote:
>>> On 9/4/2016 5:57 AM, Ben Bacarisse wrote:
>>>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
>>>>
>>>>> On 04/09/2016 04:05, Jerry Stuckle wrote:
>>>> <snip>
>>>>>>>>> On 03/09/2016 23:25, Jerry Stuckle wrote:
>>>>>>>>>>
>>>>>>>>>> ... Starting when you claimed you couldn't determine
>>>>>>>>>> whether a machine was big endian or little endian at compiler
>>>>>>>>>> time, and
>>>>>>>>>> I showed you wrong there, also.
>>>>
>>>>>> Sorry. Look back in this newsgroup. I proved it was possible. Look
>>>>>> back for yourself and see. I'm not going to bother to repeat it
>>>>>> for a
>>>>>> troll.
>>>> <snip>
>>>>> Nope, it is not possible to determine endianness with a standard
>>>>> conformant C++ compiler at compile time.
>>>>
>>>> Just to remind people, Jerry Stuckle's "solution" is to write a program
>>>> to determine the byte order, and to use its output in the build of the
>>>> program that needs to know. This is, of course, not what people
>>>> mean by
>>>> determining something "at compile time". He likely know this
>>>> because it
>>>> removes any meaning from the phrase --- anything that can be determined
>>>> at run time can be determined at "Jerry Stuckle compile time".
>>>>
>>>
>>> It satisfied the requirement. The determination was made at compile
>>> time, and the result of the compile was dependent on whether the order
>>> was little endian or big endian.
>>>
>>> It's not my fault you didn't think of it. And people use external
>>> programs during compile all the time. "make" is a good example, and it
>>> can also set compile options.
>>
>> LOL. Obviously using code generation tools is not what people mean when
>> they say "determine at compile time". Determining something at compile
>> time is what can be achieved by the C++ compiler whilst it is compiling
>> an individual translation unit. So again you remain incorrect and we
>> remain correct:
>>
>> It is not possible to determine endianness with a standard conformant
>> C++ compiler at compile time.
>>
>> /Flibble
>
> If the answer from Mr Stuckle is not correct, maybe the answer from
> Stackoverflow is better?
>
> http://stackoverflow.com/questions/4239993/determining-endianness-at-compile-time
>
>
> bool isLittleEndian()
> {
> short int number = 0x1;
> char *numPtr = (char*)&number;
> return (numPtr[0] == 1);
> }
>
> Create an integer, and read its first byte (least significant byte). If
> that byte is 1, then the system is little endian, otherwise it's big
> endian.
>
> (less than 5 minutes of Google...)
This is done at run-time, just like Jerry's "solution". The difference
is that Jerry takes the output of a function like isLittleEndian(), and
uses it to affect the compilation of a different file (by using it to
generate a header, or something like that - I have forgotten the
details). Of course, Jerry's "solution" is no more of a compile-time
solution than this one is. In fact, it is far worse, because it fails
when doing cross-compilation.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-04 17:20 -0400 |
| Message-ID | <nqi37i$1li$3@jstuckle.eternal-september.org> |
| In reply to | #44833 |
On 9/4/2016 2:25 PM, David Brown wrote:
> On 04/09/16 18:54, Luuk wrote:
>> On 04-09-16 17:39, Mr Flibble wrote:
>>> On 04/09/2016 14:40, Jerry Stuckle wrote:
>>>> On 9/4/2016 5:57 AM, Ben Bacarisse wrote:
>>>>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
>>>>>
>>>>>> On 04/09/2016 04:05, Jerry Stuckle wrote:
>>>>> <snip>
>>>>>>>>>> On 03/09/2016 23:25, Jerry Stuckle wrote:
>>>>>>>>>>>
>>>>>>>>>>> ... Starting when you claimed you couldn't determine
>>>>>>>>>>> whether a machine was big endian or little endian at compiler
>>>>>>>>>>> time, and
>>>>>>>>>>> I showed you wrong there, also.
>>>>>
>>>>>>> Sorry. Look back in this newsgroup. I proved it was possible.
>>>>>>> Look
>>>>>>> back for yourself and see. I'm not going to bother to repeat it
>>>>>>> for a
>>>>>>> troll.
>>>>> <snip>
>>>>>> Nope, it is not possible to determine endianness with a standard
>>>>>> conformant C++ compiler at compile time.
>>>>>
>>>>> Just to remind people, Jerry Stuckle's "solution" is to write a
>>>>> program
>>>>> to determine the byte order, and to use its output in the build of the
>>>>> program that needs to know. This is, of course, not what people
>>>>> mean by
>>>>> determining something "at compile time". He likely know this
>>>>> because it
>>>>> removes any meaning from the phrase --- anything that can be
>>>>> determined
>>>>> at run time can be determined at "Jerry Stuckle compile time".
>>>>>
>>>>
>>>> It satisfied the requirement. The determination was made at compile
>>>> time, and the result of the compile was dependent on whether the order
>>>> was little endian or big endian.
>>>>
>>>> It's not my fault you didn't think of it. And people use external
>>>> programs during compile all the time. "make" is a good example, and it
>>>> can also set compile options.
>>>
>>> LOL. Obviously using code generation tools is not what people mean when
>>> they say "determine at compile time". Determining something at compile
>>> time is what can be achieved by the C++ compiler whilst it is compiling
>>> an individual translation unit. So again you remain incorrect and we
>>> remain correct:
>>>
>>> It is not possible to determine endianness with a standard conformant
>>> C++ compiler at compile time.
>>>
>>> /Flibble
>>
>> If the answer from Mr Stuckle is not correct, maybe the answer from
>> Stackoverflow is better?
>>
>> http://stackoverflow.com/questions/4239993/determining-endianness-at-compile-time
>>
>>
>>
>> bool isLittleEndian()
>> {
>> short int number = 0x1;
>> char *numPtr = (char*)&number;
>> return (numPtr[0] == 1);
>> }
>>
>> Create an integer, and read its first byte (least significant byte). If
>> that byte is 1, then the system is little endian, otherwise it's big
>> endian.
>>
>> (less than 5 minutes of Google...)
>
> This is done at run-time, just like Jerry's "solution". The difference
> is that Jerry takes the output of a function like isLittleEndian(), and
> uses it to affect the compilation of a different file (by using it to
> generate a header, or something like that - I have forgotten the
> details). Of course, Jerry's "solution" is no more of a compile-time
> solution than this one is. In fact, it is far worse, because it fails
> when doing cross-compilation.
>
>
No, my solution was done at compile time, just like your requirement.
And you never said anything about cross-compilation. Had you done so, I
would have supplied a different solution.
But you never do admit you are wrong. This is a perfect example. You
said it could not be done, and I showed you how to do it. So instead of
admitting you were wrong and I was right, you tried to change the
requirements.
It doesn't work.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2016-09-04 02:36 -0700 |
| Message-ID | <b3458a12-36a1-40ea-b5a2-7a4f65d10bb9@googlegroups.com> |
| In reply to | #44801 |
On Sunday, 4 September 2016 06:05:51 UTC+3, Jerry Stuckle wrote: > On 9/3/2016 10:48 PM, Mr Flibble wrote: > > On 04/09/2016 02:48, Jerry Stuckle wrote: > >> On 9/3/2016 6:51 PM, Mr Flibble wrote: > >>> On 03/09/2016 23:25, Jerry Stuckle wrote: > >>>> > >>>> And those aren't insults. They are only the truth. Stoopid is as > >>>> stoopid does. And you have proven yourself time and time again to be > >>>> one of the worst. Starting when you claimed you couldn't determine > >>>> whether a machine was big endian or little endian at compiler time, and > >>>> I showed you wrong there, also. > >>> > >>> It is not possible with a standard conforming C++ compiler to determine > >>> endianness at compile time. > >>> > >>> Boost does offer a header file with platform specific information on > >>> endianness however. > >>> > >>> /Flibble > >> > >> Wrong again - as I showed here several months ago. However, I know it > >> is well beyond your limited level of comprehension. > > > > Nope, it is not possible to determine endianness with a standard > > conformant C++ compiler at compile time. > > > > /Flibble > > > > > > Sorry. Look back in this newsgroup. I proved it was possible. Look > back for yourself and see. I'm not going to bother to repeat it for a > troll. Perhaps you forget yourself what it was. Your example assumed that we compile on equipment for what we compile. In practice we typically compile on computer or on build farm that is LE platform. The target for what we compile may be BE. So your "proof" does not work in practice. People told you that but you did not respond anything coherent. Now you refer to it like it was something settled. Who is troll here? > > That's the difference between a coder and a consultant. A coder says > "It can't be done". A consultant says "Here's how you do it". > > But then you're barely a coder, so no surprise here. Whining and bitching much?
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-04 09:41 -0400 |
| Message-ID | <nqh8b2$2gq$2@jstuckle.eternal-september.org> |
| In reply to | #44808 |
On 9/4/2016 5:36 AM, Öö Tiib wrote: > On Sunday, 4 September 2016 06:05:51 UTC+3, Jerry Stuckle wrote: >> On 9/3/2016 10:48 PM, Mr Flibble wrote: >>> On 04/09/2016 02:48, Jerry Stuckle wrote: >>>> On 9/3/2016 6:51 PM, Mr Flibble wrote: >>>>> On 03/09/2016 23:25, Jerry Stuckle wrote: >>>>>> >>>>>> And those aren't insults. They are only the truth. Stoopid is as >>>>>> stoopid does. And you have proven yourself time and time again to be >>>>>> one of the worst. Starting when you claimed you couldn't determine >>>>>> whether a machine was big endian or little endian at compiler time, and >>>>>> I showed you wrong there, also. >>>>> >>>>> It is not possible with a standard conforming C++ compiler to determine >>>>> endianness at compile time. >>>>> >>>>> Boost does offer a header file with platform specific information on >>>>> endianness however. >>>>> >>>>> /Flibble >>>> >>>> Wrong again - as I showed here several months ago. However, I know it >>>> is well beyond your limited level of comprehension. >>> >>> Nope, it is not possible to determine endianness with a standard >>> conformant C++ compiler at compile time. >>> >>> /Flibble >>> >>> >> >> Sorry. Look back in this newsgroup. I proved it was possible. Look >> back for yourself and see. I'm not going to bother to repeat it for a >> troll. > > Perhaps you forget yourself what it was. Your example assumed that we > compile on equipment for what we compile. In practice we typically compile > on computer or on build farm that is LE platform. The target for what we > compile may be BE. So your "proof" does not work in practice. > > People told you that but you did not respond anything coherent. Now you > refer to it like it was something settled. Who is troll here? > That was not part of the original requirement. You tried to change the rules after the fact. It doesn't work. >> >> That's the difference between a coder and a consultant. A coder says >> "It can't be done". A consultant says "Here's how you do it". >> >> But then you're barely a coder, so no surprise here. > > Whining and bitching much? > Nope, just pointing out the truth. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-03 21:49 -0400 |
| Message-ID | <nqfujc$i2d$2@jstuckle.eternal-september.org> |
| In reply to | #44794 |
On 9/3/2016 6:51 PM, Mr Flibble wrote: > On 03/09/2016 23:25, Jerry Stuckle wrote: >> >> And those aren't insults. They are only the truth. Stoopid is as >> stoopid does. And you have proven yourself time and time again to be >> one of the worst. Starting when you claimed you couldn't determine >> whether a machine was big endian or little endian at compiler time, and >> I showed you wrong there, also. > > It is not possible with a standard conforming C++ compiler to determine > endianness at compile time. > > Boost does offer a header file with platform specific information on > endianness however. > > /Flibble BTW - I though you were going to killfile me. I knew you wouldn't, though. You have shown yourself to be much too obsessed with me. You really need to get help with that obsession. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> |
|---|---|
| Date | 2016-09-04 03:49 +0100 |
| Message-ID | <-9mdnWm-c-MnFlbKnZ2dnUU7-KUAAAAA@giganews.com> |
| In reply to | #44798 |
On 04/09/2016 02:49, Jerry Stuckle wrote: > On 9/3/2016 6:51 PM, Mr Flibble wrote: >> On 03/09/2016 23:25, Jerry Stuckle wrote: >>> >>> And those aren't insults. They are only the truth. Stoopid is as >>> stoopid does. And you have proven yourself time and time again to be >>> one of the worst. Starting when you claimed you couldn't determine >>> whether a machine was big endian or little endian at compiler time, and >>> I showed you wrong there, also. >> >> It is not possible with a standard conforming C++ compiler to determine >> endianness at compile time. >> >> Boost does offer a header file with platform specific information on >> endianness however. >> >> /Flibble > > BTW - I though you were going to killfile me. I knew you wouldn't, > though. You have shown yourself to be much too obsessed with me. You > really need to get help with that obsession. I will add you to my killfile at my pleasure. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-03 23:06 -0400 |
| Message-ID | <nqg33p$t6b$2@jstuckle.eternal-september.org> |
| In reply to | #44800 |
On 9/3/2016 10:49 PM, Mr Flibble wrote: > On 04/09/2016 02:49, Jerry Stuckle wrote: >> On 9/3/2016 6:51 PM, Mr Flibble wrote: >>> On 03/09/2016 23:25, Jerry Stuckle wrote: >>>> >>>> And those aren't insults. They are only the truth. Stoopid is as >>>> stoopid does. And you have proven yourself time and time again to be >>>> one of the worst. Starting when you claimed you couldn't determine >>>> whether a machine was big endian or little endian at compiler time, and >>>> I showed you wrong there, also. >>> >>> It is not possible with a standard conforming C++ compiler to determine >>> endianness at compile time. >>> >>> Boost does offer a header file with platform specific information on >>> endianness however. >>> >>> /Flibble >> >> BTW - I though you were going to killfile me. I knew you wouldn't, >> though. You have shown yourself to be much too obsessed with me. You >> really need to get help with that obsession. > > I will add you to my killfile at my pleasure. > > /Flibble > > Fine with me. Then I won't have to put up with your bullshit. But I know you won't. People like you are too obsessed. You need serious help. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | woodbrian77@gmail.com |
|---|---|
| Date | 2016-09-03 21:16 -0700 |
| Message-ID | <b2da929f-2d38-420b-bf57-704f7231b7c3@googlegroups.com> |
| In reply to | #44802 |
On Saturday, September 3, 2016 at 10:06:41 PM UTC-5, Jerry Stuckle wrote: Jerry, please don't swear here. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2016-08-31 21:08 +0100 |
| Message-ID | <Y72dnbN52ce3pFrKnZ2dnUU78TnNnZ2d@brightview.co.uk> |
| In reply to | #44630 |
On 31/08/2016 13:59, Melzzzzz wrote:
> Code in question is like this:
>
> struct Problem{
> uint32_t a;
> uint32_t b;
> uint64_t c;
> uint32_t d;
> bool check_it() {
> for (uint32_t* i = &a;i != &d; ++i)
> if (*i>0) return true;
> return false;
> }
>
> };
>
> I am not sure if this will work, so if someone has clear explanation
> why it will work (or not) , I would be grateful.
>
Depends what you mean by "work".
There is no guarantee that the first time you increment the pointer to
get from a it will point to b. There may be padding to ensure correct
alignment. Some processors require this, and IIRC the packed attribute
is not part of the C standard. Even then Gnu don't say exactly what it
packs to.
Andy
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2016-09-01 02:28 +0200 |
| Message-ID | <nq7sp3$eu4$1@dont-email.me> |
| In reply to | #44630 |
On 31.08.2016 14:59, Melzzzzz wrote:
> Code in question is like this:
>
> struct Problem{
> uint32_t a;
> uint32_t b;
> uint64_t c;
> uint32_t d;
> bool check_it() {
> for (uint32_t* i = &a;i != &d; ++i)
> if (*i>0) return true;
> return false;
> }
>
> };
>
> I am not sure if this will work, so if someone has clear explanation
> why it will work (or not) , I would be grateful.
Formally there can be padding (except before the first item), and
therefore formally you're in UB-land.
And the formal UB means that an impractical compiler, a perverse
compiler, can treat this as an opportunity to optimize away all of the
checking. After all if it incurs UB, then in a correct program it would
never be executed. So to the perverse compiler it's just dead code.
But assuming a non-perverse compiler, you can simply
static_assert( sizeof( Problem ) == 4*sizeof( uint32_t ) );
... and, under the no perversity assumption, that makes the code
portable in the sense that sometime in the future it simply won't
compile on the so far not yet created system where it wouldn't work.
Note: the /order/ of the items in memory is guaranteed, because there is
no intervening access specifier.
• • •
All that said, a safe alternative is to do this:
#include <algorithm>
#include <array>
#include <stdint.h>
namespace my {
using std::array;
struct Problem
{
using Item = uint32_t;
struct Id{ enum Enum{ a, b, c, d, _ }; };
array<Item, Id::_> items;
auto item( Id::Enum const id ) -> Item& { return items[id]; }
auto item( Id::Enum const id ) const -> Item const& {
return items[id]; }
auto check_it_in_change_resistant_way() const
-> bool
{
auto const p_last_item = &items[Id::_ - 1];
for( auto p = &items[Id::a]; p != p_last_item; ++p )
{
if( *p > 0 ) { return true; }
}
return false;
}
auto check_it_directly() const
-> bool
{ return (items[0] || items[1] || items[2]); }
};
} // namespace my
Cheers & hth.,
- Alf
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2016-09-01 01:28 -0700 |
| Message-ID | <c5221268-6e85-428e-a25f-fe61031a762f@googlegroups.com> |
| In reply to | #44646 |
On Thursday, 1 September 2016 03:29:35 UTC+3, Alf P. Steinbach wrote:
> On 31.08.2016 14:59, Melzzzzz wrote:
> > Code in question is like this:
> >
> > struct Problem{
> > uint32_t a;
> > uint32_t b;
> > uint64_t c;
> > uint32_t d;
> > bool check_it() {
> > for (uint32_t* i = &a;i != &d; ++i)
> > if (*i>0) return true;
> > return false;
> > }
> >
> > };
> >
> > I am not sure if this will work, so if someone has clear explanation
> > why it will work (or not) , I would be grateful.
>
> Formally there can be padding (except before the first item), and
> therefore formally you're in UB-land.
>
> And the formal UB means that an impractical compiler, a perverse
> compiler, can treat this as an opportunity to optimize away all of the
> checking. After all if it incurs UB, then in a correct program it would
> never be executed. So to the perverse compiler it's just dead code.
>
> But assuming a non-perverse compiler, you can simply
>
> static_assert( sizeof( Problem ) == 4*sizeof( uint32_t ) );
That assertion will fail on all platforms; it may be that you missed
the 'c' being 'uint64_t'.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-09-02 12:06 -0700 |
| Message-ID | <nqcik9$nt2$1@dont-email.me> |
| In reply to | #44646 |
On 8/31/2016 5:28 PM, Alf P. Steinbach wrote:
> On 31.08.2016 14:59, Melzzzzz wrote:
>> Code in question is like this:
>>
>> struct Problem{
>> uint32_t a;
>> uint32_t b;
>> uint64_t c;
>> uint32_t d;
>> bool check_it() {
>> for (uint32_t* i = &a;i != &d; ++i)
>> if (*i>0) return true;
>> return false;
>> }
>>
>> };
>>
>> I am not sure if this will work, so if someone has clear explanation
>> why it will work (or not) , I would be grateful.
>
> Formally there can be padding (except before the first item), and
> therefore formally you're in UB-land.
[...]
Right. So, this little program below should have no undefined behavior:
________________________________________________
#include <cstddef>
#include <cstdio>
struct A
{
int v;
};
struct B
{
A m_a0;
char c;
A m_a1;
};
int main()
{
B b = { { 0 }, 'c', { 1 } };
A* pa0 = &b.m_a0;
B* bp = reinterpret_cast<B*>(pa0);
unsigned char* a = reinterpret_cast<unsigned char*>(bp);
char* pc = reinterpret_cast<char*>(a + offsetof(B, c));
A* pa1 = reinterpret_cast<A*>(a + offsetof(B, m_a1));
pa0->v = 1;
*pc = '2';
pa1->v = 3;
std::printf("b.m_a0.v:%d\nb.c:%c\nb.m_a1.v:%d\n",
b.m_a0.v, b.c, b.m_a1.v);
return 0;
}
________________________________________________
This should be fine, A and B are POD's and work well with offsetof.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2016-09-05 02:21 -0700 |
| Message-ID | <94a91d34-4d3f-4d49-8608-cfbc653f92d2@googlegroups.com> |
| In reply to | #44630 |
On Wednesday, 31 August 2016 15:59:32 UTC+3, Melzzzzz wrote:
> Code in question is like this:
>
> struct Problem{
> uint32_t a;
> uint32_t b;
> uint64_t c;
> uint32_t d;
> bool check_it() {
> for (uint32_t* i = &a;i != &d; ++i)
> if (*i>0) return true;
> return false;
> }
>
> };
>
> I am not sure if this will work, so if someone has clear explanation
> why it will work (or not) , I would be grateful.
If to leave nitpicks that the code posted does not compile and if
to add missing include then it won't run aside then we have odd
member function. The member function looks like deliberate
sabotage that uses black magic of undefined behaviors to do
something simple like:
bool check_it() {
return a>0 || b>0 || c>0;
}
I may be wrong of course and it wasn't what it was meant to do.
What was its purpose?
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-09-05 13:38 +0200 |
| Message-ID | <20160905133847.77d7eea3@maxa-pc> |
| In reply to | #44857 |
On Mon, 5 Sep 2016 02:21:01 -0700 (PDT)
Öö Tiib <ootiib@hot.ee> wrote:
> On Wednesday, 31 August 2016 15:59:32 UTC+3, Melzzzzz wrote:
> > Code in question is like this:
> >
> > struct Problem{
> > uint32_t a;
> > uint32_t b;
> > uint64_t c;
> > uint32_t d;
> > bool check_it() {
> > for (uint32_t* i = &a;i != &d; ++i)
> > if (*i>0) return true;
> > return false;
> > }
> >
> > };
> >
> > I am not sure if this will work, so if someone has clear explanation
> > why it will work (or not) , I would be grateful.
>
> If to leave nitpicks that the code posted does not compile and if
> to add missing include then it won't run aside then we have odd
> member function. The member function looks like deliberate
> sabotage that uses black magic of undefined behaviors to do
> something simple like:
>
> bool check_it() {
> return a>0 || b>0 || c>0;
> }
>
> I may be wrong of course and it wasn't what it was meant to do.
> What was its purpose?
I ended up writing it like this.
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web