In newer version, you can surround a section of code with:

    // clang-format off
    ...
    // clang-format on

Try adding a `//` comment marker after each line, this may do it. I had the same issue in Eclipse and learned this trick.

    sql_create_6(stock, 1, 6, //
        mysqlpp::sql_char, item, //
        mysqlpp::sql_bigint, num, //
        mysqlpp::sql_double, weight, //
        mysqlpp::sql_decimal, price, //
        mysqlpp::sql_date, sdate, //
        mysqlpp::Null&lt;mysqlpp::sql_mediumtext&gt;, description)

When I try to start :

    WebApp.Start&lt;SrvcHst&gt;(new StartOptions { Port = 9956, 
         ServerFactory = &quot;Microsoft.Owin.Host.HttpListener&quot; });

I get the following exception. What could be the root cause?


    System.MissingMemberException was caught
      HResult=-2146233070
      Message=The server factory could not be located for the given input: Microsoft.Owin.Host.HttpListener
      Source=Microsoft.Owin.Hosting
      StackTrace:
           at Microsoft.Owin.Hosting.Engine.HostingEngine.ResolveServerFactory(StartContext context)
           at Microsoft.Owin.Hosting.Engine.HostingEngine.Start(StartContext context)
           at Microsoft.Owin.Hosting.Starter.DirectHostingStarter.Start(StartOptions options)
           at Microsoft.Owin.Hosting.Starter.HostingStarter.Start(StartOptions options)
           at Microsoft.Owin.Hosting.WebApp.StartImplementation(IServiceProvider services, StartOptions options)
           at Microsoft.Owin.Hosting.WebApp.Start(StartOptions options)
           at Microsoft.Owin.Hosting.WebApp.Start[TStartup](StartOptions options)

OWIN HttpListener not located

Is there a method of ending single line comments in Python?

Something like

```lang-none
/* This is my comment */ some more code here...
```


How to write an inline-comment in Python

For example, in the MySQL++ library there are macros that can be used to define simple structs based on sql table definition, like this:

    sql_create_6(stock, 1, 6,
        mysqlpp::sql_char, item,
        mysqlpp::sql_bigint, num,
        mysqlpp::sql_double, weight,
        mysqlpp::sql_decimal, price,
        mysqlpp::sql_date, sdate,
        mysqlpp::Null&lt;mysqlpp::sql_mediumtext&gt;, description)

The problem is that clang-format will reformat this in a way that is much more difficult to read (every param on a new line).
Most code formatters can recognize special format-off / format-on comments, but I haven&#39;t found anything like that in the clang-format manual.

How to mark a region so clang-format won&#39;t touch it?

