&gt; What is the difference between the two, 

The `g++` is a compiler driver. It knows how to invoke the actual compiler (`cc1plus`), assembler and linker. It does *not* know how to parse or compile the sources.

&gt; and should I ever call cc1plus directly?

No.

I was wondering what the best approach is for configuring a module export. &quot;async.function&quot; in the example below could be a FS or HTTP request, simplified for the sake of the example:

Here&#39;s example code (asynmodule.js):

    var foo = &quot;bar&quot;
    async.function(function(response) {
      foo = &quot;foobar&quot;;
      // module.exports = foo;  // having the export here breaks the app: foo is always undefined.
    });

    // having the export here results in working code, but without the variable being set.
    module.exports = foo;

How can I export the module only once the async callback has been executed? 

*edit* 
a quick note on my actual use-case: I&#39;m writing a module to configure nconf (https://github.com/flatiron/nconf) in an fs.exists() callback (i.e. it will parse a config file and set up nconf). 

Asynchronous nodejs module exports

I am trying to use a `Handler` in my app. However, when I instantiate it like this:

    Handler handler = new Handler();

I get the following error:

&gt; Gradle: error: Handler is abstract; cannot be instantiated

And when I check the solutions, it asks me to implement these methods:

    Handler handler = new Handler() {
        @Override
        public void close() {
            
        }

        @Override
        public void flush() {

        }

        @Override
        public void publish(LogRecord record) {

        }
    };

I have never used `Handlers` before and I am using it just to call a method after some delay. To achieve that, I&#39;ve used:

    handler.postDelayed(new Runnable() {
            @Override
            public void run() {
                //Do something after 100ms
            }
        }, 100);

But it shows the error:

&gt; Gradle: error: cannot find symbol method postDelayed(&lt;anonymous Runnable&gt;,int)


Handler is abstract ,cannot be instantiated

When I compile my projects and check the resources used by running `top`, the big CPU/memory hog is sometimes called `g++` and sometimes `cc1plus`. What is the difference between the two, and should I ever call `cc1plus` directly?

What is the difference between gcc/g++ and cc1/cc1plus?

<p>When I compile my projects and check the resources used by running <code>top</code>, the big CPU/memory hog is sometimes called <code>g++</code> and sometimes <code>cc1plus</code>. What is the difference between the two, and should I ever call <code>cc1plus</code> directly?</p>


When I&#39;m compiling openvswitch-1.5.0, I&#39;ve encountered the following compile error:

    

     gcc -Wstrict-prototypes -Wall -Wno-sign-compare -Wpointer-arith
         -Wdeclaration-after-statement -Wformat-security -Wswitch-enum -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -Wno-override-init  -g -O2 -export-dynamic ***-lpthread***  -o utilities/ovs-dpctl utilities/ovs-dpctl.o lib/libopenvswitch.a
     /home/jyyoo/src/dpdk/build/lib/librte_eal.a
     /home/jyyoo/src/dpdk/build/lib/libethdev.a
     /home/jyyoo/src/dpdk/build/lib/librte_cmdline.a
     /home/jyyoo/src/dpdk/build/lib/librte_hash.a
     /home/jyyoo/src/dpdk/build/lib/librte_lpm.a
     /home/jyyoo/src/dpdk/build/lib/librte_mbuf.a
     /home/jyyoo/src/dpdk/build/lib/librte_ring.a
     /home/jyyoo/src/dpdk/build/lib/librte_mempool.a
     /home/jyyoo/src/dpdk/build/lib/librte_malloc.a -lrt -lm 
         /usr/bin/ld: /home/jyyoo/src/dpdk/build/lib/librte_eal.a(eal.o): undefined reference
         to symbol &#39;pthread_create@@GLIBC_2.2.5&#39;
         /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from 
         command line
    
If I try to see the symbols of `libpthread`, it looks fine.

    $ readelf -s /lib/x86_64-linux-gnu/libpthread.so.0 | grep pthread_create
       199: 0000000000008220  2814 FUNC    GLOBAL DEFAULT   13 pthread_create@@GLIBC_2.2.5
       173: 0000000000008220  2814 FUNC    LOCAL  DEFAULT   13 __pthread_create_2_1
       462: 0000000000008220  2814 FUNC    GLOBAL DEFAULT   13 pthread_create@@GLIBC_2.2

Could you give any hints or pointers?

libpthread.so.0: error adding symbols: DSO missing from command line

