Monday, July 31, 2017

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

Juha Nieminen <nospam@thanks.invalid>: Jul 31 10:31AM

> Jesus Christ will forgive all who come to Him asking forgiveness.
> He will even forgive vile people. He wants to save us more than
> He wants to judge us because He loves us.
 
Why don't you just go away, you lying hypocrite piece of shit?
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 31 04:55AM -0700

It reads, "Love," Juha. "Love."
 
Much Love,
Rick C. Hodgin
Daniel <danielaparker@gmail.com>: Jul 31 07:54AM -0700

On Tuesday, July 25, 2017 at 7:28:30 AM UTC-4, Rick C. Hodgin wrote:
> Trust in God and God's ways. Live your life for Him.
 
And don't screw anyone unless they're bent over!
Real Troll <Real.Troll@Trolls.com>: Jul 31 05:17PM -0400

On 31/07/2017 15:54, Daniel wrote:
> And don't screw anyone unless they're bent over!
 
Instead of reading that idiot's posts why don't you try to learn
something new:
 
> poorly understood, confusing features of C++ that, in our experience,
> bring more
> grief than benefit.
 
The religious person is here to destroy these newsgroups and there are
people using profanity to indirectly support him in his objectives.
My filter list is getting bigger and bigger. Everybody should do the
same to reduce the traffic on this <and on C newsgroup> newsgroup.
woodbrian77@gmail.com: Jul 31 08:28AM -0700

Shalom
 
I want to join in the reindeer games here:
 
https://github.com/thekvs/cpp-serializers
 
, but when I run make, there's a problem when it tries
to build capnproto. Something about it not being able
to convert a template argument from bool to capnp::Kind.
What to do? Thanks.
 
 
Brian
Ebenezer Enterprises - Ben Shapiro over at dailywire.com
does a good job of figuring out who is telling the truth
and who is lying.
 
http://webEbenezer.net
David Brown <david.brown@hesbynett.no>: Jul 31 06:04PM +0200

> to build capnproto. Something about it not being able
> to convert a template argument from bool to capnp::Kind.
> What to do? Thanks.
 
I would suggest you start by reading
<http://www.catb.org/esr/faqs/smart-questions.html>. Then you might
like to think about whether people in this newsgroup could have the
slightest idea about how to help you with a third party build of a
fourth party library.
 
Following that reality check, you might then try to look at the error
message you got, and perhaps some of the source code. Look at the
readmes, documentation and build instructions, and see if you have
followed them correctly. Try contacting the github project maintainer,
or perhaps the capnproto maintainer.
 
woodbrian77@gmail.com: Jul 31 09:44AM -0700

On Monday, July 31, 2017 at 11:04:44 AM UTC-5, David Brown wrote:
> readmes, documentation and build instructions, and see if you have
> followed them correctly. Try contacting the github project maintainer,
> or perhaps the capnproto maintainer.
 
Hi David,
 
I did read the Readme, but noticed something now that I
didn't do. I'll try to do that and see what happens.
 
 
Brian
woodbrian77@gmail.com: Jul 31 10:10AM -0700


> Hi David,
 
> I did read the Readme, but noticed something now that I
> didn't do. I'll try to do that and see what happens.
 
I tried it now, but get the same problem. What I didn't do
was create a build directory and run cmake and make from
that directory. But now I tried it that way also and get the
same error. Thanks for the suggestion to contact the guy
who developed the benchmark. I sent him an email and asked
him about it.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
woodbrian77@gmail.com: Jul 31 01:52PM -0700

> same error. Thanks for the suggestion to contact the guy
> who developed the benchmark. I sent him an email and asked
> him about it.
 
I posted on a capnproto mailing list and got this reply:
 
It looks like the project you reference is hard-coded to
download Cap'n Proto version 0.5.3. The bug you describe
was fixed in 0.5.3.1 and 0.6.0. I suggest updating the
project to the current release, 0.6.1.
 
---------------------------------------------------------
 
These sorts of problems could be minimized by using
on-line code generators. But I know, that's crazy talk.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
"Öö Tiib" <ootiib@hot.ee>: Jul 31 12:39AM -0700

Leigh, why some people seem to think that they behaving kook does somehow
change anything in any direction in this world? It is just boring and aesthetically
ugly ... and that is it.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 31 05:02PM +0100

