Monday, March 23, 2020

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

James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 23 09:06AM -0400

On 3/23/20 5:24 AM, alelvb wrote:
> Mr Stroustrup knows his child better than anyone else, so if
> He decided not to give it this feature there must have been
> serious problems concerned with it.
 
Stroustrup is not perfect, and I'm sure he'd be the first to admit it.
He didn't think of everything the first time around - many aspects of
how C++ does and should work did not become clear until long after a
large number of people started using it. Especially after C++ became
standardized, many problems with C++ have been detected and solved by
people other than him. Therefore, don't read too much into the fact that
he didn't provide a given feature. "Design and Evolution of C++" gives a
very detailed explanation of it's title subject, and is much more
authoritative than any guesses you might make based upon simply noticing
the absence of a feature.
cdalten@gmail.com: Mar 23 06:16AM -0700

On Sunday, March 22, 2020 at 12:38:29 PM UTC-7, alelvb wrote:
 
> Vector v = a ∧ b;
 
> instead of the traditional explicit call:
 
> Vector v = a.wedge_product(b);
 
This wouldn't work because the tensor product works on the vector components and not the vector themselves. Remember, vectors are invariant under a change of basis.
alelvb <alelvb@inwind.it>: Mar 23 04:12PM +0100


>> instead of the traditional explicit call:
 
>> Vector v = a.wedge_product(b);
 
> This wouldn't work because the tensor product works on the vector components and not the vector themselves. Remember, vectors are invariant under a change of basis.
 
I'm sorry; what I wanted to do was just to illustrate my idea,
maybe the wedge product of two vectors is not a vector as I wrote.
 
what I'm sure it is correct is:
 
double dp = a ∙ b; // dot product
 
I hope that regardless to my mistake and ignorance, it was clear what I
meant.
 
thank you for your reply,
 
alessandro
alelvb <alelvb@inwind.it>: Mar 23 04:19PM +0100

Il 23/03/20 14:06, James Kuyper ha scritto:
> very detailed explanation of it's title subject, and is much more
> authoritative than any guesses you might make based upon simply noticing
> the absence of a feature.
 
OK, clear.
 
But do you think my idea is so absurd?
Do you think that it would be (if one day this feature is added to the
language) unseful?
 
 
thank you for your reply,
 
alessandro
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 23 11:38AM -0400

On 3/23/20 11:19 AM, alelvb wrote:
>> the absence of a feature.
 
> OK, clear.
 
> But do you think my idea is so absurd?
 
Unless and until the C++ standard is modified to mandate support for
unicode source files (the supported unicode encodings could still be
implementation-defined), your idea isn't even feasible. If such a change
did ever occur, your proposal would become feasible, but I'm not sure it
would be a good idea. Your proposal would make C++ an even more
confusing language to read than it currently is.
David Brown <david.brown@hesbynett.no>: Mar 23 04:52PM +0100

On 22/03/2020 20:38, alelvb wrote:
 
> Vector v = a ∧ b;
 
> instead of the traditional explicit call:
 
> Vector v = a.wedge_product(b);
 
One thing that can be done today, and doesn't involve hard-to-type,
hard-to-read unicode symbols, is a syntax like:
 
v1 = a *wedge* b;
v2 = a *dot* b;
"Öö Tiib" <ootiib@hot.ee>: Mar 23 09:25AM -0700

On Monday, 23 March 2020 17:52:38 UTC+2, David Brown wrote:
> hard-to-read unicode symbols, is a syntax like:
 
> v1 = a *wedge* b;
> v2 = a *dot* b;
 
Using / it looks passable. Unfortunately it involves some
bloat code, tools are somewhat confused, it may stop some
optimizations of compiler and diagnostics on case of typo in
expression can be also quite confusing. So wedge(a, b),
dot(a, b), a.wedge(b) and/or a.dot(b) keep being the winners
today.
David Brown <david.brown@hesbynett.no>: Mar 23 05:51PM +0100

On 23/03/2020 17:25, Öö Tiib wrote:
 
>> v1 = a *wedge* b;
>> v2 = a *dot* b;
 
> Using / it looks passable.
 
I'd stick to * for multiplication, since these are multiplication
operations. It might not make sense to have the same name for different
operations in this case, but it could do for other types - for
arithmetic types you might have *sat*, +sat+, -sat- for saturating
operations.
 
> expression can be also quite confusing. So wedge(a, b),
> dot(a, b), a.wedge(b) and/or a.dot(b) keep being the winners
> today.
 
I am not saying this is the best way to express the OP's requirements -
I am saying it is an option to consider. If he has more complex
expressions, then an infix operator can make things a lot easier.
That's a judgement we must leave up to the OP.
 
Compilers and other tools should not be confused here - it's just
classes and friend functions. You do need to define an extra helper
class, but it's worth a little bloat in the definition if you find the
results neater.
"Öö Tiib" <ootiib@hot.ee>: Mar 23 10:03AM -0700

On Monday, 23 March 2020 18:51:59 UTC+2, David Brown wrote:
> classes and friend functions. You do need to define an extra helper
> class, but it's worth a little bloat in the definition if you find the
> results neater.
 
Compilers and other tools are software and the software often does not
understand what kooky intentions the humans have. Some code editors
for example "helpfully" format it like a * wedge * b when copy-pasting
it.
Bonita Montero <Bonita.Montero@gmail.com>: Mar 23 06:11PM +0100

There are good reasons why operator overloading is used very sparsely.
To add to that, that code would only become more incomprehensible would
be stupid.
alelvb <alelvb@inwind.it>: Mar 23 10:36PM +0100

Il 23/03/20 16:38, James Kuyper ha scritto:
> did ever occur, your proposal would become feasible, but I'm not sure it
> would be a good idea. Your proposal would make C++ an even more
> confusing language to read than it currently is.
 
I do think that if one is confused by the code, that happens because
he or she doesn't have the same mastering on the subject than the
author of that code. Take me, for example.
I asked some time ago for an help here in the newsgroup
to solve a problem related with a chemical formula parser.
 
Well I tried to read the code sent me in a message but I have not still
come out of the darkness...
That code is full of things I don't know (but it solved at half my problem).
Anyway, it doesn't use any operator overloading nor tricky symbols, and
it is still obscure. So you are only partly right.
 
The problem with my idea was the choice of the unicode symbols?
 
What you write about the Unicode supporting is noteworthy.
I use only ASCII characters because I have not well understood how
to handle unicode char literals or strings.
 
If an operator can be overloaded, it could save some typing
without adding more complexity and it could improve readability.
 
In my example with Vectors, writing:
 
Vector v1 {1, 0, 3},
v2 {2, 1, -1};
 
double dp = v1 * v2;
 
it highlights that in some way I'm performing some operation on the
vectors related to the multiplication.
 
If I write instead:
 
double dp = v1.dot(v2);
 
you should go to read the dot function code to guess the same
information. Of course, to be more clear, I could have written
 
double dp = v1.dotProduct(v2);
 
but I had typed +10 characters instead of simply 1.
If operator overloading would be harmful it would have been banned from
the language or it could had not even been added like happens in other
OO languages.
 
One could argument that the same symbol could be used with different
kinds of operands and so overloaded multiple times, leading to
confusion, but if the code is at hand that argumentation is only provoking.
 
thank you for your reply,
 
alessandro
Paavo Helde <myfirstname@osa.pri.ee>: Mar 24 12:20AM +0200

On 23.03.2020 23:36, alelvb wrote:
> The problem with my idea was the choice of the unicode symbols?
 
Yep.
 
> What you write about the Unicode supporting is noteworthy.
> I use only ASCII characters because I have not well understood how
> to handle unicode char literals or strings.
 
Well, your initial proposal was containing Unicode symbols:
 
> [...]
> and use it usually:
 
> Vector v = a ∧ b;
 
The '∧' in the above line is U+2227, very much Unicode, despite the fact
that it looks much like the ASCII '^' (the obfuscated C++ contest people
would rejoice!)
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 23 10:27PM

On 23/03/2020 22:20, Paavo Helde wrote:
> > and use it usually:
 
> > Vector v = a ∧ b;
 
> The '∧' in the above line is U+2227, very much Unicode, despite the fact that it looks much like the ASCII '^' (the obfuscated C++ contest people would rejoice!)
 
The reason why we restrict the language symbols to ASCII is quite simple: most of us have keyboards that only have ASCII symbol keys. Now stop being a lemon.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Maciej Sobczak <see.my.homepage@gmail.com>: Mar 23 02:20PM -0700

> Now it seems there is actually some unrelated hidden class C, and a C*
> pointer is reinterpret_cast into T*, and back to C* later.
 
Yes, in the pattern described in the book, there was indeed type C involved and T was used to hide it.
 
> But what's
> the point? Why shouldn't C be just forward-declared in the header with
> 'class C'? What's the benefit of having a non-existent class T?
 
In that case (from the book) the whole idea was that A and B were wrappers for something (say X and Y) that was not to be exposed on the public view. Indeed, the third class that you suspect to exist, was a genuine base class of one of these wrapped/hidden constructs. The idea was to wrap that hierarchy without the need to repeat it at the wrapper level, because the hierarchical nature of the wrapped stuff could have been an implementation detail.
So there was:
 
class Base { ... };
class X : public Base { ... }; // hierarchy
class Y { void foo(Base &); };
 
and this stuff was wrapped as:
 
class T;
class A { T* getT(); }; // no hierarchy
class B { void foo(T*); };
 
As you guessed, T* is only the token that carries that actual Base*.
But the hierarchical nature of the wrapped stuff does not leak to the wrapper level, so can be changed to something else without disturbing the wrapper interface.
 