I am using OS 10.9 on mac machine. I want to know the version of gcc I am using. So I tried `gcc --version` on terminal and it results :

    $ gcc --version
    Configured with: --prefix=/Applications/Xcode5-DP.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode5-DP.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
    Apple LLVM version 5.0 (clang-500.1.58) (based on LLVM 3.3svn)
    Target: x86_64-apple-darwin13.0.0
    Thread model: posix

Here in output, there is no detail related to gcc but clang is there. I am confused 
whether gcc command executes clang or gcc(gnu).
  

how to find gcc version on mac

I&#39;m trying to understand whether the different behavior exposed by gcc vs. clang in the output of this simple C++11 program is due to a bug in clang (Xcode 5.0.2, OS X 10.8.5). The code is as follows:

    #include &lt;iostream&gt;
    
    int main() {
    
    
    	int matrix[][3]{{1,2,3}, {4,5,6}, {7,8,9}};
    	auto dyn_matrix = new int[3][3]{{1,2,3}, {4,5,6}, {7,8,9}};
    	
    	std::cout &lt;&lt; matrix[0][1] &lt;&lt; std::endl;
    	std::cout &lt;&lt; dyn_matrix[0][1] &lt;&lt; std::endl;
    	
    	return 0;	
    }

As shown, I&#39;m trying to use uniform initialization to initialize an anonymous (resp. named) multidimensional array of size `3x3`. When compiling with gcc 4.7 from MacPorts the expected output is obtained:

    $g++-mp-4.7 -std=c++11 dyn_matrix.cpp -o dyn_matrix 
    $ ./dyn_matrix
    2
    2
    $

Conversely, in case clang is used the output reads:

    $ clang++ -std=c++11 -stdlib=libc++ dyn_matrix.cpp -o dyn_matrix_clang
    $ ./dyn_matrix_clang 
    2
    4
    $  

In this case the result is (apparently) wrong. `clang --version` reports:

    Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM 3.3svn)
    Target: x86_64-apple-darwin12.5.0
    Thread model: posix

Who&#39;s to blame? me, gcc or clang?

**UPDATE Dec 11th, 2013:** The bug should have been fixed in r196995. Unfortunately, we still do not know how long it will take before Apple updates the version of clang that ships with Xcode. 

**UPDATE Dec 9th, 2013:** I submitted a bug report on the LLVM bugzilla platform. It has indeed been recognized as a bug, a patch is currently under review, see http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131209/095099.html. 

Thanks.

Different results between gcc and clang when compiling a rather simple c++11 program

I have found an interesting performance regression in a small C++ snippet, when I enable C++11:

    #include &lt;vector&gt;

    struct Item
    {
      int a;
      int b;
    };

    int main()
    {
      const std::size_t num_items = 10000000;
      std::vector&lt;Item&gt; container;
      container.reserve(num_items);
      for (std::size_t i = 0; i &lt; num_items; ++i) {
        container.push_back(Item());
      }
      return 0;
    }

With g++ (GCC) 4.8.2 20131219 (prerelease) and C++03 I get:

    milian:/tmp$ g++ -O3 main.cpp &amp;&amp; perf stat -r 10 ./a.out

    Performance counter stats for &#39;./a.out&#39; (10 runs):

            35.206824 task-clock                #    0.988 CPUs utilized            ( +-  1.23% )
                    4 context-switches          #    0.116 K/sec                    ( +-  4.38% )
                    0 cpu-migrations            #    0.006 K/sec                    ( +- 66.67% )
                  849 page-faults               #    0.024 M/sec                    ( +-  6.02% )
           95,693,808 cycles                    #    2.718 GHz                      ( +-  1.14% ) [49.72%]
      &lt;not supported&gt; stalled-cycles-frontend 
      &lt;not supported&gt; stalled-cycles-backend  
           95,282,359 instructions              #    1.00  insns per cycle          ( +-  0.65% ) [75.27%]
           30,104,021 branches                  #  855.062 M/sec                    ( +-  0.87% ) [77.46%]
                6,038 branch-misses             #    0.02% of all branches          ( +- 25.73% ) [75.53%]

          0.035648729 seconds time elapsed                                          ( +-  1.22% )