For example, in the MySQL++ library there are macros that can be used to define simple structs based on sql table definition, like this:
<pre><code class="hljs language-less">sql_create_6(stock, 1, 6,
 mysqlpp::sql_char, item,
 mysqlpp::sql_bigint, num,
 mysqlpp::sql_double, weight,
 mysqlpp::sql_decimal, price,
 mysqlpp::sql_date, sdate,
 mysqlpp::Null&#x3C;mysqlpp::sql_mediumtext>, description)
</code></pre>
The problem is that clang-format will reformat this in a way that is much more difficult to read (every param on a new line).
Most code formatters can recognize special format-off / format-on comments, but I haven't found anything like that in the clang-format manual.

I am learning C++ and I&#39;ve just started learning about some of [Qt][1]&#39;s capabilities to code GUI programs. I asked myself the following question:

How does C++, which previously had no syntax capable of asking the OS for a window or a way to communicate through networks (with APIs which I don&#39;t completely understand either, I admit) suddenly get such capabilities **through libraries written in C++ themselves?** It all seems terribly circular to me. What C++ instructions could you possibly come up with in those libraries?

I realize this question might seem trivial to an experienced software developer but I&#39;ve been researching for hours without finding any direct response. It&#39;s gotten to the point where I can&#39;t follow the tutorial about Qt because the existence of libraries is incomprehensible to me.


  [1]: https://en.wikipedia.org/wiki/Qt_(software)

How does a language expand itself?

I went through this [page][1] but I am not able to get the reason for the same . There it is mentioned that 

&gt; &quot;it is more sensible for it to return no value at all and to require
&gt; clients to use front() to inspect the value at the front of the queue&quot;

 
But inspecting an element from front() also required that element to be copied in lvalue. For example in this code segment

    std::queue&lt;int&gt; myqueue;
	int myint;
    int result;
	std::cin &gt;&gt; myint;
    myqueue.push (myint);
/* here temporary will be created on RHS which will be assigned to result, and in case
 if returns by reference then result will be rendered invalid after pop operation */

    result = myqueue.front();  //result.
    std::cout &lt;&lt; &#39; &#39; &lt;&lt; result;
    myqueue.pop();

on fifth line *cout* object first creates a copy of myqueue.front() then assigns that to result. So, whats the difference, pop function could have done the same thing.


  [1]: http://www.sgi.com/tech/stl/queue.html#3

Why doesn&#39;t std::queue::pop return value.?

I was looking for the fastest way to `popcount` large arrays of data. I encountered a *very weird* effect: Changing the loop variable from `unsigned` to `uint64_t` made the performance drop by 50% on my PC.

The Benchmark
-------------

    #include &lt;iostream&gt;
    #include &lt;chrono&gt;
    #include &lt;x86intrin.h&gt;

    int main(int argc, char* argv[]) {

        using namespace std;
        if (argc != 2) {
           cerr &lt;&lt; &quot;usage: array_size in MB&quot; &lt;&lt; endl;
           return -1;
        }

        uint64_t size = atol(argv[1])&lt;&lt;20;
        uint64_t* buffer = new uint64_t[size/8];
        char* charbuffer = reinterpret_cast&lt;char*&gt;(buffer);
        for (unsigned i=0; i&lt;size; ++i)
            charbuffer[i] = rand()%256;

        uint64_t count,duration;
        chrono::time_point&lt;chrono::system_clock&gt; startP,endP;
        {
            startP = chrono::system_clock::now();
            count = 0;
            for( unsigned k = 0; k &lt; 10000; k++){
                // Tight unrolled loop with unsigned
                for (unsigned i=0; i&lt;size/8; i+=4) {
                    count += _mm_popcnt_u64(buffer[i]);
                    count += _mm_popcnt_u64(buffer[i+1]);
                    count += _mm_popcnt_u64(buffer[i+2]);
                    count += _mm_popcnt_u64(buffer[i+3]);
                }
            }
            endP = chrono::system_clock::now();
            duration = chrono::duration_cast&lt;std::chrono::nanoseconds&gt;(endP-startP).count();
            cout &lt;&lt; &quot;unsigned\t&quot; &lt;&lt; count &lt;&lt; &#39;\t&#39; &lt;&lt; (duration/1.0E9) &lt;&lt; &quot; sec \t&quot;
                 &lt;&lt; (10000.0*size)/(duration) &lt;&lt; &quot; GB/s&quot; &lt;&lt; endl;
        }
        {
            startP = chrono::system_clock::now();
            count=0;
            for( unsigned k = 0; k &lt; 10000; k++){
                // Tight unrolled loop with uint64_t
                for (uint64_t i=0;i&lt;size/8;i+=4) {
                    count += _mm_popcnt_u64(buffer[i]);
                    count += _mm_popcnt_u64(buffer[i+1]);
                    count += _mm_popcnt_u64(buffer[i+2]);
                    count += _mm_popcnt_u64(buffer[i+3]);
                }
            }
            endP = chrono::system_clock::now();
            duration = chrono::duration_cast&lt;std::chrono::nanoseconds&gt;(endP-startP).count();
            cout &lt;&lt; &quot;uint64_t\t&quot;  &lt;&lt; count &lt;&lt; &#39;\t&#39; &lt;&lt; (duration/1.0E9) &lt;&lt; &quot; sec \t&quot;
                 &lt;&lt; (10000.0*size)/(duration) &lt;&lt; &quot; GB/s&quot; &lt;&lt; endl;
        }

        free(charbuffer);
    }


As you see, we create a buffer of random data, with the size being `x` megabytes where `x` is read from the command line. Afterwards, we iterate over the buffer and use an unrolled version of the x86 `popcount` intrinsic to perform the popcount. To get a more precise result, we do the popcount 10,000 times. We measure the times for the popcount. In the upper case, the inner loop variable is `unsigned`, in the lower case, the inner loop variable is `uint64_t`. I thought that this should make no difference, but the opposite is the case.

The (absolutely crazy) results
------------------------------

I compile it like this (g++ version: Ubuntu 4.8.2-19ubuntu1):

    g++ -O3 -march=native -std=c++11 test.cpp -o test

Here are the results on my [Haswell][1] [Core i7-4770K][2] CPU @ 3.50&amp;nbsp;GHz, running `test 1` (so 1&amp;nbsp;MB random data):

* unsigned  41959360000  0.401554 sec   **26.113&amp;nbsp;GB/s**
* uint64_t  41959360000  0.759822 sec   **13.8003&amp;nbsp;GB/s**

As you see, the throughput of the `uint64_t` version is **only half** the one of the `unsigned` version! The problem seems to be that different assembly gets generated, but why? First, I thought of a compiler bug, so I tried `clang++` (Ubuntu [Clang][3] version 3.4-1ubuntu3):

    clang++ -O3 -march=native -std=c++11 teest.cpp -o test

Result: `test 1`

* unsigned  41959360000  0.398293 sec   **26.3267 GB/s**
* uint64_t  41959360000  0.680954 sec   **15.3986 GB/s**

So, it is almost the same result and is still strange. *But now it gets super strange.* I replace the buffer size that was read from input with a constant `1`, so I change:

    uint64_t size = atol(argv[1]) &lt;&lt; 20;

to

    uint64_t size = 1 &lt;&lt; 20;

Thus, the compiler now knows the buffer size at compile time. Maybe it can add some optimizations! Here are the numbers for `g++`:

* unsigned  41959360000  0.509156 sec   **20.5944&amp;nbsp;GB/s**
* uint64_t  41959360000  0.508673 sec   **20.6139&amp;nbsp;GB/s**

Now, both versions are equally fast. However, the `unsigned` **got even slower**! It dropped from `26` to `20 GB/s`, thus replacing a non-constant by a constant value lead to a **deoptimization**. Seriously, I have no clue what is going on here! But now to `clang++` with the new version:

* unsigned  41959360000  0.677009 sec   **15.4884&amp;nbsp;GB/s**
* uint64_t  41959360000  0.676909 sec   **15.4906&amp;nbsp;GB/s**

*Wait, what?* Now, both versions dropped to the **slow** number of 15&amp;nbsp;GB/s. Thus, replacing a non-constant by a constant value even lead to slow code in **both** cases for Clang!

I asked a colleague with an [Ivy Bridge][4] CPU to compile my benchmark. He got similar results, so it does not seem to be Haswell. Because two compilers produce strange results here, it also does not seem to be a compiler bug. We do not have an AMD CPU here, so we could only test with Intel.

More madness, please!
--------------------

Take the first example (the one with `atol(argv[1])`) and put a `static` before the variable, i.e.:

    static uint64_t size=atol(argv[1])&lt;&lt;20;

Here are my results in g++:

* unsigned  41959360000  0.396728 sec   **26.4306 GB/s**
* uint64_t  41959360000  0.509484 sec   **20.5811 GB/s**

*Yay, yet another alternative*. We still have the fast 26&amp;nbsp;GB/s with `u32`, but we managed to get `u64` at least from the 13&amp;nbsp;GB/s to the 20&amp;nbsp;GB/s version! **On my collegue&#39;s PC, the `u64` version became even faster than the `u32` version, yielding the fastest result of all.** Sadly, this only works for `g++`, `clang++` does not seem to care about `static`.

My question
-----------

Can you explain these results? Especially:

* How can there be such a difference between `u32` and `u64`?
* How can replacing a non-constant by a constant buffer size trigger *less optimal code*?
* How can the insertion of the `static` keyword make the `u64` loop faster? Even faster than the original code on my collegue&#39;s computer!

I know that optimization is a tricky territory, however, I never thought that such small changes can lead to a **100% difference** in execution time and that small factors like a constant buffer size can again mix results totally. Of course, I always want to have the version that is able to popcount 26&amp;nbsp;GB/s. The only reliable way I can think of is copy paste the assembly for this case and use inline assembly. This is the only way I can get rid of compilers that seem to go mad on small changes. What do you think? Is there another way to reliably get the code with most performance?

The Disassembly
---------------

Here is the disassembly for the various results:

26&amp;nbsp;GB/s version from **g++ / u32 / non-const bufsize**:

    0x400af8:
    lea 0x1(%rdx),%eax
    popcnt (%rbx,%rax,8),%r9
    lea 0x2(%rdx),%edi
    popcnt (%rbx,%rcx,8),%rax
    lea 0x3(%rdx),%esi
    add %r9,%rax
    popcnt (%rbx,%rdi,8),%rcx
    add $0x4,%edx
    add %rcx,%rax
    popcnt (%rbx,%rsi,8),%rcx
    add %rcx,%rax
    mov %edx,%ecx
    add %rax,%r14
    cmp %rbp,%rcx
    jb 0x400af8

13&amp;nbsp;GB/s version from **g++ / u64 / non-const bufsize**:

    0x400c00:
    popcnt 0x8(%rbx,%rdx,8),%rcx
    popcnt (%rbx,%rdx,8),%rax
    add %rcx,%rax
    popcnt 0x10(%rbx,%rdx,8),%rcx
    add %rcx,%rax
    popcnt 0x18(%rbx,%rdx,8),%rcx
    add $0x4,%rdx
    add %rcx,%rax
    add %rax,%r12
    cmp %rbp,%rdx
    jb 0x400c00

15&amp;nbsp;GB/s version from **clang++ / u64 / non-const bufsize**:

    0x400e50:
    popcnt (%r15,%rcx,8),%rdx
    add %rbx,%rdx
    popcnt 0x8(%r15,%rcx,8),%rsi
    add %rdx,%rsi
    popcnt 0x10(%r15,%rcx,8),%rdx
    add %rsi,%rdx
    popcnt 0x18(%r15,%rcx,8),%rbx
    add %rdx,%rbx
    add $0x4,%rcx
    cmp %rbp,%rcx
    jb 0x400e50

20&amp;nbsp;GB/s version from **g++ / u32&amp;u64 / const bufsize**:

    0x400a68:
    popcnt (%rbx,%rdx,1),%rax
    popcnt 0x8(%rbx,%rdx,1),%rcx
    add %rax,%rcx
    popcnt 0x10(%rbx,%rdx,1),%rax
    add %rax,%rcx
    popcnt 0x18(%rbx,%rdx,1),%rsi
    add $0x20,%rdx
    add %rsi,%rcx
    add %rcx,%rbp
    cmp $0x100000,%rdx
    jne 0x400a68

15&amp;nbsp;GB/s version from **clang++ / u32&amp;u64 / const bufsize**:

    0x400dd0:
    popcnt (%r14,%rcx,8),%rdx
    add %rbx,%rdx
    popcnt 0x8(%r14,%rcx,8),%rsi
    add %rdx,%rsi
    popcnt 0x10(%r14,%rcx,8),%rdx
    add %rsi,%rdx
    popcnt 0x18(%r14,%rcx,8),%rbx
    add %rdx,%rbx
    add $0x4,%rcx
    cmp $0x20000,%rcx
    jb 0x400dd0

Interestingly, the fastest (26&amp;nbsp;GB/s) version is also the longest! It seems to be the only solution that uses `lea`. Some versions use `jb` to jump, others use `jne`. But apart from that, all versions seem to be comparable. I don&#39;t see where a 100% performance gap could originate from, but I am not too adept at deciphering assembly. The slowest (13&amp;nbsp;GB/s) version looks even very short and good. Can anyone explain this?

Lessons learned
---------------

No matter what the answer to this question will be; I have learned that in really hot loops *every* detail can matter, *even details that do not seem to have any association to the hot code*. I have never thought about what type to use for a loop variable, but as you see such a minor change can make a *100%* difference! Even the storage type of a buffer can make a huge difference, as we saw with the insertion of the `static` keyword in front of the size variable! In the future, I will always test various alternatives on various compilers when writing really tight and hot loops that are crucial for system performance.

The interesting thing is also that the performance difference is still so high although I have already unrolled the loop four times. So even if you unroll, you can still get hit by major performance deviations. Quite interesting.

  [1]: http://en.wikipedia.org/wiki/Haswell_%28microarchitecture%29
  [2]: http://en.wikipedia.org/wiki/Haswell_%28microarchitecture%29#Desktop_processors
  [3]: http://en.wikipedia.org/wiki/Clang
  [4]: http://en.wikipedia.org/wiki/Ivy_Bridge_%28microarchitecture%29


Replacing a 32-bit loop counter with 64-bit introduces crazy performance deviations with _mm_popcnt_u64 on Intel CPUs

I am using the GCC built-in type `__int128` for a few things in my C++ program, nothing really significant, at least not enough to justify to use BigInt library only for that and, yet, enough to prevent to remove it totally.

My problem comes when I run into the printing parts my classes, here is a minimal example:

    #include &lt;iostream&gt;

    int main()
    {
      __int128 t = 1234567890;

      std::cout &lt;&lt; t &lt;&lt; std::endl;

      return t;
    }

Commenting out the `std::cout` line will make this code to compile nicely with `g++`, but having it will cause the following error message:

    int128.c: In function ‘int main()’:
    int128.c:7:13: error: ambiguous overload for ‘operator&lt;&lt;’ (operand types are ‘std::ostream {aka std::basic_ostream&lt;char&gt;}’ and ‘__int128’)
       std::cout &lt;&lt; t &lt;&lt; std::endl;
                 ^
    int128.c:7:13: note: candidates are:
    In file included from /usr/include/c++/4.9/iostream:39:0,
                     from int128.c:1:
    /usr/include/c++/4.9/ostream:108:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; (*)(std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp;)) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;] &lt;near match&gt;
           operator&lt;&lt;(__ostream_type&amp; (*__pf)(__ostream_type&amp;))
           ^
    /usr/include/c++/4.9/ostream:108:7: note:   no known conversion for argument 1 from ‘__int128’ to ‘std::basic_ostream&lt;char&gt;::__ostream_type&amp; (*)(std::basic_ostream&lt;char&gt;::__ostream_type&amp;) {aka std::basic_ostream&lt;char&gt;&amp; (*)(std::basic_ostream&lt;char&gt;&amp;)}’
    /usr/include/c++/4.9/ostream:117:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(std::basic_ostream&lt;_CharT, _Traits&gt;::__ios_type&amp; (*)(std::basic_ostream&lt;_CharT, _Traits&gt;::__ios_type&amp;)) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ios_type = std::basic_ios&lt;char&gt;] &lt;near match&gt;
           operator&lt;&lt;(__ios_type&amp; (*__pf)(__ios_type&amp;))
           ^
    /usr/include/c++/4.9/ostream:117:7: note:   no known conversion for argument 1 from ‘__int128’ to ‘std::basic_ostream&lt;char&gt;::__ios_type&amp; (*)(std::basic_ostream&lt;char&gt;::__ios_type&amp;) {aka std::basic_ios&lt;char&gt;&amp; (*)(std::basic_ios&lt;char&gt;&amp;)}’
    /usr/include/c++/4.9/ostream:127:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(std::ios_base&amp; (*)(std::ios_base&amp;)) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;] &lt;near match&gt;
           operator&lt;&lt;(ios_base&amp; (*__pf) (ios_base&amp;))
           ^
    /usr/include/c++/4.9/ostream:127:7: note:   no known conversion for argument 1 from ‘__int128’ to ‘std::ios_base&amp; (*)(std::ios_base&amp;)’
    /usr/include/c++/4.9/ostream:166:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(long int) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;]
           operator&lt;&lt;(long __n)
           ^
    /usr/include/c++/4.9/ostream:170:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(long unsigned int) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;]
           operator&lt;&lt;(unsigned long __n)
           ^
    /usr/include/c++/4.9/ostream:174:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(bool) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;]
           operator&lt;&lt;(bool __n)
           ^
    In file included from /usr/include/c++/4.9/ostream:609:0,
                     from /usr/include/c++/4.9/iostream:39,
                     from int128.c:1:
    /usr/include/c++/4.9/bits/ostream.tcc:91:5: note: std::basic_ostream&lt;_CharT, _Traits&gt;&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(short int) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;]
         basic_ostream&lt;_CharT, _Traits&gt;::
         ^
    In file included from /usr/include/c++/4.9/iostream:39:0,
                     from int128.c:1:
    /usr/include/c++/4.9/ostream:181:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(short unsigned int) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;]
           operator&lt;&lt;(unsigned short __n)
           ^
    In file included from /usr/include/c++/4.9/ostream:609:0,
                     from /usr/include/c++/4.9/iostream:39,
                     from int128.c:1:
    /usr/include/c++/4.9/bits/ostream.tcc:105:5: note: std::basic_ostream&lt;_CharT, _Traits&gt;&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(int) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;]
         basic_ostream&lt;_CharT, _Traits&gt;::
         ^
    In file included from /usr/include/c++/4.9/iostream:39:0,
                     from int128.c:1:
    /usr/include/c++/4.9/ostream:192:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(unsigned int) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;]
           operator&lt;&lt;(unsigned int __n)
           ^
    /usr/include/c++/4.9/ostream:201:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(long long int) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;]
           operator&lt;&lt;(long long __n)
           ^
    /usr/include/c++/4.9/ostream:205:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(long long unsigned int) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;]
           operator&lt;&lt;(unsigned long long __n)
           ^
    /usr/include/c++/4.9/ostream:220:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(double) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;]
           operator&lt;&lt;(double __f)
           ^
    /usr/include/c++/4.9/ostream:224:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(float) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;]
           operator&lt;&lt;(float __f)
           ^
    /usr/include/c++/4.9/ostream:232:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(long double) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;]
           operator&lt;&lt;(long double __f)
           ^
    /usr/include/c++/4.9/ostream:245:7: note: std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(const void*) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__ostream_type = std::basic_ostream&lt;char&gt;] &lt;near match&gt;
           operator&lt;&lt;(const void* __p)
           ^
    /usr/include/c++/4.9/ostream:245:7: note:   no known conversion for argument 1 from ‘__int128’ to ‘const void*’
    In file included from /usr/include/c++/4.9/ostream:609:0,
                     from /usr/include/c++/4.9/iostream:39,
                     from int128.c:1:
    /usr/include/c++/4.9/bits/ostream.tcc:119:5: note: std::basic_ostream&lt;_CharT, _Traits&gt;&amp; std::basic_ostream&lt;_CharT, _Traits&gt;::operator&lt;&lt;(std::basic_ostream&lt;_CharT, _Traits&gt;::__streambuf_type*) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; std::basic_ostream&lt;_CharT, _Traits&gt;::__streambuf_type = std::basic_streambuf&lt;char&gt;] &lt;near match&gt;
         basic_ostream&lt;_CharT, _Traits&gt;::
         ^
    /usr/include/c++/4.9/bits/ostream.tcc:119:5: note:   no known conversion for argument 1 from ‘__int128’ to ‘std::basic_ostream&lt;char&gt;::__streambuf_type* {aka std::basic_streambuf&lt;char&gt;*}’
    In file included from /usr/include/c++/4.9/iostream:39:0,
                     from int128.c:1:
    /usr/include/c++/4.9/ostream:493:5: note: std::basic_ostream&lt;char, _Traits&gt;&amp; std::operator&lt;&lt;(std::basic_ostream&lt;char, _Traits&gt;&amp;, unsigned char) [with _Traits = std::char_traits&lt;char&gt;]
         operator&lt;&lt;(basic_ostream&lt;char, _Traits&gt;&amp; __out, unsigned char __c)
         ^
    /usr/include/c++/4.9/ostream:488:5: note: std::basic_ostream&lt;char, _Traits&gt;&amp; std::operator&lt;&lt;(std::basic_ostream&lt;char, _Traits&gt;&amp;, signed char) [with _Traits = std::char_traits&lt;char&gt;]
         operator&lt;&lt;(basic_ostream&lt;char, _Traits&gt;&amp; __out, signed char __c)
         ^
    /usr/include/c++/4.9/ostream:482:5: note: std::basic_ostream&lt;char, _Traits&gt;&amp; std::operator&lt;&lt;(std::basic_ostream&lt;char, _Traits&gt;&amp;, char) [with _Traits = std::char_traits&lt;char&gt;]
         operator&lt;&lt;(basic_ostream&lt;char, _Traits&gt;&amp; __out, char __c)
         ^
    /usr/include/c++/4.9/ostream:476:5: note: std::basic_ostream&lt;_CharT, _Traits&gt;&amp; std::operator&lt;&lt;(std::basic_ostream&lt;_CharT, _Traits&gt;&amp;, char) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;]
         operator&lt;&lt;(basic_ostream&lt;_CharT, _Traits&gt;&amp; __out, char __c)
         ^

