Tuesday, September 18, 2018

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

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 18 08:32AM -0400

On 9/18/2018 2:22 AM, David Brown wrote:
> A "new life" does not make it better.
 
When the new life is the spirit life God gave us, kept from us by
sin, given back to us by Jesus for free ... it is amazing. It is
that spirit which provides the "peace that surpasses all under-
standing."
 
You don't know what you're missing, David. You can't know, just
as a blind person cannot know what it's like to see, or a deaf
person what it's like to hear.
 
But what you're missing ... would bring you such joy, such love,
such peace. It would be like you were paroled and the weight of
condemnation lifted off you.
 
You should read The Pilgram's Progress, or listen to the audio
book for free, which centers around the character called simply,
"Christian":
 
https://www.youtube.com/watch?v=p6nVY89aDlM
Dramatized: https://www.youtube.com/watch?v=WCb3RGkQ2_8
Download YouTube videos at y2mate.com (no www. prefix)
 
It describes the burden he carries, and how it fell off at the
foot of the cross, and how the many different sorts of influences
in this world affect him in his walk.
 
> What you fail to understand is that no one wants your life.
 
I understand. The Bible speaks volumes on this point. No un-
saved person in their sin can want what God offers, because what
God offers condemns the person, holds them guilty of sin.
 
It requires the drawing of God to be able to be saved, which is
why no one not being saved will ever come to understand, believe,
or know what I'm talking about (John 6:44).
 
This message is not written for them. It's only written for they
who are being saved.
 
> We can see how
> it ruins you as a person.
 
It changes them so their focus is on the things of God, and not
the things of this world.
 
> Christianity does not ruin people.  Bigotry, hypocrisy, hatred, and the weird
> mix of self-loathing and narcissism from unthinking unquestioning religious
> zealots ruins people.
 
The enemy still works against our flesh, causing many people who
are Christians to behave inappropriately. But it is the message
God Himself teaches us through scripture which is offensive to
our sinful flesh.
 
What God gives us is freedom from sin, new spiritual life, a new
focus on eternity and the things of God, rather than this world
and the things of importance here.
 
What you call "bigotry, hypocrisy, hatred... etc" are often seen
in people who profess Christianity, but God does not call any of
us to be that way. He calls us to go forth and teach the people
in love, to live for Him rightly, to pursue holiness actively,
and to teach other people to do the same.
 
You are seeing the effects of the enemy's influence not just in
those who are unsaved in the world, but also against Christians,
those who are saved, but are made weak by the enemy of this world.
 
None of us are immune to that enemy, but God does give us the
power, authority, and ability to overcome that enemy when we step
up and pursue Him and say no to that enemy.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 18 08:38AM -0400

On 9/18/2018 2:24 AM, David Brown wrote:
> Sometimes people - given the choice and the money - buy expensive race cars.
> And sometimes they buy trucks.
 
> There is a place in this world for all sorts of folks,
 
Yes.
 
> and all sorts of
> attractions.
 
No. There are some things God prohibits us from doing. Even those
who do not recognize God as God are prohibited from doing them, and
they will find out on that day of judgment how wrong they were, that
even in their professed ignorance against God, yet did they know the
truth in their core. They rejected that truth and stood in full-on
rebellion against God.
 
> The trick, as a man, is to find a good partner before the hair falls off the
> top of your head and lands on your back.
 
No. The calling of God is to come to Jesus and ask forgiveness for
your sin, and then seek of Him the mate He has for you. Some people
are called to a life of service to God without a spouse. Others are
called to have a family.
 
It is unto the one true God first, all other things second. That is
the true and right way for all people ... even atheists and agnostics
and those who believe in other religions. They will all learn that
was their true, ongoing, unending calling, when they face Him on that
final day of judgment.
 
It's why the message goes out today. Jesus came /HERE/ to save us.
We can still be saved /HERE/. After we leave this world, salvation
is no longer possible.
 
The message goes forth to save men's souls from judgment and eternal
damnation. But because of the nature of sin, only those who are be-
ing saved will be saved. The rest will perish in their sin seemingly
unaware of the fate their facing, but that burden explained in The
Pilgrim's Progress does know the truth as it was put there by God so
they would know truly, and it will bear witness against them on that
final day of judgment.
 