With C++11 enabled on the other hand, the performance degrades significantly:

    milian:/tmp$ g++ -std=c++11 -O3 main.cpp &amp;&amp; perf stat -r 10 ./a.out
    
    Performance counter stats for &#39;./a.out&#39; (10 runs):

            86.485313 task-clock                #    0.994 CPUs utilized            ( +-  0.50% )
                    9 context-switches          #    0.104 K/sec                    ( +-  1.66% )
                    2 cpu-migrations            #    0.017 K/sec                    ( +- 26.76% )
                  798 page-faults               #    0.009 M/sec                    ( +-  8.54% )
          237,982,690 cycles                    #    2.752 GHz                      ( +-  0.41% ) [51.32%]
      &lt;not supported&gt; stalled-cycles-frontend 
      &lt;not supported&gt; stalled-cycles-backend  
          135,730,319 instructions              #    0.57  insns per cycle          ( +-  0.32% ) [75.77%]
           30,880,156 branches                  #  357.057 M/sec                    ( +-  0.25% ) [75.76%]
                4,188 branch-misses             #    0.01% of all branches          ( +-  7.59% ) [74.08%]

        0.087016724 seconds time elapsed                                          ( +-  0.50% )

Can someone explain this? So far my experience was that the STL gets faster by enabling C++11, esp. thanks to move semantics.

**EDIT:** As suggested, using `container.emplace_back();` instead the performance gets on par with the C++03 version. How can the C++03 version achieve the same for `push_back`?

    milian:/tmp$ g++ -std=c++11 -O3 main.cpp &amp;&amp; perf stat -r 10 ./a.out

    Performance counter stats for &#39;./a.out&#39; (10 runs):

            36.229348 task-clock                #    0.988 CPUs utilized            ( +-  0.81% )
                    4 context-switches          #    0.116 K/sec                    ( +-  3.17% )
                    1 cpu-migrations            #    0.017 K/sec                    ( +- 36.85% )
                  798 page-faults               #    0.022 M/sec                    ( +-  8.54% )
           94,488,818 cycles                    #    2.608 GHz                      ( +-  1.11% ) [50.44%]
      &lt;not supported&gt; stalled-cycles-frontend 
      &lt;not supported&gt; stalled-cycles-backend  
           94,851,411 instructions              #    1.00  insns per cycle          ( +-  0.98% ) [75.22%]
           30,468,562 branches                  #  840.991 M/sec                    ( +-  1.07% ) [76.71%]
                2,723 branch-misses             #    0.01% of all branches          ( +-  9.84% ) [74.81%]

       0.036678068 seconds time elapsed                                          ( +-  0.80% )

std::vector performance regression when enabling C++11

