Tuesday, March 19, 2019

Digest for comp.lang.c++@googlegroups.com - 15 updates in 2 topics

Sam <sam@email-scan.com>: Mar 18 09:24PM -0400

Chris Vine writes:
 
> > according to plan, and the dream of becoming an elite C++ uberhacker
> > overnight is proving to be quite elusive; hence the butthurt.
 
> I think this elitist meme is misplaced.
 
I wasn't claiming that C++ is some kind of an elite language. That's not
what I wrote. I was addressing someone's obvious posturing as some kind of a
C++ uberhacker and being full of amazing insights into how C++ should be
designed, and the disappointment at the lack of accolades, and agreement
with such greatness.
 
But, as long as this topic is on the table:
 
> Bear in mind that there are
> some language communities which consider that those who program in C++
> are neanderthals because of the language's verbosity, weak type system
 
You mean "strong type system". Unless black is suddenly white, it's hard to
find another general purpose language whose typing is stronger than C++. If
you filter all the noise, all the pleasedomyhomeworkforme.com,
pleasewritemycodeforme.com, and pleasegivemeananswertosomedumbquiz.com-type
posts on Stackoverflow, a good chunk of what's left are questions about some
typing-related compilation error.
 
As compared to declaring "var foo", say in Javascript, and throwing any kitchen
sink into it. Now that's what I call a weak type system.
 
And as far as verbosity goes, a lot of that is addressed by "auto", range
iterations, and similar recent features.
 
But, in any case, what other communities think, or don't think, of C++ did not
factor in my response.
 
> programming language is considerably less popular than it once was,
> probably in part because of these things (the prevalence of garbage
> collection these days has probably also played a part).
 
Of course. A long time ago you had no choice: you had to know your shit, in
order to write code that worked correctly, that didn't randomly crash, and
that didn't eat all the RAM you had. There were no other options. Either you
did C++ and got it right, or you changed careers.
 
Now, if you can't hack it, you can't wrap your brain around it, you can
always have the Java VM babysit everything for you, and change your diapers.
Forget about thinking with your brain. Create objects whenever you feel like
it, and the VM will take care of garbage-collecting everything to you. Just
make sure you have enough RAM. It's so much easier that way.
 
Before, if you didn't actually understand how things work, you were out. So,
naturally, C++ ruled the roost. There were no other options, hence, by
default, C++ had most of the mindshare.
 
But now, instead of leaving the field and go and do something else, the ones
who couldn't hack it, they were now able to write spaghetti code in Java. Or
Python. Or Perl. Or Javascript. So, of course C++'s market share is diluted.
There are so many options now, for those who can't hack C++, that didn't
exist before.
 
> multi-threaded application with shared mutable state is difficult, and
> more so when using primitives like condition variables and mutexes (and
> even more so when using atomics).
 
That's exactly what I wrote. I am not disagreeing. C++ is hard. You have to
do things the right way. What I was commenting about is the whining about
C++ being hard, or supposedly not making the sense. That whining,
simultaneously with delusions of "why do have to things X way in C++ when
doing it Y way is either" self-grandeur. Why do you have to check the
protected state, before waiting on the condition variable? Why can't one
thread just push a magic button, and signal the other thread, now or later?
 
Well, because C++ does not work this way. C++ will always be hard. It's not
going to change. It's now about 5-7 times harder and bigger now, than
<C++11. It will never be easy. Wait until concepts land. That's going to be
one hell of a party.
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 18 10:44PM -0400

On 3/18/19 21:24, Sam wrote:
> Chris Vine writes:
...
>> are neanderthals because of the language's verbosity, weak type system
 
> You mean "strong type system". Unless black is suddenly white, it's hard to
> find another general purpose language whose typing is stronger than C++. If
 
See
<https://en.wikipedia.org/wiki/Comparison_of_programming_languages_by_type_system>
which lists C++ as weakly typed, and lists 70 other languages as
strongly typed. I don't claim Wikipedia is absolutely authoritative -
but if you think it's incorrect, please feel free to correct it.
The key thing that makes C++ more weakly typed than those other
languages is the large number of implicit conversions it supports.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 19 10:11AM