It makes sense to me and I find it to be a sufficient justification for some dirty tricks under the hood (like reinterpret_casts Base* <-> T* ), and I was interested whether this idea has found some other uses.
 
> void* _Placeholder;
> } FILE;
 
> It looks like this is not the actual implementation,
 
I think the idea was similar and the only reason for the whole dummy struct was that there is no way to typedef the incomplete type and declaration alone would not allow to use "FILE" without the "struct" keyword.
 
In any case, resource handles seem to be good candidates for this idiom.
 
--
Maciej Sobczak * http://www.inspirel.com
cdalten@gmail.com: Mar 23 06:11AM -0700

On Sunday, March 22, 2020 at 4:12:24 PM UTC-7, Mr Flibble wrote:
 
> > May the Lord free you, then bind you up in His Kingdom, and keep secure you no matter what comes.
 
> > Love. Joy. Peace. Hope. In Christ alone.
 
> Fuck. Off.
 
U mad princess?
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 23 06:40PM

On 22/03/2020 23:50, Alf P. Steinbach wrote:
 
>> Fuck. Off.
 
> Consider replying to him by e-mail, instead of posting to the group, please?
 
> I've long ago killfiled Rick but despite your occasional sausage postings, good-natured trolling attempts and habitual swearing, plus one silly impossible project (the generic compiler vaporware)
 
Not impossible at all, you are displaying your ignorance if you think that: gcc or clang can be considered as "universal compilers"; the only difference between neos and gcc/clang is that my front-end is dynamic rather that statically compiled for each language.
 
, I would really really hesitate to killfile you. For one, I could miss out on news on your graphics project thing. Is it possible to maybe make a "light" version of that, that doesn't depend on the generic compiler?
 
No, scripting is an important feature.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 23 06:55PM

On 23/03/2020 18:40, Mr Flibble wrote:
 
> Not impossible at all, you are displaying your ignorance if you think that: gcc or clang can be considered as "universal compilers"; the only difference between neos and gcc/clang is that my front-end is dynamic rather that statically compiled for each language.
 
> , I would really really hesitate to killfile you. For one, I could miss out on news on your graphics project thing. Is it possible to maybe make a "light" version of that, that doesn't depend on the generic compiler?
 
> No, scripting is an important feature.
 
By "clang" I of course meant "LLVM".
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Bonita Montero <Bonita.Montero@gmail.com>: Mar 23 08:03PM +0100

If you could express your prayers in C++ everything would be fine.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 23 01:22PM -0700

On 3/23/2020 12:03 PM, Bonita Montero wrote:
> If you could express your prayers in C++ everything would be fine.
 
#include <iostream>
 
int main()
{
std::cout << "God Damn Virus!\n";
 
return 0;
}
 
 
 
;^)
"Öö Tiib" <ootiib@hot.ee>: Mar 23 01:44PM -0700

On Monday, 23 March 2020 22:22:56 UTC+2, Chris M. Thomasson wrote:
 
> return 0;
> }
 
> ;^)
 
But every kid knows that it wasn't neither God nor Chinese but
the Reptilians.
<https://en.wikipedia.org/wiki/Reptilian_conspiracy_theory>
Bonita Montero <Bonita.Montero@gmail.com>: Mar 23 01:28PM +0100

> That becomes:
> threads[i] = thread(EntryPoint, i);
 
The assignment-operator of thread is move-only.
Bonita Montero <Bonita.Montero@gmail.com>: Mar 23 01:32PM +0100

>> That becomes:
>>                   threads[i] = thread(EntryPoint, i);
 
> The assignment-operator of thread is move-only.
 
Sorry, nonsense, move isn't necessary here.
"Öö Tiib" <ootiib@hot.ee>: Mar 23 05:36AM -0700

On Monday, 23 March 2020 14:29:02 UTC+2, Bonita Montero wrote:
> > That becomes:
> > threads[i] = thread(EntryPoint, i);
 
> The assignment-operator of thread is move-only.
 
What is your point? A rvalue of type std::thread can be assigned
as the quoted line of code does.
cdalten@gmail.com: Mar 23 06:10AM -0700

On Monday, March 23, 2020 at 3:33:27 AM UTC-7, Paavo Helde wrote:
> > thread &t = *reinterpret_cast<thread*>(&storage_for_threads[i]);
 
> You should avoid reinterpret_cast if possible, it's not well-behaved in
> general.
 
Captain numb nuts was told about this in a earlier thread. But just like everything else, the moron chooses to ignore this advice. Or maybe he doesn't ignore the advice and instead, is like...uhhh..what's a nice way to this this.. maybe he is mentally deficient.
Bonita Montero <Bonita.Montero@gmail.com>: Mar 23 02:17PM +0100


>> The assignment-operator of thread is move-only.
 
> What is your point? A rvalue of type std::thread can be assigned
> as the quoted line of code does.
 
Read my other post before responding overhasty.
I didn't consider that the temporary is implicitly moveable.
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)