On 31/07/2017 08:39, Öö Tiib wrote:
> Leigh, why some people seem to think that they behaving kook does somehow
> change anything in any direction in this world? It is just boring and aesthetically
> ugly ... and that is it.
 
Being blasphemous isn't "kook"; blasphemy being a crime is "kook".
 
/Flibble
scott@slp53.sl.home (Scott Lurndal): Jul 31 12:25PM

>highest (BSR) set bit (a bit with a 1 in it).
 
> BSF: https://c9x.me/x86/html/file_module_x86_id_19.html
> BSR: https://c9x.me/x86/html/file_module_x86_id_20.html
 
$ info gcc --index-search=__builtin_ffs
$ info gcc --index-search=__builtin_clz
David Brown <david.brown@hesbynett.no>: Jul 31 02:36PM +0200

On 31/07/17 14:25, Scott Lurndal wrote:
>> BSR: https://c9x.me/x86/html/file_module_x86_id_20.html
 
> $ info gcc --index-search=__builtin_ffs
> $ info gcc --index-search=__builtin_clz
 
That is a fine mixture between useful and useless information. These
builtins in gcc are certainly useful references for Rick here, but the
best that can be said of "info" is that some people have got used to it
enough to find it useful. Web links will more helpful to most people:
 
<https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fclz>
 
<https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fctz>
 
<https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fffs>
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 31 08:36AM -0400

On 7/31/2017 8:25 AM, Scott Lurndal wrote:
>> BSR: https://c9x.me/x86/html/file_module_x86_id_20.html
 
> $ info gcc --index-search=__builtin_ffs
> $ info gcc --index-search=__builtin_clz
 
Thank you, Scott. I was able to find __builtin_ffs() and
__builtin_clz() here:
 
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
 
Thank you,
Rick C. Hodgin
scott@slp53.sl.home (Scott Lurndal): Jul 31 02:41PM

>builtins in gcc are certainly useful references for Rick here, but the
>best that can be said of "info" is that some people have got used to it
>enough to find it useful.
 
I can't disagree - I find 'info' almost useless. Give me a flat man
page anyday.
David Brown <david.brown@hesbynett.no>: Jul 31 04:58PM +0200

On 31/07/17 16:41, Scott Lurndal wrote:
>> enough to find it useful.
 
> I can't disagree - I find 'info' almost useless. Give me a flat man
> page anyday.
 
Man pages are good for small things. For larger references, I like pdf
files (they are also handy for referencing the exact version of gcc - I
have a dozen or so different versions on my system, for various
targets). But the web page versions are great for references like this.
scott@slp53.sl.home (Scott Lurndal): Jul 31 03:02PM

>files (they are also handy for referencing the exact version of gcc - I
>have a dozen or so different versions on my system, for various
>targets). But the web page versions are great for references like this.
 
$ man large-man-page | col -b > /tmp/b && vim /tmp/b && rm /tmp/b
 
A simple shell function.
Juha Nieminen <nospam@thanks.invalid>: Jul 31 10:41AM

> I think some kind of compiler switch which disables the forward-
> declaration requirement, allowing an additional pass to be run on
> source code to resolve unknown references would be desirable.
 
You can compile a compilation unit into an object file, a statically
linked file, or a dynamically linked file.
 
Even when compiling simply to an object file, the compiler might not,
at that point, have any access to the definition of a function in some
other source of object file. It's only at linking time that all the object
files come together.
 
How exactly is the compiler supposed to create the object file when it
can't see the function being called? This requires more than just a
function pointer to be set later. The parameters need to be put onto
the stack. The compiler can't know, without seeing the function
declaration, how it should put them there (eg. if you give an
int as parameter, but the function takes a double, the compiler
needs to do a conversion; it can't do that if it can't see that the
function is taking a double).
 
It becomes even more complicated with dynamically linked libraries.
Those may not be available at compile or even link time at all,
only at run time.
bartc <bc@freeuk.com>: Jul 31 11:56AM +0100

On 31/07/2017 11:41, Juha Nieminen wrote:
 
> It becomes even more complicated with dynamically linked libraries.
> Those may not be available at compile or even link time at all,
> only at run time.
I think you're posting at cross-purposes.
 
As I understand it, the proposal is about relaxing requirements for
forward declarations of functions in the /same/ translation unit.
 
Not for eliminating declarations of functions in other modules (ie.
pretty much doing away with header files). As those wouldn't be
/forward/ declarations (more sideways ones).
 