You are pursuing lies and false beliefs, David. You are headed to
literal eternal Hellfile. If even the possibility of that end exists
in your thinking you owe it to yourself to seek out the truth fully,
and to know for sure, to remove all doubt and cast aside all former
beliefs to the contrary.
 
Your eternity is on the line, sir. I would guide you to your better
end, and not for my sake, but for your and my sake.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Sep 18 02:50PM +0200

On 18/09/18 14:32, Rick C. Hodgin wrote:
 
> But what you're missing ... would bring you such joy, such love,
> such peace. It would be like you were paroled and the weight of
> condemnation lifted off you.
 
As I have said before, you know /nothing/ about me. You judge me and
others based on your own little tiny perspective without the slightest
concept of what others might know, or have experienced. /Nothing/ you
say here is new to me. I know fine what these sorts of feelings are.
The difference between us is that you believe they are a result of god,
and I understand the psychology behind them and how they arise without
any divine intervention. I have seen this "weight lifted off" from
people - I know how real and dramatic it is, and I know how it convinces
people of the existence of god, and I know how it happens without any
need for miraculous or divine explanations.
 
I /do/ know what I am missing, and I am happy to be missing it.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 18 08:55AM -0400

On 9/18/2018 8:50 AM, David Brown wrote:
>> such peace. It would be like you were paroled and the weight of
>> condemnation lifted off you.
 
> As I have said before, you know /nothing/ about me.
 
As I have said before, you broadcast your witness, David. It
is me comparing your witness to the teachings of Christ, and
/ASSESSING/ (not judging) your state.
 
You are without God today, and you are pursuing the things of
your life without God today. God has taught us through the
Holy Bible, and it is confirmed by His Holy Spirit alive in
us, that such a life leads only to eternal Hellfire.
 
> I /do/ know what I am missing, and I am happy to be missing it.
 
You don't know. You think you do, but you don't. I was the
same way before I was born again.
 
Someday you will know, and you will weep tears unimaginable ...
either here on this Earth, or as you are facing the lake of fire
you are being tossed into.
 
This is not just you. This is all people who reject Jesus
Christ's free offer of salvation.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Sep 18 03:53PM +0200

On 18/09/18 14:55, Rick C. Hodgin wrote:
>>> condemnation lifted off you.
 
>> As I have said before, you know /nothing/ about me.
 
> As I have said before, you broadcast your witness, David.
 
You know what I write. You do not know me, my knowledge, my
experiences, my past. You are judging me from a state of ignorance.
And there is no "witness" involved - there is no need to use such
meaningless terms.
 
> It
> is me comparing your witness to the teachings of Christ, and
> /ASSESSING/ (not judging) your state.
 
No, you /judge/. You judge yourself to be superior, and others who do
not follow /exactly/ the same beliefs as being inferior (but perhaps
with a hope of becoming superior beings like yourself, if only they
change). A few people occasionally get to sit beside you as Christians
- such as Brian, at the moment. Usually sooner or later there is a
conflict of opinion and they will be judged not to be /real/ Christians
by the Rick standard, and they are down in the pits with the rest of us.
 
 
> your life without God today. God has taught us through the
> Holy Bible, and it is confirmed by His Holy Spirit alive in
> us, that such a life leads only to eternal Hellfire.
 
God exists for you - for many other people, there is no god. And most
of us are glad there is no god in the way you describe, because such a
god would be /seriously/ evil.
 
 
>> I /do/ know what I am missing, and I am happy to be missing it.
 
> You don't know. You think you do, but you don't. I was the
> same way before I was born again.
 
In your arrogance, you think that everyone is like you. You are wrong.
You /really/ should try to open your eyes sometime - you are completely
blind to the world around you.
Ralf Goertz <me@myprovider.invalid>: Sep 18 12:56PM +0200

Hi,
 
when I just tried to use uint8_t instead of int in a program (because of
memory issues), I ran into the following problem:
 
#include <iostream>
 
int main() {
uint8_t i;
std::cin>>i;
int j=i;
std::cout<<j<<"\n";
}
 
Running this program and entering 4 results in the output of 52. I am
aware that this because uint8_t is typedef'ed to unsigned char so my
input is actually the character '4' which has ASCII code 52. However, I
had the impression that those [u]intX_t types were there so that I can
do math with them, not to deal with characters.
 
So what is the canonical way to input/output integral types of varying
size (in my actual program I use templates)?
David Brown <david.brown@hesbynett.no>: Sep 18 01:08PM +0200

