Saturday, March 14, 2020

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

Sam <sam@email-scan.com>: Mar 13 11:08PM -0400

jacobnavia writes:
 
 
> What happens when the class is modified to have a new field?
> All the structured binding constructs have to be modified to add the new
> field, and if you miss one crashes and bugs will inevitably happen.
 
Bullshit.
 
The code will fail to compile. And after fixing every return value, you'll
go back to your happy place.
 
Even decades-old Makefiles will automatically recompile everything that
pulls in the modified declaration, recompiling everything, and having your
compiler tell you everything you need to fix.
 
Please read a good C++ book, and try it yourself, before spewing this
nonsense again.
jacobnavia <jacob@jacob.remcomp.fr>: Mar 14 08:59AM +0100

Le 14/03/2020 à 04:08, Sam a écrit :
 
> Bullshit.
 
> The code will fail to compile. And after fixing every return value,
> you'll go back to your happy place.
 
I said:
 
All the structured binding constructs have to be modified
 
Then you say:
 
Bullshit
 
and in the next sentence you confirm what I have said.
 
> The code will fail to compile. And after fixing every return value,
> you'll go back to your happy place.
 
And you seem to ignore the contradiction!
 
Too much C++ affects reasoning capacity?
 
Or is it simply that ypu are answering out of "C++ nationalism", i.e
Trump's "My country right or wrong". as "My computer language right or
wrong"
 
As most other answers to my critique, you just seem to be touched
emotionally and your answers are emotional:
 
"spewing nonsense", etc.
 
Keep calm. We aren't speaking about your mother or about your country.
We are diuscussing a computer language feature. That's all.
 
Breath deeply and now answer me: Why is this new construct necessary?
 
Wasn't the old way of writing them easier and more robust?
 
THAT was my question. Please answer it.
jacobnavia <jacob@jacob.remcomp.fr>: Mar 14 09:05AM +0100

Le 13/03/2020 à 17:40, Öö Tiib a écrit :
>> bound automatically to the corresponding fields of the map.
 
>> Cute isn't it?
 
> No, doesn't compile, since necessary #includes are missing.
 
Yes, I missed the includes. Here they are:
 
#include <map>
#include <iostream>
#include <string>
 
 
> Someone posting this trash in anything-goes-newsgroup is fine,
> but if it is really in book then burn it and use "Filipek" like
> mild profanity.
 
You make a mountain out of a simple c ut/paste error.
 
 
> It does not parse, syntax error. Also you do not really post
> what you would like to see so I'm confused what is your
> suggestion.
 
I would say the compiler have to parse that by using the right
standard... Maybe you didn't se the standard to C++20
 
In any case you did NOT answer my question, since you can't apparently.
Or you did not see it whatever. Here is it AGAIN:
 
WHAT IS THE PURPOSE OF THIS "ENHANCEMENT"?
 
Why it is so important that you HAVE to add it to an already unbearible
complex language?
 
Why can't the old way of writing that code be maintained SIMPLIFYING the
language?
 
THAT was my point that you did not even mention!
jacobnavia <jacob@jacob.remcomp.fr>: Mar 14 09:10AM +0100

Le 13/03/2020 à 08:46, Maciej Sobczak a écrit :
>> All the structured binding constructs have to be modified
> And for some this is actually a feature, because without extremely costly review of existing code, the compiler will*automatically* tell you where are all the places that might require your attention. If neglecting the new field in any given place would result in a bug, you have all such potential places reported to you for free.
 
But the old way of writing it in C++14 doesn't have those pitfalls!
 
Even if you add 30 new fields, since the binding is done "manually" it
will continue to work unmodified. You just declare two new variables and
assign to them the values of the fields you want!
 
WHY this "enhancement" if the old way is more robust?
 
THAT is my point!!!
 
Here we have a new way of doing the same thing that is in many cases
WORST as the current one and will be added anyway, making an already
very complex language EVEN MORE COMPLEX!
 
And THAT was my point!
"Öö Tiib" <ootiib@hot.ee>: Mar 14 03:19AM -0700