(Preface: I&#39;m pretty new to C/C++ and I don&#39;t really know how debugging in native code actually works.)

Some sources say that gdb and lldb can debug [any program compiled to machine code](http://www.lego.com/en-us/mindstorms/products/fan-made-bonus-robots/ev3meg). Others say that to debug with gdb you **must** compile in gcc [with the `-g` flag](http://tedlab.mit.edu/~dr/gdbintro.html). The documentation for gcc itself suggests this is optional, and that in fact if you use it, it can cause problems for debuggers _other than_ gdb. Clang also has a `-g` flag and the documentation basically just says &quot;Generate debug information.&quot;

So are these debuggers restricted to their own toolchains (GNU and LLVM), or are they somehow independent of the compiler used?

Is it possible to debug a gcc-compiled program using lldb, or debug a clang-compiled program using gdb?

The following test program

    #include &lt;map&gt;
    #include &lt;iostream&gt;

    using namespace std;

    int main(int argc, char **argv)
    {
        map&lt;int,int&gt; a;
        a[1]=a.size();
        for(map&lt;int,int&gt;::const_iterator it=a.begin(); it!=a.end(); ++it)
                cout &lt;&lt; &quot;first &quot; &lt;&lt; (*it).first &lt;&lt; &quot; second &quot; &lt;&lt; (*it).second &lt;&lt; endl;
    }

leads to different output when compiled on `g++ 4.8.1` (Ubuntu 12.04 LTS):

    g++ xxx.cpp 
    ./a.out 
    first 1 second 1

and on Visual Studio 2012 (Windows 7) (Standard Win32 Console Application Project):

    ConsoleApplication1.exe
    first 1 second 0

Which compiler is right? Am I doing something wrong?


Strange std::map behaviour

The following code compiles successfully with g++ 4.8.1:

    int main()
    {
        int(*)();
    }

It looks like a simple declaration of a pointer to function:

    int(*f)();

It doesn&#39;t compile with clang 3.4 and vc++ 2013.

Is it a compiler bug or one of dark places of the standard?

---

### List of similar strange code pieces which compile fine with g++ 4.8.1 (updated): ###

1. `int(*)();`

2. `int(*);`

3. `int(*){};`

4. `int(*());`

[Live example with these strange code pieces](http://ideone.com/yGG2yZ).

**Update 1:** [**@Ali**](https://stackoverflow.com/users/341970/ali) added some interesting information in the comments:

&gt; All 4 cases give a compile error with clang 3.5 trunk (202594) and compile fine with gcc 4.9 trunk (20140302). The behavior is the same with `-std=c++98 -pedantic`, except for `int(*){};` which is understandable; extended initializer lists only available with `-std=c++11`.

**Update 2:** As [**@CantChooseUsernames**](https://stackoverflow.com/users/1462718/cantchooseusernames) noted in [his answer](https://stackoverflow.com/questions/23015482/strange-code-that-compiles-with-g/23019886#23019886) they still compile fine even with initialization and no assembly is generated for them by g++ (neither with nor without initialization) even without any enabled optimization:

1. `int(*)() = 0;`

2. `int(*) = 0;`

3. `int(*){} = 0;`

4. `int(*()) = 0;`

[Live example with initializations](http://ideone.com/5Ugc92).

**Update 3:** I was really surprised to find that `int(*)() = &quot;Hello, world!&quot;;` compiles fine, too (while `int(*p)() = &quot;Hello, world!&quot;;` doesn&#39;t compile, of course).

**Update 4:** It is fantastic but `int(*){} = Hello, world!;` compiles fine. And the following extremely strange piece of code, too: `int(*){}() = -+*/%&amp;|^~.,:!?$()[]{};` ([live example](http://ideone.com/JvqcVL)).

**Update 5:** As [**@zwol**](https://stackoverflow.com/users/388520/zwol) noted in [his comment](https://stackoverflow.com/questions/23015482/strange-code-that-compiles-with-g?lq=1#comment55044024_23015482)

&gt; This and a number of related syntactic problems are being tracked as gcc [bug 68265](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68265).

Strange code that compiles with g++

I am trying to compile a C++ program like this:

    $ g++ -o Sniffer_Train main.cpp Sniffer_train.cpp Sniffer_train.h -lmysqlclient -lpcap

However I get the following error:

    /usr/bin/ld: /tmp/cct6xeXD.o: undefined reference to symbol
    &#39;pthread_join@@GLIBC_2.4&#39; //lib/arm-linux-gnueabihf/libpthread.so.0:
    error adding symbols: DSO missing from command line
     
    collect2: error: ld returned 1 exit status

I have no idea what this error means. Any help will be greatly appreciated.


DSO missing from command line

I have read from a [codeforces][1] blog that if we add `#include &lt;bits/stdc++.h&gt;` in a `C++` program then there is no need to include any other header files. How does `#include &lt;bits/stdc++.h&gt;` work and is it ok to use it instead of including individual header files?

  [1]: https://codeforces.com

How does #include &lt;bits/stdc++.h&gt; work in C++?

In the MinGW-W64 online installer there are several fields you can select.  However I cannot find any documentation on this, and the guesses I&#39;ve made don&#39;t give me the behaviour I want.

Clearly a lot of work has gone into this project so it seems a pity that uptake is being held back by lack of basic documentation. 

The &quot;Version&quot; and &quot;Architecture&quot; fields are self-explanatory but the other fields I have trouble with are (values shown as of current installer):

  * **Threads**, options `posix` and `win32`
  * **Exception**, options `dwarf` and `sjlj`
  * **Build revision**, options `0`, `1`, `2`.

The values I chose on my previous install were `win32`, `seh` and `1` (clearly the options have changed since then but I am none the wiser as to what&#39;s what).

What are the pros and cons of each option, especially the threading model and exception handling, and which version is &quot;best&quot;?

The specific problems I have encountered using `x86_64-win32-seh-rev1` are:

  * `std::thread` and `std::condition_variable` are not supported
  * When debugging (using Code::Blocks as IDE), if an exception is thrown it does not jump to the exception handler; selecting Next Line does nothing 3 times and then aborts the run.

I can cope with the debugging problem but it would be really nice to have working C++11 threads.


Content Type	Original Author	Original Content on Stackoverflow
Question	Michael Schlottke-Lakemper	View Question on Stackoverflow
Solution 1 - Gcc	Employed Russian	View Answer on Stackoverflow

What is the difference between gcc/g++ and cc1/cc1plus?

Gcc Problem Overview

Gcc Solutions

Solution 1 - Gcc

Handler is abstract ,cannot be instantiated

Asynchronous nodejs module exports

Attributions