On 18/09/18 12:56, Ralf Goertz wrote:
> do math with them, not to deal with characters.
 
> So what is the canonical way to input/output integral types of varying
> size (in my actual program I use templates)?
 
For local variables, use "int" or "unsigned int" unless you need
specific sizes. You won't save space by using uint8_t or int8_t in
locals (unless you are working on an 8-bit microcontroller - in which
case cin and cout are your problem).
 
You are right to use int8_t and uint8_t rather than "char", "signed
char" or "unsigned char" for arithmetic - but that is because they are
more appropriate names for the task, not because they are actually
different types.
Ralf Goertz <me@myprovider.invalid>: Sep 18 02:19PM +0200

Am Tue, 18 Sep 2018 13:08:22 +0200
> specific sizes. You won't save space by using uint8_t or int8_t in
> locals (unless you are working on an 8-bit microcontroller - in which
> case cin and cout are your problem).
 
I don't care about single variables. I deal with
set<vector<my_int_type>> where the values within the vector are usually
rather small. But they don't always fit in a byte. That's why I need
flexibility. And the values are to be read in from cin or similar.
 
> char" or "unsigned char" for arithmetic - but that is because they are
> more appropriate names for the task, not because they are actually
> different types.
 
I find it disturbing that these types behave differently when used with
cin/cout depending on the number in the type's name although the values
read in are within the range common to all of them. I'm curious, AFAIK
there are systems where char is more than 8 bit. So int8_t can't be
typedef'ed to char. What would my program print in those systems?
Sam <sam@email-scan.com>: Sep 18 08:36AM -0400

Ralf Goertz writes:
 
> input is actually the character '4' which has ASCII code 52. However, I
> had the impression that those [u]intX_t types were there so that I can
> do math with them, not to deal with characters.
 
Well, I have some good news for you. You can do all the math you want with
them. You can add them, subtract them, multiply and divide them, and do
anything with them that you can also do with their bigger cousins.
 
And you don't even have to formally use int8_t.
 
char two=2
char four=two+two;
 
> So what is the canonical way to input/output integral types of varying
> size (in my actual program I use templates)?
 
That's the only thing. Formatted input and output operators interpret
anything declared as a char to be a character or a character string, and
treat it as such.
 
There are many ways to deal with this. There is no "canonical" way.
David Brown <david.brown@hesbynett.no>: Sep 18 02:53PM +0200

On 18/09/18 14:19, Ralf Goertz wrote:
> set<vector<my_int_type>> where the values within the vector are usually
> rather small. But they don't always fit in a byte. That's why I need
> flexibility. And the values are to be read in from cin or similar.
 
Then read the values in as "int", check them properly, and store them in
your vector of appropriate type.
 
> read in are within the range common to all of them. I'm curious, AFAIK
> there are systems where char is more than 8 bit. So int8_t can't be
> typedef'ed to char. What would my program print in those systems?
 
On systems with char greater than 8 bit, there are no types int8_t and
uint8_t. C and C++ do not support any types (expect bitfields, but they
are a bit odd) smaller than "char".
Ralf Goertz <me@myprovider.invalid>: Sep 18 03:13PM +0200

Am Tue, 18 Sep 2018 08:36:05 -0400
 
> And you don't even have to formally use int8_t.
 
> char two=2
> char four=two+two;
 
Why do I deserve your condescending tone? What made you think I wouldn't
know that?
 
 
> That's the only thing. Formatted input and output operators
> interpret anything declared as a char to be a character or a
> character string, and treat it as such.
 
I also know that. What I didn't know (but figured out before asking my
question) was that uint8_t and unsigned char are actually the same type
(on my platform). This fact renders this type useless for my purpose.
Therefore, the question arose, how can I deal with integral types of
different sizes in a template-friendly way when they are also to be read
in using formatted input.
 
> There are many ways to deal with this. There is no "canonical" way.
 
And that's what is surprising to me. I understand that it is nice to
have typenames that explicitly tell you their size. But why stop there?
Why can't those types be arithmetic types which behave like their
"bigger cousins"? If you need character types you can always use
(unsigned) char. There is no point in using [u]int8_t for that. But why
do I need to bend over backwards to deal with the special case of 8 bit?
David Brown <david.brown@hesbynett.no>: Sep 18 03:47PM +0200

On 18/09/18 15:13, Ralf Goertz wrote:
 
