Due to attempts to make C++ mostly compatible with the existing C code (which allows name collisions between object names and struct tags), C++ allows name collisions between class names and object names.

Which means that:

    struct data {
        static int member;
    };
    
    struct data2 {
        int member;
    };
    
    void f(data2&amp; data) {
        data.member = data::member;
    }

is legit code.


An example where both are valid, but refer to different objects:
```
#include &lt;iostream&gt;

struct A {
    int i;
};

struct B {
    int i;
    A B;
};

int main() {
    B x {0, 1};
    std::cout &lt;&lt; x.B.i &lt;&lt; &#39;\n&#39;;
    std::cout &lt;&lt; x.B::i &lt;&lt; &#39;\n&#39;;
}
```

See [live on coliru](//coliru.stacked-crooked.com/a/40e03237388e7c59).

There is difference between `a::b` and `a.b` where `::` implies that `a` used as namespace, which means that it is namespace or typename. Provided that C++ supports non-virtual plural inheritance and that a variable can have same name as a type, this strips chances of referencing wrong object. It&#39;s necessary for template metaprogramming.

Another example would be `&amp;B::foo` vs `&amp;B.foo` in context of class B. 

Let extend @Deduplicator example:
```
#include &lt;iostream&gt;

struct A {
    int i;
};

struct B : public A {
    int i;
    A A;
};

int main() {
    B x {1, 2};
    std::cout &lt;&lt; x.i &lt;&lt; &#39;\n&#39;;
    std::cout &lt;&lt; x.B::i &lt;&lt; &#39;\n&#39;;  // The same as the line above.
    std::cout &lt;&lt; x.A.i &lt;&lt; &#39;\n&#39;;
    std::cout &lt;&lt; x.A::i &lt;&lt; &#39;\n&#39;;  // Not the same as the line above.
}
```
[Live on Coliru Viewer][1]

Not having a possibility to differentiate with help of ::, which member we want to access, it is impossible to access members declared in a parent class with identical names.

  [1]: https://coliru.stacked-crooked.com/a/95a779f9e087dbc6

I got the following error during a `terraform plan` which occured in my pipeline:

    Error: Error locking state: Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed
    Lock Info:
    ID:        9db590f1-b6fe-c5f2-2678-8804f089deba
    Path:      ...
    Operation: OperationTypePlan
    Who:       ...
    Version:   0.12.25
    Created:   2020-05-29 12:52:25.690864752 +0000 UTC
    Info:      
    Terraform acquires a state lock to protect the state from being written
    by multiple users at the same time. Please resolve the issue above and try
    again. For most commands, you can disable locking with the &quot;-lock=false&quot;
    flag, but this is not recommended.

It is weird because I&#39;m sure there is no other concurrent plan.
Is there a way to deal with this? How should I remove this lock?

Terraform: Error acquiring the state lock: ConditionalCheckFailedException

I am getting this error when I try to use the .ix attribute of a pandas data frame to pull out a column, e.g. ```df.ix[:, &#39;col_header&#39;]```.

    AttributeError: &#39;DataFrame&#39; object has no attribute &#39;ix&#39;

The script worked this morning, but this afternoon I ran it in a new Linux environment with a fresh install of Pandas. Has anybody else seen this error before? I&#39;ve searched here and elsewhere but can&#39;t find it.


AttributeError: &#39;DataFrame&#39; object has no attribute &#39;ix&#39;

In C++, the operator `::` is used to access classes, functions and variables in a namespace or class.

If the language specification used `.` instead of `::` in those cases too like when accessing instance variables/methods of an object then would that cause possible ambiguities that aren&#39;t present with `::`?

Given that C++ doesn&#39;t allow variable names that are also a type name, I can&#39;t think of a case where that could happen.

Clarification: I&#39;m not asking why `::` was chosen over `.`, just if it could have worked too?

Would replacing &#39; :: &#39; with &#39; . &#39; create ambiguities in C++?

In C++, the operator <code>::</code> is used to access classes, functions and variables in a namespace or class.
If the language specification used <code>.</code> instead of <code>::</code> in those cases too like when accessing instance variables/methods of an object then would that cause possible ambiguities that aren't present with <code>::</code>?
Given that C++ doesn't allow variable names that are also a type name, I can't think of a case where that could happen.
Clarification: I'm not asking why <code>::</code> was chosen over <code>.</code>, just if it could have worked too?

I have a C++ background and I do fully understand and agree with the answers to this question: [Why is “using namespace std;” considered bad practice?][1] 

So I&#39;m astonished that, having some experience with C# now, I see the exact opposite there:
`using Some.Namespace;` is literally used everywhere. Whenever you start using a type, you add a using directive for its namespace first (if it isn&#39;t there already). I cannot recall having seen a `.cs`-file that didn&#39;t start with `using System; using System.Collections.Generic; using X.Y.Z; etc...`.
In fact, if you add a new file via the Visual Studio wizard, it automatically adds some using directives there, even though you may not need them at all. So, while in the C++ community you get basically lynched, C# even encourages doing this. At least this is how it appears to me.

Now, I do understand that using directives in C# and C++ are not exactly the same thing. Also, I do understand that one of the nastiest things you can do with `using namespace` in C++, namely putting it in a header file, has no equivalently nasty counterpart in C# due to the lack of a concept of header files and `#include`.

However, despite their differences, using directives in C# and C++ serve the same purpose, which is only having to type `SomeType` all the time, rather than the much longer `Some.Namespace.SomeType` (in C++ with `::` instead of `.`). And with this same purpose, also the danger appears to be the same to me: naming collisions.

In the best case this results in a compilation error, so you &quot;only&quot; have to fix it. In the worst case, it still compiles and the code silently does different things than you intended it to do. So my question is: **Why (apparently) are using directives considered so unequally bad in C# and C++?**

Some ideas of an answer that I have (none of these really satisfy me, though):

 - Namespaces tend to be much longer and much more nested in C# than in C++ (`std` vs. `System.Collection.Generic`). So, there is more desire and more gain in de-noising the code this way. But even if this is true, this argument only applies when we look at the standard namespaces. Custom ones can have any short name you like, in both C# and C++.
 
 - Namespaces appear to be much more &quot;fine granular&quot; in C# than in C++. As an example, in C++ the entire standard library is contained in `std` (plus some tiny nested namespaces like `chrono`) while in C# you have `System.IO`, `System.Threading`, `System.Text` etc. So, the risk of having naming collisions is smaller. However, this is only a gut feeling. I didn&#39;t actually count how many names you &quot;import&quot; with `using namespace std` and `using System`. And again, even if this is true, this argument applies only when looking at the standard namespaces. Your own ones can be designed as fine granular as you wish, in both C# and C++.

Are there more arguments? I&#39;m especially interested in actual hard facts (if there are any) and not so much in opinions.


  [1]: https://stackoverflow.com/q/1452721/9883438

Why is &quot;using System;&quot; not considered bad practice?

I&#39;m using a external library which at some point gives me a raw pointer to an array of integers and a size.

Now I&#39;d like to use `std::vector` to access and modify these values in place, rather than accessing them with raw pointers.

Here is an articifial example that explains the point:

    size_t size = 0;
	int * data = get_data_from_library(size);   // raw data from library {5,3,2,1,4}, size gets filled in
	
	std::vector&lt;int&gt; v = ????;                  // pseudo vector to be used to access the raw data
	
	std::sort(v.begin(), v.end());              // sort raw data in place

	for (int i = 0; i &lt; 5; i++)
	{
	  std::cout &lt;&lt; data[i] &lt;&lt; &quot;\n&quot;;             // display sorted raw data 
	}

Expected output:

	1
	2
	3
	4
	5


The reason is that I need to apply algorithms from `&lt;algorithm&gt;` (sorting, swaping elements etc.) on that data.

On the other hand changing the size of that vector would never be changed, so `push_back`, `erase`, `insert` are not required to work on that vector.

I could construct a vector based on the data from the library, use modify that vector and copying the data back to to library, but that would be two complete copies that I&#39;d like to avoid as the data set could be really big.

Using std::vector as view on to raw memory

According to [cppreference][1], the `operator!=` of many standard library types, including [`std::unordered_map::operator!=`][2] and [`std::unordered_set::operator!=`][3] is *removed* in C++20.

**What is the committee&#39;s rationale behind the decision?** Won&#39;t this make the comparison support asymmetric?


  [1]: http://en.cppreference.com/w/cpp
  [2]: https://en.cppreference.com/w/cpp/container/unordered_map/operator_cmp
  [3]: https://en.cppreference.com/w/cpp/container/unordered_set/operator_cmp

Removed operator!= in C++20 standard library

In C++ standard library there are functions to convert from string to numeric types:
```
stoi
stol
stoll
stoul
stoull
stof
stod
stold
```
but I find it tedious to use them in template code. Why there are no template functions something like:

```
template&lt;typename T&gt;
T sto(...)
```

to convert strings to numeric types?

I don&#39;t see any technical reason to not have them, but maybe I&#39;m missing something. They can be specialised to call the underlying named functions and use ```enable_if```/```concepts``` to disable non numeric types.

Are there any template friendly alternatives in the standard library to convert string to numeric types and the other way around in an efficient way? 

Template friendly string to numeric in C++

How does this work?

The idea is to make `abs(x)` use bitwise operators for integers (assuming 32 bit words):

    y = x &gt;&gt; 31
    (x + y) ^ y // This gives abs(x) (is ^ XOR)?






Absolute value abs(x) using bitwise operators and Boolean logic

This is something that has always been bugging me as a feature of C++ lambda expressions: The type of a C++ lambda expression is unique and anonymous, I simply cannot write it down. Even if I create two lambdas that are syntactically exactly the same, the resulting types are defined to be distinct. The consequence is, that a) lambdas can only be passed to template functions that allow the compile time, unspeakable type to be passed along with the object, and b) that lambdas are only useful once they are type erased via `std::function&lt;&gt;`.

