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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-02 16:32 -0400 |
| Message-ID | <nqcnk5$9as$1@jstuckle.eternal-september.org> |
| In reply to | #44755 |
On 9/2/2016 2:36 PM, David Brown wrote:
> On 02/09/16 18:49, Jerry Stuckle wrote:
>> On 9/2/2016 11:59 AM, David Brown wrote:
>>> On 02/09/16 14:50, Jerry Stuckle wrote:
>>>> On 9/2/2016 3:35 AM, David Brown wrote:
>>>>> On 02/09/16 03:02, Jerry Stuckle wrote:
>
> <snip>
>
>>>>> Secondly, as long as we are talking about memory that can only be seen
>>>>> from within the program (while following the rules of C), memory
>>>>> layout
>>>>> is nothing more than an effect of execution. The way a struct is laid
>>>>> out is not observable behaviour in itself, and thus the compiler is
>>>>> free
>>>>> to change it.
>>>>>
>>>>
>>>> The struct layout is observable behavior, and cannot be changed.
>>>> 9.2.13
>>>> says so.
>>>
>>> No, 9.2.13 says nothing about observable behaviour. Read it again, and
>>> see if you spot that phrase. And in the definition of observable
>>> behaviour (section 1.9.8), no mention is made of struct layout or memory
>>> (except in regard to volatile accesses).
>>>
>>> You are simply wrong here. You are making things up that are not in the
>>> standards.
>>>
>>
>> No, you are making up things which are not what the standard says. No,
>> section 1.9.8 doesn't say anything about struct layout. That is not its
>> purpose.
>>
>
> I did not say that 1.9.8 discussed the layout of structs - I said it did
> /not/ cover struct layout.
>
That is correct. Because 1.9.8 does not apply to structs (neither does
1.9.1).
>> And 1.9.1 refers to the remainder of section 1.9, not the entire
>> standard. Plus, 1.9 refers to program execution - not memory layout.
>> Layout is not behavior.
>
> 1.9.1 refers to the observable behaviour, which is defined "below" in
> 1.9.8. Section 1.9.8 refers to the entire rest of the standard.
>
> And memory layout is behaviour.
>
No, there is a difference. But you don't understand that.
>>
>> 1.9.1 is for things like the following:
>>
>> a = 2;
>> b = 3;
>> c = 2;
>>
>> Can be reordered to
>>
>> a = c = 2;
>> b = 3;
>>
>> Of course it's more than that. But to stay in line with what you can
>> understand, I'm keeping it simple.
>
> It covers /vastly/ more than that. It is the basis for the concept of
> an "optimising compiler".
>
As I said - it's a SIMPLIFIED EXAMPLE - meant for a SIMPLE MIND.
>>
>>>>
>>>>> It is /not/ free to change struct layout when that data is passed to
>>>>> external functions, written to files, or has volatile behaviour -
>>>>> those
>>>>> are observable effects. But if the data stays within the program as
>>>>> known to the compiler, the compiler is free to do as it wants.
>>>>>
>>>>
>>>> Sorry, you are once again wrong. The compiler doesn't know what a
>>>> function does. You are really grasping at straws now, David.
>>>
>>> If the compiler does not know what a function does (such as for external
>>> functions), then it must assume the worst - it must assume it has
>>> volatile accesses to all globally visible data, for example, and thus
>>> any such data must follow the rules for struct layout. But it can
>>> assume that the external function has defined behaviour - and thus
>>> cannot read local data or file static data that has not escaped in some
>>> way, and it can re-arrange such data as it likes.
>>>
>>
>> And how is the compiler to know that? Does it predict the future?
>>
>> struct mystruc {
>> int a, b;
>> };
>>
>> func f() }
>> struct mystruct ms;
>> ms.a = 1; // The structure has been defined
>> ms.b = 2;
>> write(ms); // NOW the compiler knows that there is a call
>> }
>>
>> It is a one-pass compiler. There is no way for it to know when
>> assigning ms.a that there is going to be a call to another function.
>>
>
> That was perhaps true in the days when compilers read programs on
> punched cards. But these days, compilers are smarter than that. Before
> the compiler generates anything for "ms.a", it has already parsed all
> the rest of the file - and perhaps all the other files in the program.
>
> Perhaps you use a one-pass compiler, with all its limitations. I don't
> know how many passes modern gcc or clang have, but according to a quick
> google gcc 4.6.2 had 207 unique passes.
>
How about - ONE PASS. But then you need to see what each of those
unique passes does. Here's a hint: 206 of them are for code
optimization - not memory layout.
That's why in C anything must be declared before it can be used.
>
>>
>>> And if the compiler knows the definition of the function, then it will
>>> know which re-arrangements and optimisations are safe. With
>>> whole-program or link-time optimisation, the compiler may even know the
>>> definitions of every function in the program.
>>>
>>
>> Not before the structure has been defined.
>
> The compiler collects all the information about the program, data,
> structures, functions, etc., before it starts organising the data or
> generating the code. That's the point of whole-program optimisation.
>
Once again you are mistaken.
>>
>>>>
>>>> Just admit you are wrong and move on. Or explain why 9.2.13 exists,
>>>> when according to you, it is meaningless.
>>>>
>>>
>>> No, only you have claimed it is meaningless. I am quite happy with its
>>> meaning.
>>>
>>
>> No, you said the compiler is free to reorder the memory. That is in
>> direct conflict with 9.2.13. So it is you who declare it meaningless.
>
> Yes, the compiler is free to re-order anything it likes - code,
> functions, memory, structs, whatever - as long as the observable
> behaviour is unchanged.
>
Not according to 9.2.13. But you don't understand plain English.
>>
>> You are just digging yourself a deeper and deeper hole,
>>
>
> You simply don't understand much about how compilers work. That's okay,
> you don't have to know how they work in order to use them. But you do
> look silly by continuing to flaunt your ignorance.
>
> But keep going, if you like - it is somewhat entertaining. The idea
> that a modern C compiler is one-pass and generates the code for one line
> of source before reading the next line gave me a bit of a chuckle.
>
I understand completely how compilers work. I've worked on more of them
than you have. And yes, they are one pass through the source code. The
other passes are for optimization - which does NOT include reordering
structs.
But you don't understand standards.
But then trolls like you never were very smart. And you just continue
to dig yourself into deeper and deeper holes.
--
==================
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-03 18:08 +0200 |
| Message-ID | <nqeshc$97s$1@dont-email.me> |
| In reply to | #44759 |
On 02/09/16 22:32, Jerry Stuckle wrote: <snip> Jerry, you are wrong. You are talking absolute nonsense. You are talking such complete and utter rubbish, that I suspect you actually /do/ know a little about how compilers work - it would be hard to get so many things wrong in so many ways by sheer idiocy and ignorance, so at least part of what you write must be intentionally wrong. I can only suppose you think it is fun to post this sort of stuff to wind people up. Certainly that seems to be the only motivation for the extraordinary levels of hatred and bile you pour out at people on Usenet, and the totally unjustified insults you come out with. What a sad, lonely little life you must lead when you gain pleasure from trying to push other people down.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-03 18:25 -0400 |
| Message-ID | <nqfiku$ma7$1@jstuckle.eternal-september.org> |
| In reply to | #44785 |
On 9/3/2016 12:08 PM, David Brown wrote: > On 02/09/16 22:32, Jerry Stuckle wrote: > > <snip> > > Jerry, you are wrong. You are talking absolute nonsense. You are > talking such complete and utter rubbish, that I suspect you actually > /do/ know a little about how compilers work - it would be hard to get so > many things wrong in so many ways by sheer idiocy and ignorance, so at > least part of what you write must be intentionally wrong. > > I can only suppose you think it is fun to post this sort of stuff to > wind people up. Certainly that seems to be the only motivation for the > extraordinary levels of hatred and bile you pour out at people on > Usenet, and the totally unjustified insults you come out with. What a > sad, lonely little life you must lead when you gain pleasure from trying > to push other people down. > Sorry, David. Once again you are throwing out the standards, based on your incorrect assumptions. But such is the life of language lawyers who think they know what is going on - but have absolutely no clue. 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. The bottom line is - you don't know 10% of what you think you know. And you never will until you humble up and figure out a lot of people know more than you do - most of the world, in fact. But then it seems many of the people in this newsgroup are in the same boat. And FYI - the first compiler I wrote was a FORTRAN compiler in the early 70's in IBM 360 assembler. It was a side project since I had access to a mainframe at the time. One other thing - I lead a very happy life. One thing I have learned over the years. I don't have to put up with stoopid idiots or trolls. Life is too short to worry about what they think of me. When you start paying me what my clients do or otherwise make a positive difference in my life, I will start to care. Until then, you're not worth my worrying about. -- ================== 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-03 23:51 +0100 |
| Message-ID | <2Madnet9i-VrzlbKnZ2dnUU7-TvNnZ2d@giganews.com> |
| In reply to | #44793 |
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
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-03 21:48 -0400 |
| Message-ID | <nqfuhe$i2d$1@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 Wrong again - as I showed here several months ago. However, I know it is well beyond your limited level of comprehension. -- ================== 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:48 +0100 |
| Message-ID | <-9mdnW6-c-MSFlbKnZ2dnUU7-KWdnZ2d@giganews.com> |
| In reply to | #44797 |
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
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-03 23:05 -0400 |
| Message-ID | <nqg324$t6b$1@jstuckle.eternal-september.org> |
| In reply to | #44799 |
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. 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. -- ================== 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 05:02 +0100 |
| Message-ID | <P8Odne-pF45XAVbKnZ2dnUU7-X2dnZ2d@giganews.com> |
| In reply to | #44801 |
On 04/09/2016 04:05, 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. > > 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. Nope, it is not possible to determine endianness with a standard conformant C++ compiler at compile time. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-04 10:57 +0100 |
| Message-ID | <87d1kk0yz2.fsf@bsb.me.uk> |
| In reply to | #44803 |
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". -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-04 09:40 -0400 |
| Message-ID | <nqh88r$2gq$1@jstuckle.eternal-september.org> |
| In reply to | #44809 |
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. -- ================== 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 16:39 +0100 |
| Message-ID | <woSdnWeQ87a_3VHKnZ2dnUU7-bXNnZ2d@giganews.com> |
| In reply to | #44812 |
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
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-04 12:46 -0400 |
| Message-ID | <nqhj4u$753$1@jstuckle.eternal-september.org> |
| In reply to | #44819 |
On 9/4/2016 11:39 AM, 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 The requirement was to determine at compile time whether the system is big endian or little endian. My solution satisfied that requirement. End of story. No wonder you can't land a decent job. -- ================== 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 17:51 +0100 |
| Message-ID | <Ba-dnTaggJV2zVHKnZ2dnUU7-bHNnZ2d@giganews.com> |
| In reply to | #44822 |
On 04/09/2016 17:46, Jerry Stuckle wrote: > On 9/4/2016 11:39 AM, 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 > > The requirement was to determine at compile time whether the system is > big endian or little endian. My solution satisfied that requirement. > End of story. > > No wonder you can't land a decent job. From the latest printing of the Oxford English Dictionary: obtuse Pronunciation: /əbˈtjuːs/ ADJECTIVE 1. Jerry Stuckle 'He wondered if this was another case of deliberate Jerry Stuckleness' /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-04 13:07 -0400 |
| Message-ID | <nqhkbt$cbp$1@jstuckle.eternal-september.org> |
| In reply to | #44823 |
On 9/4/2016 12:51 PM, Mr Flibble wrote: > On 04/09/2016 17:46, Jerry Stuckle wrote: >> On 9/4/2016 11:39 AM, 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 >> >> The requirement was to determine at compile time whether the system is >> big endian or little endian. My solution satisfied that requirement. >> End of story. >> >> No wonder you can't land a decent job. > > From the latest printing of the Oxford English Dictionary: > > obtuse > Pronunciation: /əbˈtjuːs/ > ADJECTIVE > 1. Jerry Stuckle > 'He wondered if this was another case of deliberate Jerry Stuckleness' > > /Flibble > > Your obsession with me is quite sick. But then that's just like the troll you are. I suggest you seek psychiatric help quickly. -- ================== 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 18:37 +0100 |
| Message-ID | <ivKdnc7uVfd8xlHKnZ2dnUU7-fmdnZ2d@giganews.com> |
| In reply to | #44827 |
On 04/09/2016 18:07, Jerry Stuckle wrote: > Your obsession with me is quite sick. But then that's just like the > troll you are. > > I suggest you seek psychiatric help quickly. You think I am obsessed with you yet I am on the verge of killfiling you now that I have the full measure of you. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-04 17:16 -0400 |
| Message-ID | <nqi2uk$1li$1@jstuckle.eternal-september.org> |
| In reply to | #44831 |
On 9/4/2016 1:37 PM, Mr Flibble wrote: > On 04/09/2016 18:07, Jerry Stuckle wrote: >> Your obsession with me is quite sick. But then that's just like the >> troll you are. >> >> I suggest you seek psychiatric help quickly. > > You think I am obsessed with you yet I am on the verge of killfiling you > now that I have the full measure of you. > > /Flibble > > ROFLMAO! You are so obsessed you need to reply to every post I make - even those not addressed to you. Please - for your own sake, get help. The sooner the better. -- ================== 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 22:23 +0100 |
| Message-ID | <FMedneiWy6YrDVHKnZ2dnUU7-b2dnZ2d@giganews.com> |
| In reply to | #44837 |
On 04/09/2016 22:16, Jerry Stuckle wrote: > On 9/4/2016 1:37 PM, Mr Flibble wrote: >> On 04/09/2016 18:07, Jerry Stuckle wrote: >>> Your obsession with me is quite sick. But then that's just like the >>> troll you are. >>> >>> I suggest you seek psychiatric help quickly. >> >> You think I am obsessed with you yet I am on the verge of killfiling you >> now that I have the full measure of you. >> >> /Flibble >> >> > > ROFLMAO! You are so obsessed you need to reply to every post I make - > even those not addressed to you. I reply to any of your posts that are blatantly incorrect: the problem is that that is the case for almost 100% of them. > > Please - for your own sake, get help. The sooner the better. Classic example of psychological projection. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-04 18:54 -0400 |
| Message-ID | <nqi8ns$ktn$1@jstuckle.eternal-september.org> |
| In reply to | #44841 |
On 9/4/2016 5:23 PM, Mr Flibble wrote: > On 04/09/2016 22:16, Jerry Stuckle wrote: >> On 9/4/2016 1:37 PM, Mr Flibble wrote: >>> On 04/09/2016 18:07, Jerry Stuckle wrote: >>>> Your obsession with me is quite sick. But then that's just like the >>>> troll you are. >>>> >>>> I suggest you seek psychiatric help quickly. >>> >>> You think I am obsessed with you yet I am on the verge of killfiling you >>> now that I have the full measure of you. >>> >>> /Flibble >>> >>> >> >> ROFLMAO! You are so obsessed you need to reply to every post I make - >> even those not addressed to you. > > I reply to any of your posts that are blatantly incorrect: the problem > is that that is the case for almost 100% of them. > Sorry, the post was completely correct. You didn't even know the question, so how could you say the answer was "blatantly incorrect"? Oh, that's because of your obsession with me. You think anything I say is incorrect. >> >> Please - for your own sake, get help. The sooner the better. > > Classic example of psychological projection. > > /Flibble > > Yes, and you have a really bad case of it - in addition to your obsession with me. You need serious help. -- ================== 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-04 09:58 -0700 |
| Message-ID | <2606af01-3c31-4159-b672-0dbfe0c98555@googlegroups.com> |
| In reply to | #44822 |
Jerry Stuckle wrote: > No wonder you can't land a decent job. Is this the best way to help someone, Jerry? You profess to know Jesus Christ as Lord and Savior ... is this what He said to the woman caught in the act of adultery? "No wonder you can't be faithful to your husband" ... Or did He say, "Neither do I condemn you. Go, and sin no more" ? Who are you serving with belittling speech? Is it Jesus Christ? Or is there another spirit who seeks to belittle and demean? Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-04 13:08 -0400 |
| Message-ID | <nqhke4$cbp$2@jstuckle.eternal-september.org> |
| In reply to | #44825 |
On 9/4/2016 12:58 PM, Rick C. Hodgin wrote: > Jerry Stuckle wrote: >> No wonder you can't land a decent job. > > Is this the best way to help someone, Jerry? You profess to know > Jesus Christ as Lord and Savior ... is this what He said to the woman > caught in the act of adultery? "No wonder you can't be faithful to > your husband" ... Or did He say, "Neither do I condemn you. Go, > and sin no more" ? > > Who are you serving with belittling speech? Is it Jesus Christ? Or is there > another spirit who seeks to belittle and demean? > > Best regards, > Rick C. Hodgin > Rick, I've tried to help Flibbie multiple times. He is incapable of learning. And I don't need any of your self-righteous preaching. Take it to an appropriate newsgroup - as so many have asked you to do. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web