On Saturday, 14 March 2020 10:05:58 UTC+2, jacobnavia wrote:
> > but if it is really in book then burn it and use "Filipek" like
> > mild profanity.
 
> You make a mountain out of a simple c ut/paste error.
 
Mea culpa. I just tried to mimic back your unmerciful style when
discussing a tool. Lets try a bit more calmly?
 
> > suggestion.
 
> I would say the compiler have to parse that by using the right
> standard... Maybe you didn't se the standard to C++20
 
It can't compile, it is syntax error in C++20. Range based for is:
for ( range_declaration : range_expression ) loop_statement
Call of function template std::bind is not a declaration.
I just had to point it out since majority of your post contained
such blunders.
 
> In any case you did NOT answer my question, since you can't apparently.
> Or you did not see it whatever. Here is it AGAIN:
 
> WHAT IS THE PURPOSE OF THIS "ENHANCEMENT"?
 
Sorry, I lost question in the pile of rant that felt incorrect. My
eyes are just accustomed to notice defects and in defective stuff
my mind stops searching any meaning.
I see no purpose of that particular enchantment. I continue writing:
 
for (auto const& e : mapCityPopulation)
std::cout << e.first << ": " << e.second << '\n';
 
When navigating within iterated element is too repetitive, verbose
and/or abstract (it isn't in that toy example but can be) then
I name these using local variables:
 
for (auto const& e : mapCityPopulation) {
char const* city = e.first.c_str();
int population = e.second;
std::cout << city << ": " << population << '\n';
}
 
I do same in every other place in code where something looks too
repetitive, verbose and/or abstract so it hurts readability.
 
> Why it is so important that you HAVE to add it to an already unbearible
> complex language?
 
My guess is that it is perhaps sabotage of wormtongues from monster
software companies with task to deteriorate the language to non-
useful. I disliked the language changes in C++17 as well. But I may
be wrong.
 
> Why can't the old way of writing that code be maintained SIMPLIFYING the
> language?
 
> THAT was my point that you did not even mention!
 
World is what it is. For me it is more important what we,
programmers can do to mitigate the issues. Actual market for
C++ has been in serious raise (in my experience) but skilled
specialists are hard to find and so half of people programming in
it can't actually comprehend it.
Sam <sam@email-scan.com>: Mar 14 10:09AM -0400

jacobnavia writes:
 
 
> Then you say:
 
> Bullshit
 
> and in the next sentence you confirm what I have said.
 
You're still full of bullshit. The bullshit part is the one that says "and
if you miss one crashes and bugs will inevitably happen".
 
That's the bullshit.
 
The reality is that if you miss one, the code won't compile, at all.
 
Try to learn C++, one of these days, ok?
 
> > The code will fail to compile. And after fixing every return value,
> > you'll go back to your happy place.
 
> And you seem to ignore the contradiction!
 
You don't understand, Einstein. The code will fail to compile. If it can't
compile, it can't "crash" and cause "bugs" to "inevitably happen".
 
> Wasn't the old way of writing them easier and more robust?
 
No, it wasn't. If you suddenly figured out that a function or a method
needed to return two or more discrete values, instead of one, the new way is
faster, less typing, and less error-prone.
 
> THAT was my question. Please answer it.
 
I just did: you're still full of bullshit.
jacobnavia <jacob@jacob.remcomp.fr>: Mar 14 06:32PM +0100

Le 14/03/2020 à 15:09, Sam a écrit :
> You're still full of bullshit. The bullshit part is the one that says
> "and if you miss one crashes and bugs will inevitably happen".
 
> That's the bullshit.
 
Dear Sam:
 
I am referring to the page 35 of
 
<https://drive.google.com/file/d/1W0Em5ioHiBdIG3LeXqpwla4wcPxvOBKq/view?usp=sharing>
 
In that page we have the description of the general interface of
structurezd binding with some arbitrary class, that he calls UserEntry.
 
<quote>
class UserEntry {
public:
void Load() { }
std::string GetName() const { return name; }
unsigned GetAge() const { return age; }
private:
std::string name;
unsigned age { 0 };
size_t cacheEntry { 0 }; // not exposed
};
<end quote>
 
We have here then a class with 3 fields, "name", "age", and another
called "cacheEntry" that is NOT EXPOSED to the structured binding interface.
 
To be able to specify in a "structured binding" the alias for the fields
you have to define (nothing less than ) 3 things:
 
1: get<N>,
2: std::tuple_size and
3: std::tuple_element
 
Here is an exemple:
 
<quote>
// with if constexpr:
template <size_t I> auto get(const UserEntry& u) {
if constexpr (I == 0) return u.GetName();
else if constexpr (I == 1) return u.GetAge();
}
namespace std {
template <> struct tuple_size<UserEntry>:integral_constant<size_t,2> {};
template <> struct tuple_element<0,UserEntry> { using type = std::string; };
template <> struct tuple_element<1,UserEntry> { using type=unsigned; };
}
<end quote>
 
As you see the "get" template receives an index that IS HARDCODED TO THE
INDEX OF THE FIELD, and any changes by INSERTING A NEW FIELD will make
those indexes silently access the WRONG FIELD, since if you add a field
at the beginning, it will become the zeroeth field of course.
 
Will it compile?
 
Well, if you insert a std::string at the beginning it WILL COMPILE since
the type of the first field is unchaged: it was std::string and REMAINS
std::string.
 
Now, let me make two remarks here:
 
1: We are speaking of just syntactic sugar for avoiding using two new
variables and some typing... To avoid that you type MUCH MORE NOW since
you have to define those 3 items I mentioned above and that is surely a
LOT of more typing.
 
2: Note that the names are "bound" to the fields of an anonymous object
created by the compiler? They are (excuse for this) what we would write in C
 
#define name tmp.name
#define age tmp.age
 
where the "tmp" is a name give,n by the compiler and invisible to the
program as written.
 
Is that name captured by a lambda expression?
 
Since you told me I do not know C++ I will leave to you the answer to
that question, since you obviously know more C++ than me.
 
Coming back to the problem at hand, we see that to save a trivial typing
(Mr Tib proposed it in this thread)
for (auto const& e : mapCityPopulation) {
char const* city = e.first.c_str();
int population = e.second;
std::cout << city << ": " << population << '\n';
}
 
there is more to type and figure out, and a complex interface of several
templates and definitions needs to be constructed!
 
What has been gained by adding this enormous complexity?
 
That is my question, that remains. I hope that I answered yours:
 
YES, THE CODE WILL SILENTLY COMPILE WRONG STUFF.
 
Q.E.D
Sam <sam@email-scan.com>: Mar 14 06:33PM -0400

jacobnavia writes:
 
> As you see the "get" template receives an index that IS HARDCODED TO THE
> INDEX OF THE FIELD, and any changes by INSERTING A NEW FIELD will make those
> indexes silently access the WRONG FIELD,
 
Which will now be a completely different class, and this will guarantee a
compilation error, until this is fixed.
 
A new field will change the size of the tuple binding.
 
This means that all existing code that uses structured bindings for these
values from the function that returns it, like:
 
auto &[name, age]=some_function_that_returns_UserEntry();
 
If and when a third field gets added to this UserEntry, and gets exposed via
structured bindings, this specific binding will now FAIL. Guaranteed. No
chance of miscompilation. Even if the name field is now index #1, and age is
index #2 and the new field is the same data type as name, and index 0.
 
So, there are now at least two different reasons why this will cause a
compilation error, and why the original claim is still 100% bullshit.
 
> since if you add a field at the
> beginning, it will become the zeroeth field of course.
 
> Will it compile?
 
No.
 
> Well, if you insert a std::string at the beginning it WILL COMPILE since the
> type of the first field is unchaged: it was std::string and REMAINS
> std::string.
 
None of the existing structured bindings will compile. They're all binding
two elements, instead of three.
 
Fail.
 
But what about pre-C++17 code that uses `std::get` to bind individual
elements?
 
Well, as the old joke goes: "Doctor, it hurts when I move my arm this way".
"Well, don't move your arm this way, then".
 
With a
 
auto &[value1, value2]=
 
structured binding, you are guaranteed a compilation failure when a new
binding gets added or removed. That's one preventative measure that's the
simplest solution. Use structured bindings this way, and any new bindings is
a guaranteed compilation failure.
 
Now, what about code that uses "std::get<>" indexes directly? Perhaps you
were only aware of the std::get<>-based version of structured bindings, and
you weren't aware of this, C++17 structured bindings?
 
That's ok. A reliable solution is still simple. Let's say you wanted, for
whatever reason, for a new std::string to take place of the existing
std::string name that std::get<0> gives you, in this situation.
 
Of course, the easiest solution is to return the new value as std::get<2>, a
new binding. But let's say you're stubborn and want to add a new one as
std::get<0> and shift the rest. And you want to guarantee a compilation
error?
 
Well, since you haven't yet written any new code that will use this new
field, you just declare one that's guaranteed to miscompile with any code
that uses the existing std::get<0> in any observable way:
 
class surname_t {
 
public:
surname_t(const surname_t &)=delete;
surname_t &operator=(const surname_t &)=delete;
};
 
Now, define this as your new std::get<0> binding. Compile the end result,
and have your compiler find all the existing usage of std::get<0> for you to
fix. It's going to be a bit difficult to assign it to a std::string. Even
with
 
auto name=std::get<0>(object);
 
Whatever subsequent code uses it next will fail. At some point, anything
that expects a std::string here will not find it. Only if this name isn't
used anywhere will let this slip through. But who cares, in that case.
 
It also seems to me that defining a
 
template <size_t I> auto get(const UserEntry& u) {
// …
}
 
is not required. One can simply declare a
 
template <size_t I> auto get(const UserEntry& u);
 
and then simply specialize it:
 
template<> auto get<(size_t)0>(const UserEntry &u)
{
return u.getName();
}
 
and so on, for the rest.
 
Now, one can easily respecialize that one as get<1>, leaving get<0>
completely unspecified, and thusly find all existing code that refers to it.
This will guarantee that no references to std::get<0> from existing code
will remain.
 
Now, you may find some existing code, perhaps something that uses
std::apply, that will now completely fail. But it'll need changing in any
case, to handle the new binding properly, so you can temporarily stub it
out, and put it back when the binding is completed.
 
And once now the existing code compiles, you've proven that you have no code
that uses the former std::get<0>, as a std::string, or anything else, so now
you're free to bind std::get<0> to an actual, new, std::string, with no
possibility of overlooking some existing reference.
 
But, even better, you should take this as an opportunity to find every
existing instance of direct usage of std::get<> (since std::get<1> of age,
that was getting an int before, will now be seeing a std::string, and fail),
and replace them with proper structured bindings:
 
auto &[surname, name, age]=whatever().
 
I would expect every modern compiler to completely optimize away whichever of
these are not actually used, so they come as cost-free, and future additions
to the structurally-bound class will not require a wrapper class, like this.
 
> Since you told me I do not know C++ I will leave to you the answer to that
> question, since you obviously know more C++ than me.
 
Yes, it does seem that I do. I have done precisely things of this nature
safely, and with 0 resulting defects. You just have to understand that these
kinds of breaking API changes should be done in a way that guarantees a
compilation error from any existing code that needs to change, and then have
the compiler find every occurence that needs changing, for you.
 
It is not difficult to cause a C++ compilation error in existing code. One
of the easiest things to do, in C++.
 
It is true that you just can't rebind, in this specific example, of
std::get<0> directly to std::string, and rely on the human factor to hunt
down all existing usage of it. You have to force a compilation error, and
have the compiler do it for you. That's what you will need to do, and if it
takes any amount of effort to do it, you make sure that the next time you
have to do it, it won't take much effort at all.
 
Now, perhaps you can prove that you know more than me here, and think of
some situation where a stub wrapper like this will not cause a compilation
error, but will still have observable changes. But, I'm pretty sure I can
come up with something that will also force a compilation error, in that
case.
 
> What has been gained by adding this enormous complexity?
 
The need to avoid declaring a bunch of helper classes, for one. Structured
bindings are not simply about declaring specialization of std::get. It's
much more than that. For example, if one needs to have a function or a
method return two discrete values, no need to declare a new helper class,
just a
 
std::tuple<int, const char *> so_long()
{
return {42, "And thanks for all the fish"};
}
 
And then simply get two natural objects from
 
auto [answer, mostly_harmless] = so_long();
 
Suddenly, it now becomes much easier for functions to actually return two,
or more, objects, without wearing out one's keyboard.
 
And by following this model, if so_long() ever needs to return three values,
just do it, and your C++ compiler will find all callers, guaranteed.
 
> That is my question, that remains. I hope that I answered yours:
 
> YES, THE CODE WILL SILENTLY COMPILE WRONG STUFF.
 
Sorry. That's still 100% bullshit. It is not difficult to prove that no
existing code will "compile wrong stuff". Not if you actually know C++, and
know how to use it correctly. Now, can you please pay attention, when
someone's teaching you C++?
 
If you'd like to prove me wrong, give me an example of an existing
structured binding, its existing usage, in some way, and tell me to rebind
the usage to a different one, and I'm confident I'll find a way to change
the binding, temporarily, to make the existing usage ill-formed, and not
compilable.
 
Nobody ever claimed that rebinding an existing structured binding can be
done in one step, with guaranteed error-free results. Just that there's
always a way to find all existing usage of structured bindings, and force a
compilation error until it's fixed to use the new binding, even a temporary
one, a wrapper of some sorts, that can be quickly dropped after all existing
code is converted.
 
In my experience, the worst case scenario is where I had to force a
compilation error twice: once in all existing code that used structured
bindings, converting it to temporary scaffolding; and a second time after
the temporary scaffolding gets removed, and the new structured binding gets
put in place.
 
But there's always a guaranteed way to get a compilation failure, and not
"SILENTLY COMPILE WRONG STUFF" (see, I can use the CAPS LOCK key too).
woodbrian77@gmail.com: Mar 13 07:39PM -0700

Shalom
 
Are others interested in a C++ meeting in the Saint
Paul, Minnesota area? My thought is to start with
a quarterly meeting.
 
We'll have to have some protocols to our meetings
like asking people if they have any symptoms of the
Wuhan virus and checking temperatures. I'm happy
to report that I don't have any symptoms at this
time and hope to keep it that way.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
https://github.com/Ebenezer-group/onwards
David Brown <david.brown@hesbynett.no>: Mar 14 01:25PM +0100


> Are others interested in a C++ meeting in the Saint
> Paul, Minnesota area? My thought is to start with
> a quarterly meeting.
 
Why would you post about a meeting in a small town in the middle of
nowhere, to an international newsgroup with people from all over the
world? Put an advert in the window of your local shop.
gazelle@shell.xmission.com (Kenny McCormack): Mar 14 08:44PM

In article <r4iifh$6ib$1@dont-email.me>,
 
>your international advert town meeting the people would shop. window to
>middle Put about newsgroup small in over in in local from you of an of
>an a with Why the nowhere, the a world? all post
 
This is pathetic, even by David Brown standards.
 
If you don't like it, ignore it. Or get out your Atlas and find out that
Saint Paul is anything but a small town in the middle of nowhere.
 
Anyway, what I found funny about the post is that most of the text (by word
count) was about the silly blah, blah, blah virus scare. Sign of the times...
 
--
"Everything Roy (aka, AU8YOG) touches turns to crap."
--citizens of alt.obituaries--
Real Troll <Real.Troll@Trolls.com>: Mar 14 05:30PM -0400


> Are others interested in a C++ meeting in the Saint
> Paul, Minnesota area? My thought is to start with
> a quarterly meeting.
 
If you are serious about this than please start a new group at this link:
 
<https://www.meetup.com/>
 
There's a link on top right corner at the above page to start a new
group for serious people looking for like minded people. You have to be
careful that you might get about 100 people at any one time but they
will all confirm before joing you so you can plan accordingly. After
the meeting, people normally go for drinks at their own costs, of
course. Yu only pay for the venue or organize with corporations such
as Google, Microsoft, Adobe or some other IT corporations. These people
are generally quite happy to finance events as long as their logo is
prominently displayed at the event.
 
I suspect you were just trolling to post your usual crap about
coronavirus. If this is true then you can safely ignore this post but
others might be interested to know what's available.
 
 
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 14 04:54PM

On Thu, 2020-03-12, Frederick Gotham wrote:
> On Thursday, March 12, 2020 at 3:02:13 PM UTC, Felix Palmen wrote:
...
 
> another program. In the future I might look at cleaner ways of
> achieving my objectives, but for right now I'm just gonna run these
> other programs and collect their first line of output.
 
This strikes me as a bad idea.
 
Shell scripting languages are designed to tie commands together, with
streams and files, and pipelines. For that kind of task it's a much
better tool than C++.
 
Even straight ports of shell scripts to Perl or Python is a bad
idea, IMO.
 
Things change if the problem isn't really a shell kind of problem, and
you do a brand new solution in C++. But the 'ps aux | grep foo' makes
this sound unlikely.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
cdalten@gmail.com: Mar 14 11:58AM -0700

On Saturday, March 14, 2020 at 9:54:48 AM UTC-7, Jorgen Grahn wrote:
 
> Things change if the problem isn't really a shell kind of problem, and
> you do a brand new solution in C++. But the 'ps aux | grep foo' makes
> this sound unlikely.
 
Here comes something the OP clearly doesn't know about. The output on *nix is divided into three major categories. Line buffered, unbuffered, and fully buffered. And if I saw the original shell scripts, I'm wiling to bet that the author took these three different cases into account because the OPs code clearly doesn't.
 
This despite the fact that I've told this halfwit that he should give the computer a rest and read "Advanced Programming in the Unix Environment" by the late Dr. Stevens. Seriously. If this dispshit would have taken my advice and read this book, he would know what I'm talking about and then maybe see why rewriting this stuff in C++ is sometimes a bad idea.
 
But I guess it's easier just to act like a retarded on the internet.
 
Uhh…
 
Hi mom!
Sam <sam@email-scan.com>: Mar 13 11:09PM -0400

jacobnavia writes:
 
> Consider:
 
> auto f = foo();
 
> What is "f"?
 
Who cares.
Melzzzzz <Melzzzzz@zzzzz.com>: Mar 14 04:53AM


> It's those of us that _want_ C++ to become a modern language, and have
> reservations where that's going, that have to also think about leaving. But
> where to?
 
Rust.
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Bonita Montero <Bonita.Montero@gmail.com>: Mar 14 08:06AM +0100

Is there any IDE that can expand an auto to the usual declarations ?
jacobnavia <jacob@jacob.remcomp.fr>: Mar 14 09:20AM +0100

Le 13/03/2020 à 14:26, David Brown a écrit :
> If you don't like a language, don't use it. If you don't know a
> language, either learn about it or keep quite about it - it is pointless
> to come to a language forum and complain about it.
 
Well, as a user of comp.lang.c I have been reading about the problems
with C by C++ heads since YEARS. They come to comp.lang.c to tell us how
bad C is and how good C++ is with various arguments. We listen politely
and answer them how do you do that in C, for instance when they say "C
is lacking xxx"
 
I haven't seen answers like "If you do not like C do not use it and go
away".
 
In this particular thread I am asking about your awareness about "auto"
misfeatures and we seemed to agree that are problems with it.
 
I am not saying that C++ is a pile of shit or even that this construct
should be taken away... I am pointing to the problems with it in the
following context:
 
Many of the new features added to C++ aren't well THOUGHT OUT and
provoke more problems than the ones they try to solve!
 
This is precisely why I think that continuing to add features each 3
years to an already highly complex language is a recipe for DISASTER!
 
I singled out two of them: structured binding and auto but there are
many more. Is it still possible to change the way the committee is working?
 
Instead of cheap polemic could you (maybe) reflect about that and
express your opinion about that?
"Öö Tiib" <ootiib@hot.ee>: Mar 14 03:23AM -0700

On Saturday, 14 March 2020 06:53:39 UTC+2, Melzzzzz wrote:
> > reservations where that's going, that have to also think about leaving. But
> > where to?
 
> Rust.
 
What is the chance that when Rust ever gets out of kindergarten it won't
be spoiled by "contributors" from monster companies as well? These
companies have plenty of money to sabotage anything.
Melzzzzz <Melzzzzz@zzzzz.com>: Mar 14 01:16PM

> Is there any IDE that can expand an auto to the usual declarations ?
VS?
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Melzzzzz <Melzzzzz@zzzzz.com>: Mar 14 01:20PM


> What is the chance that when Rust ever gets out of kindergarten it won't
> be spoiled by "contributors" from monster companies as well? These
> companies have plenty of money to sabotage anything.
 
So far, Rust eliminated lot of things from original language. From qutie
to monster. But it is ok so far. ML features are what is great about it
and they got right with error handling. Also proper `move` built into
language (destructors not get called after move and compiler errors if
one try to access them)
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Sam <sam@email-scan.com>: Mar 14 10:12AM -0400

jacobnavia writes:
 
> Many of the new features added to C++ aren't well THOUGHT OUT and provoke
> more problems than the ones they try to solve!
 
There are some like that, I do believe. But they're none of the ones you're
having a cow about.
David Brown <david.brown@hesbynett.no>: Mar 14 04:12PM +0100

On 14/03/2020 09:20, jacobnavia wrote:
> bad C is and how good C++ is with various arguments. We listen politely
> and answer them how do you do that in C, for instance when they say "C
> is lacking xxx"
 
So you think two wrongs makes a right? There are a few people who post
regularly in c.l.c. about how bad or pointless C is, and why C++ or
their own made-up language is vastly better. These kinds of posts are
as annoying as posts in c.l.c++ about how bad C++ is. (It's one thing
to discuss particular features, or to question the wisdom of current
language directions - that's different from wide-ranging rants about how
impossibly complicated the language is and other such posts.)
 
No, you don't have to listen politely to people complaining about C in
c.l.c. You can ignore them, point out their mistakes, or ask them to
stop pointless posts. (Again, there is nothing wrong with discussing a
language or its features pros and cons.)
 
 
> I haven't seen answers like "If you do not like C do not use it and go
> away".
 
Such answers are not uncommon - I don't know how you missed them.
 
For most people, in most circumstances, there are choices about the
tools and languages they use. Occasionally as professional programmers,
we have to work with languages we don't like, but if it is a long term
issue, it would be better to try to change jobs (or change things at
your current job) than to complain to innocent bystanders in a newsgroup.
 
 
> In this particular thread I am asking about your awareness about "auto"
> misfeatures and we seemed to agree that are problems with it.
 
I think everyone can see that it is a feature with advantages and
disadvantages. Use it appropriately, and don't use it inappropriately.
The same could be said of pretty much every feature of every language.
 
> following context:
 
> Many of the new features added to C++ aren't well THOUGHT OUT and
> provoke more problems than the ones they try to solve!
 
I think you are wrong. Some features have, in hindsight, had unexpected
and unforeseen issues. But that is not common, and not from lack of
thought or effort. More directly, however, I think you are not in a
position to make a reasonable judgement - much less make the kind of
absolute condemnations you write. Instead of emotive posts full of
capitals, exclamation marks, and accusations of incompetence in the C++
committee, perhaps you could ask other people where the find it useful,
and where they see it as counter productive.
 
In fact, /asking/ people and listening to them, rather than making
declarations from a position of ignorance or prejudice, is generally a
good idea.
 
> many more. Is it still possible to change the way the committee is working?
 
> Instead of cheap polemic could you (maybe) reflect about that and
> express your opinion about that?
 
I haven't made use of structured bindings as yet. I see it as a
somewhat convenient way to get multiple return values from functions.
However, it is not ideal for me - I would prefer a method that named the
parts, as it is too easy to get the order wrong. (For the same reason,
I am disappointed that C++ still has not got named parameters in
function calls.)
 
auto foo(int x, int y) {
struct { int sum; int prod; } r;
 
r.sum = x + y;
r.prod = x * y;
 
return r;
}
 
int bar(int x, int y) {
auto r = foo(x, y);
return r.prod / r.sum;
}
 
int bar2(int x, int y) {
auto [prod, sum] = foo(x, y);
return prod / sum;
}
 
The "auto" in "foo" and "bar" makes the code a lot simpler and shorter,
and saves providing a name for the multi-value return type. This is a
good thing, and a good use of "auto" (IMHO, of course). "bar2" uses
structured bindings, and shows the kind of subtle mistake that is easily
made here. (Unlike some of the mistakes you discussed about structured
bindings, this mistake compiles fine so you get no help from the tools.)
 
However, AFAIK C++ currently gives no way to use such anonymous struct
return types in functions with separate definitions and declarations.
"Öö Tiib" <ootiib@hot.ee>: Mar 14 09:20AM -0700

On Saturday, 14 March 2020 15:20:46 UTC+2, Melzzzzz wrote:
> and they got right with error handling. Also proper `move` built into
> language (destructors not get called after move and compiler errors if
> one try to access them)
 
You misunderstood my question. Lets say Rust becomes mature enough
to be useful enough so some shops start to write real software in it.
What stops all those googles, amazons, microsofts, ibms, oracles and
apples to form intermonsternational standardization committee of
wormtongues and to screw it into oblivion within a decade like
with C++?
Bart <bc@freeuk.com>: Mar 14 05:23PM

On 14/03/2020 15:12, David Brown wrote:
> }
 