> I also know that. What I didn't know (but figured out before asking my
> question) was that uint8_t and unsigned char are actually the same type
> (on my platform).
 
They are likely to be the same type on any platform for which uint8_t
exists. In theory, uint8_t and int8_t could be "extended integer types"
- in practice you won't find that.
 
This is an oddity that C++ inherited from C, and unfortunately you are
stuck with it.
 
> Therefore, the question arose, how can I deal with integral types of
> different sizes in a template-friendly way when they are also to be read
> in using formatted input.
 
As I said, use "int" for your input and check it - then assign it to
int8_t (or int16_t, or whatever).
 
Other than that, you can make your own types and use them.
 
> "bigger cousins"? If you need character types you can always use
> (unsigned) char. There is no point in using [u]int8_t for that. But why
> do I need to bend over backwards to deal with the special case of 8 bit?
 
int16_t and uint16_t do not behave like their larger cousins either,
assuming 32-bit int. They are closer than int8_t and uint8_t, but not
identical.
 
Remember, these are /not/ new types - they are typedefs, or alternative
names for existing types. "uint8_t" is /exactly/ the same as "unsigned
char". "int16_t" is (on most implementations) /exactly/ the same as
"signed short".
 
You could happily make some classes that really are new types, and
really act like pure integers of different sizes - but you'd have to
make them.
boltar@cylonHQ.com: Sep 18 09:33AM

On Tue, 18 Sep 2018 11:13:48 +0200
>reasons for this - these languages are dynamic, managed languages with
>good string support and with standard libraries for handling network
>protocols of all sorts.
 
And they can be more easily sandboxed and restricted. I suspect the real
reason for no C or C++ support in serverless systems (Amazon does support it
but only on EC2 which is little more than a fancy VM host anyway) is that
these companies don't want raw binaries running on their systems because A) it
could be a security risk and B) it might restrict them to a particular
processor architecture as perhaps in the future they might switch to ARM for
example.
 
>choosing Python rather than C++. But that doesn't mean C++ can't
>benefit from looking at them and thinking how it would be best to solve
>the same problems in the C++ world.
 
Why? As I said, people who want to solve these sorts of problems are not going
to bother with C++ since the language is so large now no sane person is going
to bother to learn it from scratch. If I didn't know it already I certainly
wouldn't.
 
>that have no obvious connection to the duck-like features you want.
>Enter "concepts" that give you this, and you have many of the benefits
>of duck-typing in a statically compiled and checked language.
 
If you want duck typing just use python.
 
>Python has strings, dictionaries, lists, with automatic memory
>management. Enter the C++ standard library which gives you these -
>albeit with a somewhat less pleasant syntax.
 
Which has been around for decades and is not part of the language per-se.
 
>run-time, making it simple to write things like JSON serialisers and
>deserialisers, or match classes to database tables. Enter C++
>introspection and metaclasses, coming Real Soon Now!.
 
Whoppee, I can hardly wait. Serialised json is just json. Its not binary, it
doesn't have any word byte order conversions to worry about nor does it store
BLOBs. If you simply want to compress it then you could do that in C, never
mind C++.
 
>As a fine example, look at the "safe boolean idiom". It used to be
 
Not only have I never used that idiom, I've never even written code that
needed it. A lot of these "solutions" are problems created by over complicated
code written by people trying to be clever rather than solving the actual
problem at hand. Hands up how many people have seen an entire factory framework
when a simple STL container would have done the same job?
 
>Look at template code today - it is often full of enable_if's, SFINAE
 
Had to look up enable_if, never heard of it. If your templates get that
complex then maybe for sanitys sake just bin them and use non templated
functions and classes even if it means more code.
 
>Metaclasses will be another revolution in letting people write C++ code
>in a simpler and clearer way, and letting people write more useful
>libraries.
 
Yeah, right.
 
>The C++ language has become more complicated and gained new features, in
>order to make C++ /programming/ easier. That's a win as far as I can see.
 
Yes, I can see from the enable_if example page how it makes programming
easier.
 
https://en.cppreference.com/w/cpp/types/enable_if
 
I can't even be bothered to figure it out. Frankly I'd sooner code in
assembler again than have to fuck about with that sort of mess.
David Brown <david.brown@hesbynett.no>: Sep 18 12:26PM +0200

> could be a security risk and B) it might restrict them to a particular
> processor architecture as perhaps in the future they might switch to ARM for
> example.
 
