<div dir="ltr"><div dir="ltr">Also, this behaviour that may seem weird from programmers coming from C# is quite familiar to those coming from C++.<div><br></div><div><font face="monospace">int i1 = 1;</font></div><div><font face="monospace">int i2 = 1;</font></div><div><font face="monospace">int* p1 = &i1;</font></div><div><font face="monospace">int* p2 = &i2;</font></div><div><font face="monospace">std::cout << (i1 == i2) << std::endl; // prints true</font></div><div><font face="monospace">std::cout << (p1 == p2) << std::endl; // prints false</font></div><div><br></div><div>Atte.<br></div><div>Pedro.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 31 de out. de 2023 às 04:34, Jens Lideström <<a href="mailto:jens@lidestrom.se">jens@lidestrom.se</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Remember that C# has its own quirks regarding the behaviour of ==.<br>
<br>
Example of the behaviour in C#:<br>
<br>
```<br>
string s1 = new String("1");<br>
string s2 = new String("1");<br>
object o1 = s1;<br>
object o2 = s2;<br>
Console.WriteLine(s1 == s2); // True, overload for string kicks in<br>
Console.WriteLine(o1 == o2); // False, reference equality!<br>
<br>
int? i1 = 1;<br>
int? i2 = 1;<br>
object o1 = i1;<br>
object o2 = i2;<br>
Console.WriteLine(i1 == i2); // True, overload for Nullable<int> kicks <br>
in<br>
Console.WriteLine(o1 == o2); // False, reference equality!<br>
```<br>
<br>
That is, in C# the behaviour of == varies for the same objects, <br>
depending on what types the references have.<br>
<br>
Both approaches have their advantages and disadvantages. But to me <br>
Java's approach seems more sensible: For reference types == always means <br>
reference equality.<br>
<br>
Best regards,<br>
Jens Lideström<br>
<br>
On 2023-10-31 03:10, tzengshinfu wrote:<br>
<br>
> Thank you, Anatoly, for informing me about `IntegerCache`.<br>
> As a developer experienced in C# and JavaScript/TypeScript, I am <br>
> currently responsible for migrating our in-house systems from C# to <br>
> Java.<br>
> I also have the responsibility of training and sharing knowledge with <br>
> others.<br>
> <br>
> I was surprised by the following result in Java:<br>
> <br>
> ```java<br>
> Integer int1 = 100;<br>
> Integer int2 = 100;<br>
> Integer int3 = int1 + 100;<br>
> Integer int4 = int2 + 100;<br>
> out.println(int3 == int4); // false<br>
> ```<br>
> <br>
> This is different from how it works in C#:<br>
> <br>
> ```C#<br>
> Int32 int1 = 100;<br>
> Int32 int2 = 100;<br>
> Int32 int3 = int1 + 100;<br>
> Int32 int4 = int2 + 100;<br>
> Console.Write(int3 == int4); // True<br>
> ```<br>
> <br>
> Now, I understand that Java's design philosophy (thanks to Brian for <br>
> patiently explaining) leads to this behavior.<br>
> I will make an effort to understand how this works under the hood and <br>
> include it in my Java FAQ documentation.<br>
> My initial thoughts and suggestions were aimed at colleagues who are <br>
> also transitioning from other programming languages and newcomers to <br>
> Java who bring their language experiences.<br>
> Naturally, they might find the unexpected results in certain use cases, <br>
> and I hope to find ways to make this learning curve smoother without <br>
> disrupting the existing framework.<br>
> <br>
> Without breaking the current architecture, both Solution A (changing <br>
> String1 == String2 to String::equals()) and Solution B (introducing a <br>
> new string/str class to replace the String class) are unfeasible <br>
> (thanks to Nathan for preventing "I think it's rarely used, but in <br>
> reality, it's not, and everything breaks").<br>
> <br>
> Can I propose a Solution C?<br>
> <br>
> Solution C: Introduce the === and !== operators for value comparison <br>
> (equivalent to Object::equals()).<br>
> <br>
> For example:<br>
> <br>
> ```java<br>
> if (Integer4 === Integer1 + Integer2 + Integer3) {<br>
> // Do something...<br>
> }<br>
> ```<br>
> <br>
> Would be equivalent to:<br>
> <br>
> ```java<br>
> if (Integer4.equals(Integer1 + Integer2 + Integer3)) {<br>
> // Do something...<br>
> }<br>
> ```<br>
> <br>
> From a visual perspective, I believe that the === and !== operators can <br>
> reduce the chances of typos and make the code look cleaner, with fewer <br>
> parentheses compared to using equals().<br>
> Sometimes, symbols can convey meaning more clearly than text. This idea <br>
> stems from my experience with Delphi, where the use of keywords like <br>
> begin and end mixed with variable declarations and expressions made <br>
> code difficult to read in a plain text editor, despite IDE features <br>
> like highlighting and automatic formatting. Java's use of {} solved <br>
> this issue.<br>
> However, there are also counterexamples, such as Rust's code, where <br>
> excessive symbols may contribute to a steep learning curve.<br>
> <br>
> /* GET BETTER EVERY DAY */</blockquote></div></div>