Ok, but that&#39;s just the way C++ does it, I was ready to write it off as just an irksome feature of that language. However, I just learned that Rust seemingly does the same: Each Rust function or lambda has a unique, anonymous type. And now I&#39;m wondering: Why?

So, my question is this:  
**What is the advantage, from a language designer point of view, to introduce the concept of a unique, anonymous type into a language?**

Why design a language with unique anonymous types?

    #include &lt;compare&gt;
    
    struct A
    {
        int n;
    
        auto operator&lt;=&gt;(A const&amp; other) const
        {
            if (n &lt; other.n)
            {
                return std::strong_ordering::less;
            }
            else if (n &gt; other.n)
            {
                return std::strong_ordering::greater;
            }
            else
            {
                return std::strong_ordering::equal;
            }
        }
    
        // compile error if the following code is commented out.
        // bool operator==(A const&amp; other) const
        // { return n == other.n; }
    };
    
    int main()
    {   
        A{} == A{};
    }

See [online demo][1]

**Why must I provide** `operator ==` **when** `operator &lt;=&gt;` **is enough?**

  [1]: https://godbolt.org/z/x7T7r86zc

Why must I provide &#39;operator ==&#39; when &#39;operator &lt;=&gt;&#39; is enough?

Why does the TypeScript compiler compile its [optional chaining and null-coalescing](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html) operators, `?.` and `??`, to
```lang-js
// x?.y
x === null || x === void 0 ? void 0 : x.y;

// x ?? y
x !== null &amp;&amp; x !== void 0 ? x : y
```
instead of
```lang-js
// x?.y
x == null ? void 0 : x.y

// x ?? y
x != null ? x : y
```
?

Odds are that behind the scenes `== null` does the same two checks, but even for the sake of code length, it seems like single check would be cleaner. It adds many fewer parentheses when using a string of optional chaining, too.

Incidentally, I&#39;m also surprised that optional chaining doesn&#39;t compile to
```lang-js
x == null ? x : x.y
```
to preserve `null` vs `undefined`.  This has since been answered: https://stackoverflow.com/q/69856082/3120446

Content Type	Original Author	Original Content on Stackoverflow
Question	Jimmy R.T.	View Question on Stackoverflow
Solution 1 - C++	Kit.	View Answer on Stackoverflow
Solution 2 - C++	Deduplicator	View Answer on Stackoverflow
Solution 3 - C++	Swift - Friday Pie	View Answer on Stackoverflow
Solution 4 - C++	273K	View Answer on Stackoverflow

Would replacing ' :: ' with ' . ' create ambiguities in C++?

C++ Problem Overview

C++ Solutions

Solution 1 - C++

Solution 2 - C++

Solution 3 - C++

Solution 4 - C++

AttributeError: 'DataFrame' object has no attribute 'ix'

Terraform: Error acquiring the state lock: ConditionalCheckFailedException

Attributions