That may well be the case - you'd have to ask those companies.
 
> to bother with C++ since the language is so large now no sane person is going
> to bother to learn it from scratch. If I didn't know it already I certainly
> wouldn't.
 
By "problems", I don't mean the overall task of the program - I mean
particular bits of it. Like "how do we make this data structure in a
way that is efficient and won't leak memory".
 
>> Enter "concepts" that give you this, and you have many of the benefits
>> of duck-typing in a statically compiled and checked language.
 
> If you want duck typing just use python.
 
If you want fast code with static checking, /and/ you want some aspects
of duck-typing, use C++ with concepts.
 
I use Python when I want Python, and C or C++ when I want those
languages. There are times when using one language that I think "I wish
it was easy to do this particular thing as it is in that other
language". It is a /good/ thing that languages take inspiration from
each other to see how they can be better for developers.
 
> doesn't have any word byte order conversions to worry about nor does it store
> BLOBs. If you simply want to compress it then you could do that in C, never
> mind C++.
 
We all know what JSON is. Would it not be lovely to be able to take an
object in C++ and pass it to a generic "toJson" function and have its
members serialised - recursively as needed - without having to write
specialised functions for every single class in the program?
 
 
> Had to look up enable_if, never heard of it. If your templates get that
> complex then maybe for sanitys sake just bin them and use non templated
> functions and classes even if it means more code.
 
Have you ever looked at how the standard library is implemented? You
may not need to use safe boolean idioms, enable_if, and the rest in your
code - but I'm guessing that you have at least used standard containers
that /do/ use this kind of thing for their implementation. If you don't
want to use these features of the language, that's absolutely fine - but
don't try to tell others that they are useless, or that they could not
be replaced with something better, just because /you/ don't understand them.
 
 
boltar@cylonHQ.com: Sep 18 11:08AM

On Tue, 18 Sep 2018 12:26:07 +0200
 
>> If you want duck typing just use python.
 
>If you want fast code with static checking, /and/ you want some aspects
>of duck-typing, use C++ with concepts.
 
Or use Objective-C which has had it since it was created. Oddly though that
language never took off outside the apple ecosystem.
 
>language". It is a /good/ thing that languages take inspiration from
>each other to see how they can be better for developers.
 
You say taking inspiration, I say a one-size-fits-all type language which
will never work.
 
>object in C++ and pass it to a generic "toJson" function and have its
>members serialised - recursively as needed - without having to write
>specialised functions for every single class in the program?
 
It would, except it'll never be implemented fully. Why? Pointers. Apart from
not being able to figure out the pointer type unless extra functionality is
added to the runtime system (typeid is no good as you have to know beforehand
what you're checking against), the pointer itself could be pointing at anything
or anywhere. Eg shared memory, of which the structure is only known to the
program logic, not the compiler or any library function and could in turn have
pointers itself. Serialising that would simply produce a meaningless list of
values that could be invalid in any other process.
 
So, even if built in serialisation is added it'll be rather restricted.
 
>> complex then maybe for sanitys sake just bin them and use non templated
>> functions and classes even if it means more code.
 
>Have you ever looked at how the standard library is implemented? You
 
Once, it was enough.
 
>may not need to use safe boolean idioms, enable_if, and the rest in your
>code - but I'm guessing that you have at least used standard containers
>that /do/ use this kind of thing for their implementation. If you don't
 
Since enable_if is C++ 2011 they quite obviously don't (or didn't) as the STL
has been around since the 90s. Seems to me it is nothing more than yet another
syntatic hack to get around the poor initial syntactic and lexical design of
some aspect of the language rather than anything that will aid in developing
actually useful code or algorithms.
Ian Collins <ian-news@hotmail.com>: Sep 18 11:17PM +1200

> syntatic hack to get around the poor initial syntactic and lexical design of
> some aspect of the language rather than anything that will aid in developing
> actually useful code or algorithms.
 
Blah blah blah... are you related to BartC who whinges on about C in c.l.c?
 
--
Ian.
boltar@cylonHQ.com: Sep 18 11:50AM

On Tue, 18 Sep 2018 23:17:05 +1200
>> some aspect of the language rather than anything that will aid in developing
>> actually useful code or algorithms.
 
>Blah blah blah... are you related to BartC who whinges on about C in c.l.c?
 