On Tue, 2019-03-19, James Kuyper wrote:
> which lists C++ as weakly typed, and lists 70 other languages as
> strongly typed. I don't claim Wikipedia is absolutely authoritative -
> but if you think it's incorrect, please feel free to correct it.
 
A "this page lacks needed references" would be a good start.
 
> The key thing that makes C++ more weakly typed than those other
> languages is the large number of implicit conversions it supports.
 
A binary strong/weak separation isn't very useful (and it doesn't help
that "weak" sounds like a bad thing). C++ (and C) lets you mix char
and unsigned long, but not struct Foo and struct Bar (unless you add
conversion paths on purpose).
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Sam <sam@email-scan.com>: Mar 19 06:38AM -0400

James Kuyper writes:
 
> which lists C++ as weakly typed, and lists 70 other languages as
> strongly typed. I don't claim Wikipedia is absolutely authoritative -
> but if you think it's incorrect, please feel free to correct it.
 
I've read enough articles on Wikipedia itself, to know better than waste my
time like that.
 
> The key thing that makes C++ more weakly typed than those other
> languages is the large number of implicit conversions it supports.
 
Let's see, implicit conversions between numeric types, acquiring const-ness,
and implicit conversion of pointers/references to pointers/references to
base classes.
 
First of all, how many of those 70 other languages have char, short, int,
long, long long, the unsigned varieties, float and double? That's 12 numeric
types.
 
If you consider all of these as just one numeric type, like what I suspect
what happens in most of those 70 other languages, which probably have only
one, maybe two, numeric types, that's not a lot of implicit conversions.
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 19 08:07AM -0400

On 3/19/19 06:11, Jorgen Grahn wrote:
>> strongly typed. I don't claim Wikipedia is absolutely authoritative -
>> but if you think it's incorrect, please feel free to correct it.
 
> A "this page lacks needed references" would be a good start.
 
Agreed. My original plan was to say "..., but you can follow up on the
references." - but there don't seem to be any that cover how the
languages are classified.
 
>> languages is the large number of implicit conversions it supports.
 
> A binary strong/weak separation isn't very useful (and it doesn't help
> that "weak" sounds like a bad thing).
 
Agreed. I was only addressing the question of whether C qualifies as a
strongly-typed langauge, not the desirability of doing so.
 
> ... C++ (and C) lets you mix char
> and unsigned long, but not struct Foo and struct Bar (unless you add
> conversion paths on purpose).
 
See section 4, "Standard Conversions" for the full list of conversions
that can occur implicitly - it's several pages long. In particular, see
paragraph 7. For standard types, you can, among other things, convert
long double to char, or a pointer to a struct to bool.
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 19 08:11AM -0400

On 3/19/19 06:38, Sam wrote:
> James Kuyper writes:
...
> time like that.
 
>> The key thing that makes C++ more weakly typed than those other
>> languages is the large number of implicit conversions it supports.
 
I should also mention that C++ allows explicit conversions of types that
many strongly typed languages don't allow at all, particularly pointer
conversions.
 
> First of all, how many of those 70 other languages have char, short, int,
> long, long long, the unsigned varieties, float and double? That's 12 numeric
> types.
 
Many of them have multiple arithmetic types, but don't have implicit
conversions between them.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 19 12:19PM

On Mon, 18 Mar 2019 21:24:33 -0400
> C++ uberhacker and being full of amazing insights into how C++ should be
> designed, and the disappointment at the lack of accolades, and agreement
> with such greatness.
 
It was you who was setting yourself up as a "C++ uberhacker", with your
"It took me only a few minutes to figure it out, the first time I
encountered this topic, a long long time ago, in a galaxy far, far
away. But not everyone is as smart as me." and "I think we're looking
at a future Microsoft Windows developer, here" and similar nonsense
intended to belittle someone else. (I fail to understand quite how you
managed to bring Windows developers into it; many of them are very
good.)
 
He was basically confused about what condition variables were and how
they were used, as beginners often are. His questions were reasonable
ones for a beginner; the most you could say is that he was somewhat
slow on the uptake, and may have argued the point more than you would
have liked, but people go at their own pace.
 