So it means being able to write this:
 
-----------------------------
int main(void) { fn(10,20);}
void fn(float a,int b) {}
-----------------------------
 
instead of:
 
-----------------------------
void fn(float,int); // forward declaration of fn
int main(void) { fn(10,20);}
void fn(float a,int b) {}
-----------------------------
 
or:
 
-----------------------------
void fn(float a,int b) {} // re-ordering functions
int main(void) { fn(10,20);}
-----------------------------
 
--
bartc
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 31 08:33AM -0400

On 7/31/2017 6:41 AM, Juha Nieminen wrote:
 
> It becomes even more complicated with dynamically linked libraries.
> Those may not be available at compile or even link time at all,
> only at run time.
 
I do not advocate forward-declarations that are unknown across
object files, but only within a single compilation.
 
In many cases doing this will fail:
 
#include "file1.h"
#include "file2.h"
 
...because there are dependencies in file1.h which require the
information that's declared in file2.h. You must order them as:
 
#include "file2.h"
#include "file1.h"
 
But what can also happen is file1.h and file2.h both have some
dependencies on each other, so that if any members are referenced
the compilation will fail.
 
My goal in removing the requirement of having forward-declaration
is to resolve this issue so that something needs only be defined
somewhere in the compilation, and not before it's first referenced.
 
Many other languages have done away with the forward-declaration
requirement. It seems to be a proper thing for a compiler running
on modern hardware in 2017.
 
There's nothing to prevent a compiler from NOT implementing the
relaxation, and to maintain things as they are. In fact, I think
it would be essential for this relaxation to be only a feature
that can be turned on, and not a default feature.
 
Thank you,
Rick C. Hodgin
Juha Nieminen <nospam@thanks.invalid>: Jul 31 10:30AM

> People do not earn their way into Heaven. It is the free gift of
> God to all who will receive Jesus, receive His sacrifice, and ask
> Him to forgive their sin.
 
You did not answer my post. Why? Because you know you are a liar and a
hypocrite.
 
You think that your words are magic, but they are not. They are nothing
but you being a condescending smug lying hypocrite.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 31 04:53AM -0700

Juha, you can find all kinds of failures with me. I am just
a man. But I'm not advocating me, nor my words, but
rather Jesus and His words.
 
You'll be unable to find fault with Him, or His words.
I need Him to forgive me just like everybody else does.
 
Thank you,
Rick C. Hodgin
"Öö Tiib" <ootiib@hot.ee>: Jul 31 05:03AM -0700

Rick, why some people seem to think that they behaving kook does somehow
change anything in any direction in this world? It is just boring and aesthetically
ugly ... and that is it.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 31 08:28AM -0400

On 7/31/2017 8:03 AM, Öö Tiib wrote:
> Rick, why some people seem to think that they behaving kook does somehow
> change anything in any direction in this world? It is just boring and aesthetically
> ugly ... and that is it.
 
I know. People only look at the person giving the message and,
because they are just a person like them, are able to label them
summarily with disparaging names like "kook" or "hypocrite."
 
They don't seem to realize the messenger is not the message, but
the one they're pointing to is the message.
 
That inability to receive the root message is the source of ALL
of the confusion involved. It breaks my heart because people
are willing to sacrifice hearing the true message and intent of
the message because they judge the messenger on his merits, and
the messengers unwaveringly come up short. It's such a loss.
 
-----
I do not advocate Rick. Or any other pastor, preacher,
evangelist, or teacher. I would not point you to them for any
salvation or true help. I would point you only to Jesus Christ.
And then, after you have found merit in Jesus Christ, I would
point you to others who can help teach you those things He first
taught us, but only then under the direct, purposeful, and focused
scrutiny of a discerning heart, one who compares anything we might
say with the true and foundational words of Jesus Christ. What we
teach must align with His teachings, or else they have no merit,
and are to be rebuked. But if they do align with His teachings,
then it is as though He is teaching you directly ... He's just
doing so through us and our conveyance of His message for you.
 
Thank you,
Rick C. Hodgin
red floyd <no.spam@its.invalid>: Jul 30 08:57PM -0700


> Brian
> Ebenezer Enterprises - Be joyful, patient and faithful.
> http://webEbenezer.net
 
Fuck off. And, he's not swearing as the bible defines it, so fuck
off again.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: