Sunday, March 8, 2020

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

jacobnavia <jacob@jacob.remcomp.fr>: Mar 08 09:30PM +0100

Le 07/03/2020 à 06:35, Real Troll a écrit :
 
> It saves you filling out the form!!!!
 
Interesting. A document of about 100 pages just to explain de
differences between C++17 and C++14.
 
C++ programmers must have big brains, the standard of C++17 is 1633
pages long! Imagine how much brain space that takes...
 
The whole bible (King James edition) has 1513 pages...
 
And everybody is happy of course. The committee goes on adding and
adding features, then adding features to fix added features, then adding
features to fix the fixings...
 
Is anyone following? Maybe, some enthusiast people are always trying to
learn the latest fad, but this incredible featurism is leading the
language into a pit it will never be able to get out.
 
Just too complex, too much time needed to master a small part of it that
could be useful... It is SO BIG that a beginner has no chance in the
first few years, of understanding why something compiles or why it doesn't.
Daniel <danielaparker@gmail.com>: Mar 08 03:52PM -0700

On Sunday, March 8, 2020 at 4:31:10 PM UTC-4, jacobnavia wrote:
 
> Interesting. A document of about 100 pages just to explain de
> differences between C++17 and C++14.
 
Only 100?
 
C++ Move Semantics - The Complete Guide, _started_ with 110 pages, and, as
the author explains, "...the content grows with new chapters, examples, and
caveats about the features of move semantics and I integrate all feedback I
get for the pages already published" - https://leanpub.com/cppmove
 
Daniel
Juha Nieminen <nospam@thanks.invalid>: Mar 08 11:12PM

> Just too complex, too much time needed to master a small part of it that
> could be useful... It is SO BIG that a beginner has no chance in the
> first few years, of understanding why something compiles or why it doesn't.
 
Then don't use it. Your infantile whining is useless. Grow up.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 07 04:05PM -0800


> as
 
> if ("android.intent.action.BOOT_COMPLETED").equals(intent.getAction())
 
> Is a bad practice. Because in the above case, the first catches the error at runtime while the other doesn't. While this might be okay in C++, carry this kind of practice over to other programming languages has some really really bad consequences.
 
Fwiw, in C++:
 
(nullptr != function())
 
and:
 
(function() != nullptr)
 
will give the same results.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 07 04:09PM -0800

On 3/7/2020 4:05 PM, Chris M. Thomasson wrote:
> On 3/7/2020 5:47 AM, cdalten@gmail.com wrote:
>> On Friday, March 6, 2020 at 8:34:18 PM UTC-8, James Kuyper wrote:
>>> On Friday, March 6, 2020 at 7:00:51 PM UTC-5, cda...@gmail.com wrote:
[...]
 
> and:
 
> (function() != nullptr)
 
> will give the same results.
 
#include <iostream>
 
void* function()
{
return nullptr;
}
 
int main()
{
bool a = (function() != nullptr);
bool b = (nullptr != function());
 
std::cout << "a = " << a << ", b = " << b << "\n";
 
return 0;
}
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 07 04:53PM -0800


> as
 
> if ("android.intent.action.BOOT_COMPLETED").equals(intent.getAction())
 
> Is a bad practice. Because in the above case, the first catches the error at runtime while the other doesn't. While this might be okay in C++, carry this kind of practice over to other programming languages has some really really bad consequences.
 
I know very little about java, other than that, in some ways, it looks a
lot like C++. Would you care to explain, in terms suitable to my level
of java expertise, precisely what the two forms do, and why it is that
only one of the two forms catches the error?
 
My naive expectation would be that both forms retrieve from "intent"
something that is called an Action, and that an Action either is, or at
least, can be compared with, a character string. Then both forms carry
out precisely such a comparison, returning some kind of boolean result.
It's not clear to me how this code has anything to do with "catching an
error", nor why the two forms might differ in their ability to do so.
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Mar 07 10:23PM -0500

James Kuyper wrote:
> out precisely such a comparison, returning some kind of boolean result.
> It's not clear to me how this code has anything to do with "catching an
> error", nor why the two forms might differ in their ability to do so.
 
IIRC if getAction returns null,
 
"androind.intent.action.BOOT_COMPLETED".equals(intent.getAction())
 
won't throw, just returns false; but
 
intent.getAction().equals("android.intent.action.BOOT_COMPLETED")
 
will throw.
 
Usually, you would do something like class Util { public static AreEqual(Object
o1, Object o2) {/*obvious 9 yards*/} } and then use Util.AreEqual instead of
equals if you want null and non-null references to be comparable.
 
-Pavel
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 08 09:01AM

On Sun, 2020-03-08, Pavel wrote:
 
> won't throw, just returns false; but
 
> intent.getAction().equals("android.intent.action.BOOT_COMPLETED")
 
> will throw.
 
Ah, cdalten's argument finally makes sense. IMO, that is caused by
things in Java which look like objects really being more like
pointers, which may be null. And apparently support for that in
library functions, so that String.equals(null) == false.
 
That's IMO a weirdness in Java which shouldn't affect how we write
C++ code. We're responsible for not creating null references and
for not dereferencing null pointers.
 
(I dislike 'if (nullptr == expr)' anyway, but for different reasons.)
 
> Usually, you would do something like class Util { public static AreEqual(Object
> o1, Object o2) {/*obvious 9 yards*/} } and then use Util.AreEqual instead of
> equals if you want null and non-null references to be comparable.
 
But it seems here the String class tries to be helpful; no doubt most
people will use that rather than write wrappers.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 08 04:57PM -0400

On 3/8/20 5:01 AM, Jorgen Grahn wrote:
> things in Java which look like objects really being more like
> pointers, which may be null. And apparently support for that in
> library functions, so that String.equals(null) == false.
 
Ah, that makes sense now. In C++, you could get the same problem by
providing a function with two (or more) overloads:
 
bool operator==(const A*left, const B*right) {
if(!left) throw();
if(!right) return false;
// compare *left with *right
}
 
and
 
bool operator==(const B*left, const A*right) {
if(!left) throw();
if(!right) return false;
// compare *left with *right
}
 
The syntax for using such overloads would be quite different from the
syntax of his Java example. However, to be fair, the syntax of his Java
example was quite different from the syntax of the C++ code he
originally objected to as
 
However, while C++ is flexible enough to reproduce this problem, writing
C++ code that way wouldn't be at all reasonable. First of all, one would
ordinarily use references, not pointers, which wouldn't allow you to do
anything of the kind. Secondly, written this way, the asymmetry of the
two overloads sticks out like a sore thumb - it's implausible that it
would never get
 
> That's IMO a weirdness in Java which shouldn't affect how we write
> C++ code. We're responsible for not creating null references and
> for not dereferencing null pointers.
 
Agreed.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 08 02:16PM -0700

On 3/8/2020 1:01 AM, Jorgen Grahn wrote:
> things in Java which look like objects really being more like
> pointers, which may be null. And apparently support for that in
> library functions, so that String.equals(null) == false.
 
Perfect.
 
 
> That's IMO a weirdness
 
Agreed.
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 08 02:21PM -0700

On 3/7/2020 7:23 PM, Pavel wrote:
 
> IIRC if getAction returns null,
 
> "androind.intent.action.BOOT_COMPLETED".equals(intent.getAction())
 
> won't throw, just returns false;
 
Okay.
 
but
 
> intent.getAction().equals("android.intent.action.BOOT_COMPLETED")
 
> will throw.
 
A little odd to me. intent.getAction().equals will throw on null, yet
the equals function for the string literal will not because its just
using intent.GetAction(), nothing more. I see it, but it seems odd. the
equals function behaves differently. Thanks.
 
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)