> > are neanderthals because of the language's verbosity, weak type system
 
> You mean "strong type system". Unless black is suddenly white, it's hard to
> find another general purpose language whose typing is stronger than C++.
 
You are wrong. This was one of the (in my view worthwhile) trade-offs
made when C++ was first designed in order to maintain compatibility
with C. C's built-in types have many implicit conversions available to
them, and what is more C has an undescriminated void* type. C++'s
class system is well typed, but every class at the end of the day is
formed from its built-in components.
 
[snip]
> As compared to declaring "var foo", say in Javascript, and throwing any kitchen
> sink into it. Now that's what I call a weak type system.
 
Javascript is relatively weakly typed - it does allow some coersions -
but the main distinguishing feature of "var foo" in Javascript compared
with "auto foo" in C++ is that Javascript has dynamic (latent) typing.
It is the object bound to 'foo' which is typed rather than the variable
name 'foo'. It is perfectly possible to have a language which is
strongly and dynamically typed, requiring some of the type checking to
be carried out at run time.
 
> Python. Or Perl. Or Javascript. So, of course C++'s market share is diluted.
> There are so many options now, for those who can't hack C++, that didn't
> exist before.
 
More of the same attitude. (By the way, you said above that you
"[weren't] claiming that C++ is some kind of an elite language".)
 
In any event, Python, Perl and Javascript are fishing in a different
pond from C++ and irrelevant to this - I don't think they have any
significant effect on C++ usage. My view is that C++ is a good
language for a number of the things that they don't do.
johnbenny@nowhere.co.uk: Mar 19 01:30PM

On Mon, 18 Mar 2019 21:24:33 -0400
>C++ uberhacker and being full of amazing insights into how C++ should be
>designed, and the disappointment at the lack of accolades, and agreement
>with such greatness.
 
I would suggest that , in this order, you should:
 
A) Improve your English comprehension
B) Grow up.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 19 01:57PM

On 19 Mar 2019 10:11:57 GMT
> that "weak" sounds like a bad thing). C++ (and C) lets you mix char
> and unsigned long, but not struct Foo and struct Bar (unless you add
> conversion paths on purpose).
 
One problem with the yes/no approach is that most of the languages
marked as strongly typed have a FFI for C, for reasons of practicality.
This means that if the type system of your language does not allow you
to do some low level hack, you can do it in C and provide some
appropriate language-endorsed glue over it. However the code in that
case is still only as safe as the C code you have in fact written.
 
One thing you can say is that in such a case the area of weak typing is
confined to its own module. When you write an entire program in C it is
ubiquitous.
Sam <sam@email-scan.com>: Mar 19 06:00PM -0400


> I would suggest that , in this order, you should:
 
> A) Improve your English comprehension
> B) Grow up.
 
You have my earnest assurances that your suggestions will receive the full
weight, and considerations, that they so richly deserve.
Sam <sam@email-scan.com>: Mar 19 06:02PM -0400

Chris Vine writes:
 
> "It took me only a few minutes to figure it out, the first time I
> encountered this topic, a long long time ago, in a galaxy far, far
> away. But not everyone is as smart as me."
 
It looks like a crucial fact was inadvertently omitted from this thoughtful
analysis. Specifically, the actual post that specific response was written
in reply to. Even more specific: the post in question was a 100% content-
free "you all suck" message; and my reply was pretty much in the same vein.
Perhaps I should've disclosed my policy that requires my response to be made
in the language the individual that I'm responding to is capable of
understanding. I just don't see the point of investing the time and effort
in assesmbling and putting together something that the intended recipient is
incapable of understanding.
 
But, obviously, that, in itself, was also too complicated for some to
understand.
 
> and "I think we're looking
> at a future Microsoft Windows developer, here" and similar nonsense
> intended to belittle someone else.
 
And that remark was responding to the proposal to replace wait() with a busy-
loop. The proposee, apparently, was either unable to understand the
difference, or was unaware how wait() works, in terms of CPU usage. Hence
the proper response.
 
But this was also too complicated for some to understand, from the looks of
it.
 
> (I fail to understand quite how you
> managed to bring Windows developers into it; many of them are very
> good.)
 
s/many/some/, and I might agree. But I'll have to disagree, as long as
things remain at such a generic level.
 
> He was basically confused about what condition variables were and how
> they were used, as beginners often are. His questions were reasonable
> ones for a beginner;
 
You left out trailing "… who belives that he's an expert and a know it all".
 
> the most you could say is that he was somewhat
> slow on the uptake,
 
That's a very modest understatement.
 
> them, and what is more C has an undescriminated void* type. C++'s
> class system is well typed, but every class at the end of the day is
> formed from its built-in components.
 
Oh, I wasn't aware that you could assign a std::variant to a double, or
push_back an instance of MyClass into a std::vector<int>, just like that. I
guess I was wrong, and C++ is a weakly-typed language.
anhongleetcode@gmail.com: Mar 19 11:20AM -0700

Hi Expert,
 
I am new to C++ and template is d**n hard for me... I am trying to make a class (say Func) to accept different type of lambdas/functions, then I can call it in uniformed way.
 
 
Func f([](int a)->bool { return a > 1; }); // lambda with parameter int
Func g([]( )->bool { return true ; }); // lambda without parameter
 
f.exec(2);
g.exec(2); // the parameter 2 is ignored, always returns true
 
 
 
 
To do this, I declared class like:
 
 
class Func
{
private:
std::function<bool(int)> m_func;
 
public:
template<typename F> Func(F && f): m_func()
{
if constexpr(std::is_invocable_r_v<bool, F>){
m_func = [f_void = std::function<bool()>(std::forward<F>(f))](int)
{
return f_void();
}
}else{
m_func = std::function<bool(int)>(std::forward<F>(f));
}
}
 
public:
int exec(int a){ return m_func(a); }
};
 
my problem is:
1. how to avoid the ctor call of std::function get called in initialization list? It actually has no point since we actually immediately assign the real function to it.
 
2. this code doesn't compile for VS2017, if fails at else-branch as:
 
Func f([]()->bool {return false; });
^^^^^^^^^^^^^^^^^^^^^^^^^^^ error C2440: '<function-style-cast>': cannot convert from '_Ty' to 'std::function<bool(int)>'
anhongleetcode@gmail.com: Mar 19 11:22AM -0700

gcc compiles
 
在 2019年3月19日星期二 UTC-7上午11:20:41，anhongl...@gmail.com写道：
Paavo Helde <myfirstname@osa.pri.ee>: Mar 19 10:28PM +0200

> {
> return f_void();
> }
 
A semicolon is missing here.
 
 
 
> 2. this code doesn't compile for VS2017, if fails at else-branch as:
 
> Func f([]()->bool {return false; });
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error C2440: '<function-style-cast>': cannot convert from '_Ty' to 'std::function<bool(int)>'
 
After fixing the semicolon, it compiled fine for me.
 
However, this all seems far too complicated/obfuscated for my taste.
What's wrong with:
 
#include <functional>
#include <type_traits>
 
using ftype = std::function<bool(int)>;
using gtype = std::function<bool()>;
 
class Func {
private:
ftype m_func;
public:
Func(ftype f) : m_func(f) {}
Func(gtype g) : m_func([g](bool dummy) {return g(); }) {}
public:
int exec(int a) { return m_func(a); }
};
 
int main() {
Func f([](int a)->bool { return a > 1; });
Func g([]()->bool { return true; });
 
f.exec(2);
g.exec(2); // the parameter 2 is ignored, always returns true
}
 
What benefit would std::is_invocable_r_v have here over a constructor
overload (other than having fun with impenetrable template syntax, of
course ;-)?
anhongleetcode@gmail.com: Mar 19 02:08PM -0700

在 2019年3月19日星期二 UTC-7下午1:28:22，Paavo Helde写道：
 
> What benefit would std::is_invocable_r_v have here over a constructor
> overload (other than having fun with impenetrable template syntax, of
> course ;-)?
 
Yes, thanks for saving me from the chaos!...
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)