Yes, I know, a lot of lines to explain that `__int128` is just not properly handled...

Is there a **simple** way to get `__int128` to be printed by the `iostream` as any other numeric types ?

EDIT: For those who are still confusing C and C++, yes, I read the question: [how to print __uint128_t number using gcc?](https://stackoverflow.com/questions/11656241/how-to-print-uint128-t-number-using-gcc) But, this was for C and not for C++ as I am asking now.

How to print __int128 in g++?

I have a question on how pointers to a custom object are handled when used as Keys in an map. More specifically if I define 

    std::map&lt; CustomClass*, int &gt; foo;

Would the default C++ implementation work to handle these pointers? Or do I need to define a custom comparator function to handle it? In general, is it good practice to use pointers to objects as keys?

Pointers as keys in map C++ STL

Is there an option for clang-format to add braces to all if()/do/while statements etc?

eg

    if( i == 42 )
       std::cout &lt;&lt; &quot;You found the meaning of life\n&quot;;
    else
       std::cout &lt;&lt; &quot;Wrong!\n&quot;;

to

    if( i == 42 )
    {
       std::cout &lt;&lt; &quot;You found the meaning of life\n&quot;;
    }
    else
    {
       std::cout &lt;&lt; &quot;Wrong!\n&quot;;
    }

Using

    $ clang-format --version
    clang-format version 3.6.0



Can clang format add braces to single line if statements etc

The [clang-format sytle options documentation][1] includes a number of options called PenaltyXXX. The documentation doesn&#39;t explain how these penalties should be used. Can you describe how to use these penalty values and what effect they achieve (perhaps with an example)?


  [1]: http://clang.llvm.org/docs/ClangFormatStyleOptions.html

In clang-format, what do the penalties do?

Is there a way to call something like `clang-format --style=Webkit` for an entire cpp project folder, rather than running it separately for each file?

I am using `clang-format.py` and `vim` to do this, but I assume there is a way to apply this once.


How to call clang-format over a cpp project folder?

I&#39;m looking for a `clang-format` setting to prevent the tool from removing line breaks.

For example, I have my `ColumnLimit` set to 120, and here&#39;s what happens when I reformat some sample code.

Before:

    #include &lt;vector&gt;
    #include &lt;string&gt;
    
    std::vector&lt;std::string&gt; get_vec()
    {
       return std::vector&lt;std::string&gt; {
          &quot;this is a test&quot;,
          &quot;some of the lines are longer&quot;,
          &quot;than other, but I would like&quot;,
          &quot;to keep them on separate lines&quot;
       };
    }
    
    int main()
    {
       auto vec = get_vec();
    }

After:

    #include &lt;vector&gt;
    #include &lt;string&gt;
    
    std::vector&lt;std::string&gt; get_vec()
    {
       return std::vector&lt;std::string&gt;{&quot;this is a test&quot;, &quot;some of the lines are longer&quot;, &quot;than other, but I would like&quot;,
             &quot;to keep them on separate lines&quot;};
    }
    
    int main()
    {
       auto vec = get_vec();
    }


What I would like is that the tool breaks lines that are over 120 characters, but doesn&#39;t decide to combine lines just because they are less than 120 characters.

Is there such an option?  Nothing in the docs stood out to me.



Clang-format line breaks

Searching through the [Clang-Format Style Options](https://clang.llvm.org/docs/ClangFormatStyleOptions.html), I can&#39;t seem to find a way to control the behavior on the placement of C++ attributes.

As an example, take these two declarations, the first of which does not overflow the column limit and the second of which does:

    template &lt;typename TChar&gt;
    [[gnu::always_inline]]
    static ptr&lt;TChar&gt; within_limit(ptr&lt;TChar&gt; first, ptr&lt;TChar&gt; last);

    template &lt;typename TChar, typename FApply, typename... FApplyRest&gt;
    [[gnu::always_inline]]
    static ptr&lt;TChar&gt; overflow(ptr&lt;TChar&gt; first, ptr&lt;TChar&gt; last, const FApply&amp; apply, const FApplyRest&amp;... apply_rest);

No matter how I tweak my `.clang-format`, the output is some variant of this:

    [[gnu::always_inline]] static ptr&lt;TChar&gt; within_limit(ptr&lt;TChar&gt; first, ptr&lt;TChar&gt; last);

    [[gnu::always_inline]] static ptr&lt;TChar&gt;
    overflow(ptr&lt;TChar&gt; first, ptr&lt;TChar&gt; last, const FApply&amp; apply, const FApplyRest&amp;... apply_rest);

Having the attributes on the same line as the type is rather unreadable (to me), so I would prefer `clang-format` not do this. Using `__attribute__((always_inline))` exhibits the same behavior. Specifying multiple attributes in a single list (``[[noreturn, gnu::cold]]``) causes reformatting (to `[[ noreturn, gnu::cold ]]` for reasons unclear to me). The formatter has at least some basic understanding of attributes.

**SO:** Is there a way to get `clang-format` to put attributes on their own line (the C++ equivalent to `BreakAfterJavaFieldAnnotations`)?

---

__Attempted Workarounds__

Use of `// clang-format off`/`// clang-format on` is an _okay_ stopgap, but it is definitely too ham-handed for a permanent solution. I still want the declaration formatted properly. Aside from that, the project requires the use of a lot of attributes, so having `clang-format` comments everywhere is arguably less readable.

Use of `CommentPragmas` theoretically would allow me to be more localized in disabling, but the output is still quite odd:

    template &lt;typename TChar&gt;
    [[gnu::always_inline]] // NO-FORMAT: Attribute
        static ptr&lt;TChar&gt;
        within_limit(ptr&lt;TChar&gt; first, ptr&lt;TChar&gt; last);

Content Type	Original Author	Original Content on Stackoverflow
Question	Alex	View Question on Stackoverflow
Solution 1 - C++	djasper	View Answer on Stackoverflow
Solution 2 - C++	vsoftco	View Answer on Stackoverflow

How to mark a region so clang-format won't touch it?

C++ Problem Overview

C++ Solutions

Solution 1 - C++

Solution 2 - C++

How to write an inline-comment in Python

OWIN HttpListener not located

Attributions