That warning is telling you that there was a subtle ABI change (actually a conformance fix) between 6 and 7.1, such that libraries built with 6.x or earlier may not work properly when called from code built with 7.x (and vice-versa). As long as all your C++ code is built with GCC 7.1 or later, you can safely ignore this warning. To disable it, pass `-Wno-psabi` to the compiler.

For more details on the context of the change, see [the GCC 7 changelog][1], and [the associated bug][2].


  [1]: https://gcc.gnu.org/gcc-7/changes.html
  [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728

The VS solutions I often work with consist of a **single executable project** (console app, web app) and **many class library projects** that are all referenced by the executable.

When working with NuGet and installing packages, there&#39;s often an `app.config` file created for each project, usually containing nothing else than a list of binding redirects that consolidate versions of referenced assemblies. Sometimes there&#39;s some third-party library-specific content (like Entity Framework config section), but let&#39;s leave that aside for now.

When I build the solution and use the binaries of the main executable project, I see all the class library project assemblies in the build output together with the corresponding `*.config` files (the `app.config` file gets renamed to `AssemblyName.config` when built).

When launching the main executable, do the config files of the class library assemblies take any effect? Or is it just the `app.config` file of the executable that has an effect in this case? What if there are some binding redirects set up on some of the class library projects, and some different binding redirects set up on the main executable project &amp;mdash; How are these combined, which take priority?

I&#39;ve tried to research this online and from what I&#39;ve read, it looks to me like the `app.config` files for non-executable assemblies are useless (with regards to binding redirects). Can someone confirm this or elaborate a bit more on the topic?

If it is that way, is it actually undesirable to have these `app.config` files created by NuGet in class libraries if they contain just the binding redirects? It feels to me that NuGet shouldn&#39;t create those binding redirects for class library projects, as it will only increase the confusion about what settings are actually applied.

---

I found these existing Stack Overflow questions on the topic, but their **accepted answers are actually contradictory even when they&#39;re marked as duplicates of each other**.

- https://stackoverflow.com/questions/22227675/why-nuget-adds-app-config-with-assemblybinding-to-library-projects-during-a-nuge

- https://stackoverflow.com/questions/21795507/is-the-bindingredirect-config-file-needed-or-all-assemblies-in-an-application

[The accepted answer to the first question](https://stackoverflow.com/a/22228738/108374) mentions that app.config files are actually used during compile-time, which means they could have effect. Sources like [MSDN](http://msdn.microsoft.com/en-us/library/7wd6ex19.aspx) and [MSBuild source code](https://github.com/Microsoft/msbuild/blob/5df95761c73cd6b1b2c35a827ed168e32546388e/src/Tasks/AssemblyDependency/ResolveAssemblyReference.cs#L2088-L2100) are cited there as a proof it&#39;s used during compile-time. Unfortunately, I&#39;m not proficient enough in MSBuild to understand how it&#39;s being used, and if it&#39;s really a valid argument.

### Can anybody describe an example scenario to prove that an app.config with binding redirects for a class library can do anything?

Do binding redirects in app.config for class libraries do anything?

For example I have dynamic filter for my list of books where I can set specific color, authors and categories.
This filter can set multiple colors at once and multiple categories.

       Book &gt; Red, Blue &gt; Adventure, Detective.

How can I add &quot;where&quot; conditionally?


      firebase
        .firestore()
        .collection(&quot;book&quot;)
        .where(&quot;category&quot;, &quot;==&quot;, )
        .where(&quot;color&quot;, &quot;==&quot;, )
        .where(&quot;author&quot;, &quot;==&quot;, )

        .orderBy(&quot;date&quot;)
        .get()
        .then(querySnapshot =&gt; {...


Firestore: Multiple conditional where clauses

I have a C++ project that builds fine and without warnings with gcc 7.2 on x86 Linux and Windows, I needed to port it to an ARM device so I tried to crosscompile it with an &quot;arm-linux-gnueabihf&quot; gcc 7.2 that runs on my x86 machine, it builds but I get a lot of warnings of this kind

    note: parameter passing for argument of type &#39;__gnu_cxx::__normal_iterator&lt;P2d*, std::vector&lt;P2d&gt; &gt;&#39; changed in GCC 7.1
    _M_realloc_insert(end(), __x);

and

    /opt/armv7-gcc-2017/arm-linux-gnueabihf/include/c++/7.2.0/bits/vector.tcc:105:21: note: parameter passing for argument of type &#39;__gnu_cxx::__normal_iterator&lt;cpzparser::Anchor*, std::vector&lt;cpzparser::Anchor&gt; &gt;&#39; changed in GCC 7.1
        _M_realloc_insert(end(), std::forward&lt;_Args&gt;(__args)...);

or

    /opt/armv7-gcc-2017/arm-linux-gnueabihf/include/c++/7.2.0/bits/vector.tcc:394:7: note: parameter passing for argument of type &#39;std::vector&lt;cpzparser::PointEntity&gt;::iterator {aka __gnu_cxx::__normal_iterator&lt;cpzparser::PointEntity*, std::vector&lt;cpzparser::PointEntity&gt; &gt;}&#39; changed in GCC 7.1
           vector&lt;_Tp, _Alloc&gt;::


the generated executable seems to work fine but I am worried by the presence of all those warnings since I have no idea of what they mean.. any clue?




What does the gcc warning &quot;project parameter passing for X changed in GCC 7.1&quot; mean?

I have a C++ project that builds fine and without warnings with gcc 7.2 on x86 Linux and Windows, I needed to port it to an ARM device so I tried to crosscompile it with an "arm-linux-gnueabihf" gcc 7.2 that runs on my x86 machine, it builds but I get a lot of warnings of this kind
<pre><code class="hljs language-css">note: parameter passing for argument of type '__gnu_cxx::__normal_iterator&#x3C;P2d*, std::vector&#x3C;P2d> >' changed in GCC 7.1
_M_realloc_insert(end(), __x);
</code></pre>
and
<pre><code class="hljs language-rust">/opt/armv7-gcc-2017/arm-linux-gnueabihf/include/c++/7.2.0/bits/vector.tcc:105:21: note: parameter passing for argument of type '__gnu_cxx::__normal_iterator&#x3C;cpzparser::Anchor*, std::vector&#x3C;cpzparser::Anchor> >' changed in GCC 7.1
 _M_realloc_insert(end(), std::forward&#x3C;_Args>(__args)...);
</code></pre>
or
<pre><code class="hljs language-rust">/opt/armv7-gcc-2017/arm-linux-gnueabihf/include/c++/7.2.0/bits/vector.tcc:394:7: note: parameter passing for argument of type 'std::vector&#x3C;cpzparser::PointEntity>::iterator {aka __gnu_cxx::__normal_iterator&#x3C;cpzparser::PointEntity*, std::vector&#x3C;cpzparser::PointEntity> >}' changed in GCC 7.1
 vector&#x3C;_Tp, _Alloc>::
</code></pre>
the generated executable seems to work fine but I am worried by the presence of all those warnings since I have no idea of what they mean.. any clue?

`std::is_pod` will be probably deprecated in C++20.  
What&#39;s the reason for this choice? What should I use in place of `std::is_pod` to know if a type is actually a POD?

Why is std::is_pod deprecated in C++20?

I need to insert values into the beginning of a `std::vector` and I need other values in this vector to be pushed to further positions for example: something added to beginning of a vector and values moved from position 1 to 2, from 2 to 3 etc.

How can I do that?

How can I insert element into beginning of vector?

When I work on my personal C and C++ projects I usually put `file.h` and `file.cpp` in the same directory and then `file.cpp` can reference `file.h` with a `#include &quot;file.h&quot;` directive.

However, it is common to find out libraries and other kinds of projects (like the linux kernel and freeRTOS) where all `.h` files are placed inside an `include/` directory, while `.cpp` files remain in another directory. In those projects, `.h` files are also included with `#include &quot;file.h&quot;` instead of `#include &quot;include/file.h&quot;` as I was hoping.

I have some questions about all of this:

 1. What are the advantages of this file structure organization?
 2. Why are `.h` files inside `include/` included with `#include &quot;file.h&quot;` instead of `#include &quot;include/file.h&quot;`? I know the real trick is inside some Makefile, but is it really better to do that way instead of making clear (in code) that the file we want to include is actually in the `include/` directory?



Why create an include/ directory in C and C++ projects?

In C/C++, why should one use `abs()` or `fabs()` to find the absolute value of a variable without using the following code?

    int absoluteValue = value &lt; 0 ? -value : value;

Does it have something to do with fewer instructions at lower level?

Why use abs() or fabs() instead of conditional negation?

I&#39;m preparing for my CPP exam and one of the question is: Can you delete default class constructor and if so, what would be the reason to do so? OK, so obviously you can do it:

    class MyClass 
    { 
      public: 
        MyClass() = delete; 
    };


but I do not understand why would you do it? 


What&#39;s the point of deleting default class constructor?

I am trying to use a supplier&#39;s library in combination with my C++ application. The library is largely based on C, which is normally not a problem with the `extern &quot;C&quot;` option, but I ran into an issue that the C++ compiler does not accept. 

I simplified my code into the following example files. header.h represents a header from the suppier library, main.c/cpp are my own files. My real application is a C++ application, so I want to get it to work with main.cpp. 

header.h (note the line `u64 u64;`):

    #ifndef HEADER_H
    #define HEADER_H

    #include &lt;stdint.h&gt;

    typedef uint64_t u64;

    union teststruct {
        u64 u64;
        struct {
            u64 x:32;
            u64 y:32;
        } s;
    };

    #endif

main.c:

    #include &lt;stdio.h&gt;
    #include &quot;header.h&quot;

    int main() {
        union teststruct a;
        a.u64=5;
        printf(&quot;%x\n&quot;, a.u64);
    
        return 0;
    }

main.cpp (same as main.c but with an extra `extern &quot;C&quot;` statement): 

    #include &lt;stdio.h&gt;

    extern &quot;C&quot; {
    #include &quot;header.h&quot;
    }

    int main() {
        union teststruct a;
        a.u64=5;
        printf(&quot;%x\n&quot;, a.u64);
        
        return 0;
    }

Compiling main.c using the line

    gcc -o test main.c

compiles without problems. However, compiling the C++ version using the g++ compiler with the command 

    g++ -o test main.cpp

gives the following compiler errors:

    In file included from main.cpp:12:0:
    header.h:11:9: error: ‘u64’ does not name a type
             u64 x:32;
             ^
    header.h:12:9: error: ‘u64’ does not name a type
             u64 y:32;
             ^

The issue is that the supplier used the same name (u64) for both the type and the variable name, which seems like a bad idea to begin with, but gcc apparently accepts it. I do not want to change the library (i.e. header.h) as it is very large,this occurs a lot in the code, and I occasionally get updates for it. Is there a way to make g++ accept this combination, or a way to modify main.cpp to make it compile _without_ changing header.h?

C vs C++ compilation incompatibility - does not name a type

**Case 1:**

    #include &lt;iostream&gt;
    
    int main()
    {
        double d = 15.50;
        std::cout&lt;&lt;(d/0.0)&lt;&lt;std::endl;
    }

It compiles without any warnings and prints `inf`. OK, C++ can handle division by zero, ([see it live](https://wandbox.org/permlink/qnpr8cM4W7rKlNid)).

But,

**Case 2:** 

    #include &lt;iostream&gt;
    
    int main()
    {
        double d = 15.50;
        std::cout&lt;&lt;(d/0)&lt;&lt;std::endl;
    }

The compiler gives the following warning ([see it live](https://wandbox.org/permlink/9cRSsWqewKxqN2CT)):

    warning: division by zero [-Wdiv-by-zero]
         std::cout&lt;&lt;(d/0)&lt;&lt;std::endl;
	 
Why does the compiler give a warning in the second case? 

Is `0 != 0.0`?

**Edit:**

    #include &lt;iostream&gt;
    
    int main()
    {
        if(0 == 0.0)
            std::cout&lt;&lt;&quot;Same&quot;&lt;&lt;std::endl;
        else
            std::cout&lt;&lt;&quot;Not same&quot;&lt;&lt;std::endl;
    }

**output:**

    Same



C++ warning: division of double by zero

### Background

In the last year I was using the nlohmann json library&lt;sup&gt;[1]&lt;/sup&gt; and was cross-compiling on x86_64 using GCC 5.x `arm-linux-gnueabi-*` with no warnings. When I updated GCC to a newer version, GCC would generate pages of cryptic diagnostic notes. For example, here is one of the notes

    In file included from /usr/arm-linux-gnueabi/include/c++/7/vector:69:0,
                 from include/json.hpp:58,
                 from src/write_hsi.cpp:23:
    /usr/arm-linux-gnueabi/include/c++/7/bits/vector.tcc: In member function ‘void std::vector&lt;_Tp, _Alloc&gt;::_M_realloc_insert(std::vector&lt;_Tp, _Alloc&gt;::iterator, _Args&amp;&amp; ...) [with _Args = {nlohmann::basic_json&lt;std::map, std::vector, std::__cxx11::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;, bool, long long int, long long unsigned int, double, std::allocator, nlohmann::adl_serializer&gt;}; _Tp = nlohmann::basic_json&lt;&gt;; _Alloc = std::allocator&lt;nlohmann::basic_json&lt;&gt; &gt;]’:
    /usr/arm-linux-gnueabi/include/c++/7/bits/vector.tcc:394:7: note: parameter passing for argument of type ‘std::vector&lt;nlohmann::basic_json&lt;&gt;, std::allocator&lt;nlohmann::basic_json&lt;&gt; &gt; &gt;::iterator {aka __gnu_cxx::__normal_iterator&lt;nlohmann::basic_json&lt;&gt;*, std::vector&lt;nlohmann::basic_json&lt;&gt;, std::allocator&lt;nlohmann::basic_json&lt;&gt; &gt; &gt; &gt;}’ changed in GCC 7.1
       vector&lt;_Tp, _Alloc&gt;::
       ^~~~~~~~~~~~~~~~~~~
    /usr/arm-linux-gnueabi/include/c++/7/bits/vector.tcc: In member function ‘nlohmann::basic_json&lt;ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer&gt; nlohmann::basic_json&lt;ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType, JSONSerializer&gt;::parser::parse_internal(bool) [with ObjectType = std::map; ArrayType = std::vector; StringType = std::__cxx11::basic_string&lt;char&gt;; BooleanType = bool; NumberIntegerType = long long int; NumberUnsignedType = long long unsigned int; NumberFloatType = double; AllocatorType = std::allocator; JSONSerializer = nlohmann::adl_serializer]’:
    /usr/arm-linux-gnueabi/include/c++/7/bits/vector.tcc:105:21: note: parameter passing for argument of type ‘__gnu_cxx::__normal_iterator&lt;nlohmann::basic_json&lt;&gt;*, std::vector&lt;nlohmann::basic_json&lt;&gt;, std::allocator&lt;nlohmann::basic_json&lt;&gt; &gt; &gt; &gt;’ changed in GCC 7.1
    _M_realloc_insert(end(), std::forward&lt;_Args&gt;(__args)...);
    ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It was easy to find a solution, namely by adding `-Wno-psabi` to the compiler options. In fact, that was the fix implemented in the library.&lt;sup&gt;[2]&lt;/sup&gt;

I understand the basics of Application Binary Interfaces (ABIs) and processor-specific ABIs (psABIs). For reference, this answer&lt;sup&gt;[11]&lt;/sup&gt; gives a quick overview of ABIs:

&gt; An ABI (_**Application Binary Interface**_) is a standard that defines a mapping between low-level concepts in high-level languages and the abilities of a specific hardware/OS platform&#39;s machine code. That includes things like:
&gt; 
&gt;  - how C/C++/Fortran/... **data types** are laid out in memory (data sizes / alignments)
&gt;  - how nested **function calls** work (where and how the information on how to return to a function&#39;s caller is stored, where in the CPU registers and/or in memory function arguments are passed)
&gt;  - how **program startup / initialization** works (what data format an &quot;executable&quot; has, how the code / data is loaded from there, how DLLs work ...)
&gt; 
&gt; The answers to these are:
&gt; 
&gt;  - _language-specific_ (hence you&#39;ve got a C ABI, C++ ABI, Fortran ABI, Pascal ABI, ... even the Java bytecode spec, although targeting a &quot;virtual&quot; processor instead of real hardware, is an ABI),
&gt;  - _operating-system specific_ (MS Windows and Linux on the same hardware use a different ABI),
&gt;  - _hardware/CPU-specific_ (the ARM and x86 ABIs are different).
&gt;  - _evolving over (long) time_ (existing ABIs have often been updated / rev&#39;ed so that new CPU features could be made use of, like, say, specifying how the x86 SSE registers are to be used by apps was of course only possible once CPUs _had_ these regs, therefore existing ABIs needed to be clarified).

So the ABI is the overarching component, and one of its components (the &quot;hardware/CPU-specific&quot; details) is the psABI.

### My Issue

The problem I am having is

 1. I don&#39;t like universally disabling warnings without understanding the implications.
 2. The advice &quot;use `-Wno-psabi` to make the notes go away&quot; seems to be pretty common advice for these types of diagnostic notes that &quot;suddenly appear&quot; after a compiler upgrade.&lt;sup&gt;[2]&lt;/sup&gt;&lt;sup&gt;[3]&lt;/sup&gt;&lt;sup&gt;[4]&lt;/sup&gt; Even the one of the GCC developers suggest doing this.&lt;sup&gt;[5]&lt;/sup&gt;
 3. Neither `-Wpsabi` nor `-Wno-psabi` are documented&lt;sup&gt;[6]&lt;/sup&gt; in the GCC manual.&lt;sup&gt;[7]&lt;/sup&gt;

As a result I am not really sure what exactly `-Wno-psabi` will and will not affect. A related option `-Wabi` *is* documented:&lt;sup&gt;[8]&lt;/sup&gt;

&gt; `-Wabi (C, Objective-C, C++ and Objective-C++ only)`
&gt;
&gt;    Warn when G++ it generates code that is probably not compatible with the vendor-neutral C++ ABI...
&gt;
&gt; It also warns about psABI-related changes. The known psABI changes at this point include: 
&gt;
&gt; - For SysV/x86-64, unions with long double members are passed in memory as specified in psABI. For example: 
&gt;
&gt; `    union U {`
&gt; `     long double ld;`
&gt; `     int i;`
&gt; `    };`
&gt;
&gt; `union U` is always passed in memory.

My understanding of this all is

1. `-Wabi` will generate warnings when there is a psABI change.
2. GCC 7 fixed an ABI bug&lt;sup&gt;[9]&lt;/sup&gt; introduced in GCC 5 that affects ARM targets.
    - In the release notes it is stated &quot;this is an ABI change.&quot;&lt;sup&gt;[10]&lt;/sup&gt;
    - For some reason the release notes state that the related diagnostic notes are generated when using the undocumented `-Wpsabi`, not the documented `-Wabi`.
    - This ABI change is not mentioned in the manual.
3. Putting together &quot;this is an ABI change&quot; and &quot;use `-Wpsabi`&quot;, it appears to me this is *specifically* a psABI change, not a different kind of ABI change. (In reality it is a change in GCC&#39;s implementation of the psABI, not the psABI itself)

I know that documentation isn&#39;t always up to date, especially for something that is a known undocumented option. But my concern is that &quot;use `-Wno-psabi`&quot; seems to be the standard response for several different kinds of these cryptic diagnostic notes. But, in my basic understanding of ABIs, isn&#39;t an ABI change a big deal? Shouldn&#39;t I be concerned about an ABI change, rather than just making the message go away? Between the undocumented stuff and some of the finer details of ABI vs psABI, I&#39;m not really sure...

For example, if I add `-Wno-psabi` to my makefile to make those notes go away, what if there is another ABI change in the future that *does* affect my project? Have I effectively silenced future warnings or notes that may be important?

Also, even though we are told &quot;if you recompile all the code, there is nothing to worry about,&quot;&lt;sup&gt;[5]&lt;/sup&gt; what exactly is &quot;all the code&quot;? Is that my source code? glibc? Any other system-wide shared library I might be using?

### References

1. https://github.com/nlohmann/json
2. https://github.com/nlohmann/json/issues/658
3. https://stackoverflow.com/a/48149400
4. https://stackoverflow.com/a/13915796/10270632
5. https://gcc.gnu.org/ml/gcc/2017-05/msg00073.html
6. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81831
7. https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc
8. https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/C_002b_002b-Dialect-Options.html
9. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
10. https://gcc.gnu.org/gcc-7/changes.html
11. https://stackoverflow.com/a/8063350

What exactly does GCC&#39;s -Wpsabi option do? What are the implications of supressing it?

I have used the gcc command on the terminal to compile C programs but all of a sudden, after an update to my Mac&#39;s OS (to macOS 10.14 Mojave, and XCode 10.0), I started receiving the message:

    test.c:8:10: fatal error: stdio.h: No such file or directory
    #include &lt;stdio.h&gt;
             ^~~~~~~~~
    compilation terminated.

I already have gcc installed as I can find it in `/usr/local/bin` and there really is a gcc in there. I tried running the same file on my other iMac and it worked without any issue. 

I tried running `xcode-select --install` and it already was installed, hence it didn&#39;t fix the issue I&#39;m having now. I&#39;m guessing that the path is messed up as it doesn&#39;t seem like it can find `gcc` after I started copying and pasting some commands from other resources to solve this issue.

Would like some help on this.

Can&#39;t compile C program on a Mac after upgrade to Mojave

With most C/C++ compilers, there&#39;s a flag passable to the compiler, `-march=native`, which tells the compiler to tune generated code for the micro-architecture and ISA extensions of the host CPU. Even if it doesn&#39;t go by the same name, there&#39;s typically an equivalent option for LLVM-based compilers, like `rustc` or `swiftc`.

In my own experience, this flag can provide massive speedups for numerically-intensive code, and it _sounds_ like it would be free of compromises for code you&#39;re just compiling for your own machine. That said, I don&#39;t think I&#39;ve seen any build system or static compiler that enables it by default:

- Obviously, any command-line compiler executable that requires you to pass it doesn&#39;t use it by default.

- I can&#39;t think of any IDE that enables this by default.

- I can&#39;t think of any common build system I&#39;ve worked with (`cmake`, `automake`, `cargo`, `spm`, etc.) that enables it by default, even for optimized builds.

I can think of a few reasons for this, but none of them are really satisfactory:

- Using `-march=native` is inappropriate for binaries that will be distributed to other machines. That said, I find myself compiling sources for my own machine much more often than for others, and this doesn&#39;t explain its lack of use in debug builds, where there&#39;s no intention for distribution.

- At least on Intel x86 CPUs, it&#39;s my understanding that using AVX instructions infrequently could degrade performance or power efficiency, since the AVX unit is powered down when not in use, requiring it to be powered up to be used, and a lot of Intel CPUs downclock to run AVX instructions. Still, it only explains why AVX wouldn&#39;t be enabled, not why the code wouldn&#39;t be tuned for the particular micro-architecture&#39;s handling of regular instructions.

- Since most x86 CPUs use fancy out-of-order superscalar pipelines with register renaming, tuning code for a particular micro-architecture probably isn&#39;t particularly important. Still, if it _could_ help, why not use it?

Content Type	Original Author	Original Content on Stackoverflow
Question	woggioni	View Question on Stackoverflow
Solution 1 - C++	Sneftel	View Answer on Stackoverflow

What does the gcc warning "project parameter passing for X changed in GCC 7.1" mean?

C++ Problem Overview

C++ Solutions

Solution 1 - C++

Firestore: Multiple conditional where clauses

Do binding redirects in app.config for class libraries do anything?

Attributions