Oh look, another mouth breather has popped up.
David Brown <david.brown@hesbynett.no>: Sep 18 02:01PM +0200

>> each other to see how they can be better for developers.
 
> You say taking inspiration, I say a one-size-fits-all type language which
> will never work.
 
Nobody has suggested a one-size-fits-all language. People have merely
suggesting adding some more features to a useful and flexible language.
 
> pointers itself. Serialising that would simply produce a meaningless list of
> values that could be invalid in any other process.
 
> So, even if built in serialisation is added it'll be rather restricted.
 
Of course it would be restricted (and pointers are not the main issue -
especially since they could probably be avoided in most cases). But it
would still be very, very useful.
 
> syntatic hack to get around the poor initial syntactic and lexical design of
> some aspect of the language rather than anything that will aid in developing
> actually useful code or algorithms.
 
You might want to look at what has changed over the years, before
deciding that what you had in the 1990's was enough. And "enable_if"
does not actually do anything that could not be done before - it's usual
definition is simple enough and valid for C++98 (I think). But it
standardises a common pattern with a recognizable name, making such
template code easier to read, write and maintain..
 
Many new C++ features are not about allowing you to do something that
you could not do earlier - they are about making them simple, clearer,
and easier to work with.
 
Let's take a little example. Suppose you want a function "roughlyEqual"
that compares integers or floats, using a different algorithm in each
case. With concepts, you can define a couple of concepts and write out
the functions neatly. (There are severe limitations in this example -
it is a taster, nothing more.)
 
You can paste this into <https://godbolt.org> and compile with "-fconcepts".
 
 
#include <type_traits>
#include <cstdlib>
 
// These "concepts" would probably be part of the standard library
 
template <typename T>
concept bool Floating_Point =
std::is_floating_point<T>::value;
 
template <typename T>
concept bool Integer =
std::is_integral<T>::value;
 
 
// Here we have two template functions using the concepts
 
bool roughlyEqual(Floating_Point a, Floating_Point b) {
return abs(a - b) < 0.0001;
}
 
bool roughlyEqual(Integer a, Integer b) {
return a == b;
}
 
// And some test code
 
bool test1(void) {
return roughlyEqual(2, 5);
}
 
bool test2(void) {
return roughlyEqual(2, 2);
}
 
bool test3(void) {
return roughlyEqual(2.0, 5.0);
}
 
bool test4(void) {
return roughlyEqual(2.0, 2.000001);
}
 
 
If you try "roughlyEqual("a", "b")", it will fail to compile - which is
the result you want.
 
 
You can write the roughlyEqual template functions using SFINAE, using
enable_if to make it easier:
 
template <typename T>
typename std::enable_if<std::is_integral<T>::value, bool>::type
roughlyEqual(T a, T b) {
return a == b;
}
 
template <typename T>
typename std::enable_if<std::is_floating_point<T>::value, bool>::type
roughlyEqual(T a, T b) {
return abs(a - b) < 0.0001;
}
 
 
To me, the concept code is a lot simpler.
David Brown <david.brown@hesbynett.no>: Sep 18 02:05PM +0200

>>> actually useful code or algorithms.
 
>> Blah blah blah... are you related to BartC who whinges on about C in c.l.c?
 
> Oh look, another mouth breather has popped up.
 
What do you think "mouth breather" means? It is about as smart as
saying "Oh look, another left-hander" or "Oh look, another person with
big ears". It simply makes you look rude, thoughtless and ignorant -
with a penchant for really stupid insults.
boltar@cylonHQ.com: Sep 18 01:07PM

On Tue, 18 Sep 2018 14:01:35 +0200
>> You say taking inspiration, I say a one-size-fits-all type language which
>> will never work.
 
>Nobody has suggested a one-size-fits-all language. People have merely
 
That seems to be the way C++ is heading. And anyone who's used a large
swiss army knife knows, they're really not particularly good at anything.
Including being a knife.
 
>case. With concepts, you can define a couple of concepts and write out
>the functions neatly. (There are severe limitations in this example -
>it is a taster, nothing more.)
 
No kidding. You can do exactly the same using standard polymorphism:
 
bool roughlyEqual(int a, int b)
{
return a == b;
}
 
 
bool roughlyEqual(float a, float b)
{
return fabs(a - b) < 0.001;
}
boltar@cylonHQ.com: Sep 18 01:12PM

On Tue, 18 Sep 2018 14:05:39 +0200
 