> The "auto" in "foo" and "bar" makes the code a lot simpler and shorter,
> and saves providing a name for the multi-value return type.
 
Does C++ still need declarations of such functions when the definition
itself is not visible? If so, what would they look like?
 
What I'm getting at is that such a return type will need to be known at
the call-site, at least the number and types of the multiple values.
 
Also I can't see that 'auto' helps that much here, since you will still
need to know the number of return values, if not their types.
 
(Your proposal also seems to allow multiple, nested return values, which
IMO is not useful and complicates matters. That would be better as a
single compound type.)
 
  This is a
> structured bindings, and shows the kind of subtle mistake that is easily
> made here.  (Unlike some of the mistakes you discussed about structured
> bindings, this mistake compiles fine so you get no help from the tools.)
 
C, and I assume C++, allows this:
 
void fn(int sum, int prod);
void fn(int prod, int sum) {....}
 
If only the declaration is visible at the call-site, it will be misleading.
 
> However, AFAIK C++ currently gives no way to use such anonymous struct
> return types in functions with separate definitions and declarations.
 
OK, you seem to have answered my point above...
 
 
> So you think two wrongs makes a right? There are a few people who post
> regularly in c.l.c. about how bad or pointless C is, and why C++ or
> their own made-up language is vastly better.
 
It might worth listening to such people when their made-up (but actual,
not imaginary) language has long had features such as multiple return
types, default parameter values and keyword arguments. And that sum/prod
mixup is not possible.
 
Example after sig.
 
--
function foo(int x,y)int,int =
return (x+y, x*y)
end
 
Call using (sum, prod) := foo(a,b). foo can be in a different module; no
declaration needed, only an 'import' statement in call-module.
 
Based on your proposal, I might allow the multiple return parts to be
named (currently only possible for single return values):
 
function foo(int x,y)int sum, prod =
sum := x+y
prod := x*y
return (sum, prod)
end
 
'sum' and 'prod' will be regular local variables.
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)