>>> Blah blah blah... are you related to BartC who whinges on about C in c.l.c?
 
>> Oh look, another mouth breather has popped up.
 
>What do you think "mouth breather" means? It is about as smart as
 
I know what it means, but why not grace us with your clearly sage like
wisdom and tell us.
 
>saying "Oh look, another left-hander" or "Oh look, another person with
>big ears". It simply makes you look rude, thoughtless and ignorant -
>with a penchant for really stupid insults.
 
Except those are being rude about physical aspects of someone, not their
behaviour which is quite different. Either that mind numbingly clear
distinction is beyond you or you're just some sad little SJW looking to be
offended. Either way, I couldn't give a shit. If you are offended then tough,
grow a pair and get over it. Now close your mouth and stop dribbling.
David Brown <david.brown@hesbynett.no>: Sep 18 03:29PM +0200


>> What do you think "mouth breather" means? It is about as smart as
 
> I know what it means, but why not grace us with your clearly sage like
> wisdom and tell us.
 
You don't need a lot of wisdom here - a "mouth breather" is someone who
breaths through their mouths a lot, rather than through their nose.
There can be many reasons for this, such as simply having a physically
narrow air passage in the upper nose (this is an inheritable trait).
 
>> with a penchant for really stupid insults.
 
> Except those are being rude about physical aspects of someone, not their
> behaviour which is quite different.
 
Having narrow nasal air passages, leading to mouth breathing, is a
physical aspect of the person.
 
A little googling showed me that some American's think "mouth breathing"
is an insult suggesting someone is stupid. It's a bit like calling
someone "blond" when they mean stupid - it merely shows the
name-caller's ignorance and general rudeness.
 
> distinction is beyond you or you're just some sad little SJW looking to be
> offended. Either way, I couldn't give a shit. If you are offended then tough,
> grow a pair and get over it. Now close your mouth and stop dribbling.
 
I think Ian is wrong to compare you to Bart. Bart might be stubbornly
and wilfully ignorant, but he is not the unpleasant little turd of a
human being that you give yourself out to be.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 18 04:31PM +0300

> On Tue, 18 Sep 2018 11:13:48 +0200
> David Brown <david.brown@hesbynett.no> wrote:
[...]
> to bother with C++ since the language is so large now no sane person is going
> to bother to learn it from scratch. If I didn't know it already I certainly
> wouldn't.
 
As it has become clear by now you do not know very much about C++ anyway
so this does not look like a very strong reason.
 
 
>> As a fine example, look at the "safe boolean idiom". It used to be
 
> Not only have I never used that idiom, I've never even written code that
> needed it.
 
Let me guess, this means you have never written a conversion operator
for a class and do not understand why somebody would need one.
 
> Had to look up enable_if, never heard of it.
 
No wonder you are thinking C++ is "an OO and generic version of C" (a
quote from your previous post).
 
> I can't even be bothered to figure it out. Frankly I'd sooner code in
> assembler again than have to fuck about with that sort of mess.
 
That's all nice and fine, you don't need to know or use the whole
language. On the other hand, why do you feel you are entitled to express
strong opinions about in which direction the language should evolve in
spite of your ignorance about the current state?
David Brown <david.brown@hesbynett.no>: Sep 18 03:31PM +0200

> {
> return fabs(a - b) < 0.001;
> }
 
Polymorphism - function overloading - works on structural typing.
Concepts work on features. There is a /vast/ difference.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 18 08:42AM -0400

On 9/17/2018 7:39 PM, Rick C. Hodgin wrote:
> True morality is doing what is right without the threat of divine retribution
> nor the possibility of divine reward.
 
Please examine the headers. You will see that there is an
imposter pretending to be me. I post from Google Groups
or Eternal September only.
 
-----
To Leigh Johnston (the one impersonating me):
 
We are already under sin. Judgment and condemnation is
already looming over us. We're in the water on the way
to drowning. What Jesus offers us is the only life raft
we will receive.
 
Why? Because only Jesus went to the cross innocent before
God (free from sin), yet guilty before man, and chose volun-
tarily to take on the sin of others and die with it charged
to Him, so that all people from who He takes their sin are
set free from sin, leaving them righteous and whole before
God.
 
It was the very reason Jesus was manifest in this world: to
set men free from sin, and to restore them to eternal life.
 
--
Rick C. Hodgin
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)