`const void` is a type which you can form a pointer to. It&#39;s similar to a normal void pointer, but conversions work differently. For example, a `const int*` cannot be implicitly converted to a `void*`, but it can be implicitly converted to a `const void*`. Likewise, if you have a `const void*` you cannot `static_cast` it to an `int*`, but you can `static_cast` it to a `const int*`.

    const int i = 10;
    void* vp = &amp;i;                           // error
    const void* cvp = &amp;i;                    // ok
    auto ip = static_cast&lt;int*&gt;(cvp);        // error
    auto cip = static_cast&lt;const int*&gt;(cvp); // ok



As `void`, `const void` is a void type. However, if `const void` is a *return* type, the `const` is meaningless (albeit legal!), because [\[expr\]/6][1]:

&gt; If a prvalue initially has the type “*cv* `T`”, where `T` is a cv-unqualified non-class, non-array type, the type of
the expression is adjusted to `T` prior to any further analysis.

However, it is a valid type itself and occurs in e.g. [C-standard library functions][2], where it&#39;s used to ensure const-correctness of argument pointers: `int const*` cannot be converted to `void*`, but `void const*`. 


  [1]: http://eel.is/c++draft/expr#6
  [2]: http://en.cppreference.com/w/cpp/string/byte/memcpy

Types can be the result of templates; a template might state `const T`, and be instantiated with `T` as `void`.

The linked answer is misled, or rather, limited in view in that it regards the special case of a non-template type, and even then `const void` might be *meaningless*, but it is *valid code*.

I am working on facebook messenger.

Facebook app only accept one url for webhook but **ngrock** is generating new URL every time. Now I am unable to test my app because of webhook URL changed.

How to generate fixed url with ngrok

How can somebody configure `react-native run-ios` to execute in iTerm instead of Terminal on OSX?  By default, it opens a new Terminal window, but Terminal doesn&#39;t work as well with my window manager as iTerm does.

How to get react-native run-ios to open in iTerm instead of Terminal on a macOS?

The description of [`std::is_void`][1] states that:

&gt; Provides the member constant value  that is equal to true, if T is the **type void, const void, volatile
&gt; void,** or const volatile void.

Then what could be `const void`, or a `volatile void` ? 

[This answer][2] states that `const void` return type would be invalid (however compiles on VC++ 2015)

    const void foo() { }

If by standard, `const void` is invalid (VC being wrong) - then what is `const void`?
  [1]: http://en.cppreference.com/w/cpp/types/is_void
  [2]: https://stackoverflow.com/a/28707034/264325

What is const void?

The description of [<code>std::is_void</code>][1] states that:
> Provides the member constant value that is equal to true, if T is the type void, const void, volatile
> void, or const volatile void.
Then what could be <code>const void</code>, or a <code>volatile void</code> ?
[This answer][2] states that <code>const void</code> return type would be invalid (however compiles on VC++ 2015)
<pre><code class="hljs language-csharp">const void foo() { }
</code></pre>
If by standard, <code>const void</code> is invalid (VC being wrong) - then what is <code>const void</code>?
[1]: <a href="http://en.cppreference.com/w/cpp/types/is_void" target="_blank" rel="noopener noreferrer">http://en.cppreference.com/w/cpp/types/is_void</a>
[2]: <a href="https://stackoverflow.com/a/28707034/264325" target="_blank" rel="noopener noreferrer">https://stackoverflow.com/a/28707034/264325</a>

Does C++11 standard library provide any utility to convert from a `std::shared_ptr` to `std::unique_ptr`, or vice versa? Is this safe operation?

Does C++11 unique_ptr and shared_ptr able to convert to each other&#39;s type?

I&#39;ve recently come across some code which has a loop of the form

    for (int i = 0; i &lt; 1e7; i++){
    }

I question the wisdom of doing this since 1e7 is a floating point type, and will cause `i` to be promoted when evaluating the stopping condition. Should this be of cause for concern?


Using scientific notation in for loops

When should I declare my function as:

`void foo(Widget w);`

as opposed to

`void foo(Widget&amp;&amp; w);`?

Assume this is the only overload (as in, I pick one or the other, not both, and no other overloads). No templates involved. Assume that the function `foo` requires ownership of the `Widget` (e.g. `const Widget&amp;` is not part of this discussion). I&#39;m not interested in any answer outside the scope of these circumstances. See addendum at end of post for *why* these constraints are part of the question.

The primary difference that my colleagues and I can come up with is that the rvalue reference parameter forces you to be explicit about copies. The caller is responsible for making an explicit copy and then passing it in with `std::move` when you want a copy. In the pass by value case, the cost of the copy is hidden:

        //If foo is a pass by value function, calling + making a copy:
        Widget x{};
        foo(x); //Implicit copy
        //Not shown: continues to use x locally
        
        //If foo is a pass by rvalue reference function, calling + making a copy:
        Widget x{};
        //foo(x); //This would be a compiler error
        auto copy = x; //Explicit copy
        foo(std::move(copy));
        //Not shown: continues to use x locally

Other than that difference. Other than forcing people to be explicit about copying and changing how much syntactic sugar you get when calling the function, how else are these different? What do they say differently about the interface? Are they more or less efficient than one another?

Other things that my colleagues and I have already thought of:

 * The rvalue reference parameter means that you *may* move the argument, but does not mandate it. It is possible that the argument you passed in at the call site will be in its original state afterwards. It&#39;s also possible the function would eat/change the argument without ever calling a move constructor but assume that because it was an rvalue reference, the caller relinquished control. Pass by value, if you move into it, you must assume that a move happened; there&#39;s no choice.
 * Assuming no elisions, a single move constructor call is eliminated with pass by rvalue.
 * The compiler has better opportunity to elide copies/moves with pass by value. Can anyone substantiate this claim? Preferably with a link to gcc.godbolt.org showing optimized generated code from gcc/clang rather than a line in the standard. My attempt at showing this was probably not able to successfully isolate the behavior: https://godbolt.org/g/4yomtt


**Addendum:** *why* am I constraining this problem so much?

 * No overloads - if there were other overloads, this would devolve into a discussion of pass by value vs a set of overloads that include both const reference and rvalue reference, at which point the set of overloads is obviously more efficient and wins. This is well known, and therefore not interesting.
 * No templates - I&#39;m not interested in how forwarding references fit into the picture. If you have a forwarding reference, you call std::forward anyway. The goal with a forwarding reference is to pass things as you received them. Copies aren&#39;t relevant because you just pass an lvalue instead. It&#39;s well known, and not interesting.
 * `foo` requires ownership of `Widget` (aka no `const Widget&amp;`) - We&#39;re not talking about read-only functions. If the function was read-only or didn&#39;t need to own or extend the lifetime of the `Widget`, then the answer trivially becomes `const Widget&amp;`, which again, is well known, and not interesting. I also refer you to why we don&#39;t want to talk about overloads.

Pass by value vs pass by rvalue reference

I have a pointer, `ptr`, and a condition, `cond`. I need the fastest possible way to reset `ptr` if `cond` is `true`, or keep `ptr` unchanged if `cond` is `false`. The current implementation is, trivially:

    void reset_if_true(void*&amp; ptr, bool cond)
    {
        if (cond)
            ptr = nullptr;
    }

I&#39;m aware that the above code performance is good, and I cannot expect a major performance boost optimizing it. However, this code is called several millions of times per second and every little nanosecond saved is relevant.

I was thinking about something that get rid of the branch, e.g.:

    void* p[] = { ptr, nullptr };
    ptr = p[cond];

but I&#39;m not sure it&#39;s the best way to proceed.


What is the fastest way to update a variable on a condition?

I&#39;m trying to set up clang-tidy for a project. I&#39;d like to be able to have clean output, and encourage the use of -fix mode where possible. However, there are individual cases where an exception is needed.

Much as it is possible to use

    #pragma clang diagnostic push
    #pragma clang diagnostic ignored &quot;-Wreserved-id-macro&quot;
    // Code that is being specially exempted
    #pragma clang diagnostic pop

for the equivalent case where one wants to locally disable a compiler warning, is it possible to do something similar from clang-tidy?

I have tried 

    #pragma clang diagnostic push
    #pragma clang diagnostic ignored &quot;readability-identifier-naming&quot;
    // Code that is being specially exempted
    #pragma clang diagnostic pop

and also with `clang` replaced with `clang-tidy`. Unfortunately when using `clang` as the pragma target and compiling with regular clang, I get the compilation warning 

    warning: pragma diagnostic expected option name (e.g. &quot;-Wundef&quot;) [-Wunknown-pragmas]

 and  

    warning: unknown pragma ignored [clang-diagnostic-unknown-pragmas]

when compiling if I use `clang-tidy` in place of `clang`. Neither make an impact on what `clang-tidy` itself outputs when run over the source.

This is with `clang` and `clang-tidy` 3.8 on x86_64 Linux.

Inline way to disable clang-tidy checks

With almost all code I write, I am often dealing with set reduction problems on collections that ultimately end up with naive &quot;if&quot; conditions inside of them. Here&#39;s a simple example:

    for(int i=0; i&lt;myCollection.size(); i++)
    {
         if (myCollection[i] == SOMETHING)
         {
               DoStuff();
         }
    }

With functional languages, I can solve the problem by reducing the collection to another collection (easily) and then perform all operations on my reduced set. In pseudocode:

    newCollection &lt;- myCollection where &lt;x=true
    map DoStuff newCollection

And in other C variants, like C#, I could reduce with a where clause like

    foreach (var x in myCollection.Where(c=&gt; c == SOMETHING)) 
    {
       DoStuff();
    }

Or better (at least to my eyes)

    myCollection.Where(c=&gt;c == Something).ToList().ForEach(d=&gt; DoStuff(d));

Admittedly, I am doing a lot of paradigm mixing and subjective/opinion based style, but I can&#39;t help but feel that I am missing something really fundamental that could allow me to use this preferred technique with C++. Could someone enlighten me?

How can I avoid &quot;for&quot; loops with an &quot;if&quot; condition inside them with C++?

How can I find out what type the compiler deduced when using the ``auto`` keyword?

Example 1: Simpler

    auto tickTime = 0.001;

Was this deduced as a ``float`` or a ``double?``

Example 2: More complex (and my present headache):

    typedef std::ratio&lt;1, 1&gt; sec;
    std::chrono::duration&lt;double, sec &gt; timePerTick2{0.001};
     auto nextTickTime = std::chrono::high_resolution_clock::now() + timePerTick2;

What type is ``nextTickTime``?

The problem I&#39;m having is when I try to send ``nextTickTime`` to ``std::cout``. I get the following error:

    ./main.cpp: In function ‘int main(int, char**)’:
    ./main.cpp:143:16: error: cannot bind ‘std::basic_ostream&lt;char&gt;’ lvalue to ‘std::basic_ostream&lt;char&gt;&amp;&amp;’
      std::cout &lt;&lt; std::setprecision(12) &lt;&lt; nextTickTime &lt;&lt; std::endl; // time in seconds
                ^
    In file included from /usr/include/c++/4.8.2/iostream:39:0,
                 from ./main.cpp:10:
    /usr/include/c++/4.8.2/ostream:602:5: error:   initializing argument 1 of ‘std::basic_ostream&lt;_CharT, _Traits&gt;&amp; std::operator&lt;&lt;(std::basic_ostream&lt;_CharT, _Traits&gt;&amp;&amp;, const _Tp&amp;) [with _CharT = char; _Traits = std::char_traits&lt;char&gt;; _Tp = std::chrono::time_point&lt;std::chrono::_V2::system_clock, std::chrono::duration&lt;double, std::ratio&lt;1l, 1000000000l&gt; &gt; &gt;]’
     operator&lt;&lt;(basic_ostream&lt;_CharT, _Traits&gt;&amp;&amp; __os, const _Tp&amp; __x)


Using &#39;auto&#39; type deduction - how to find out what type the compiler deduced?

Is there a rule which states in which order the members of an std::tuple are destroyed?

For example if `Function1` returns an `std::tuple&lt;std::unique_ptr&lt;ClassA&gt;, std::unique_ptr&lt;ClassB&gt;&gt;` to `Function2`, then can I be sure that (when the scope of `Function2` is left) the instance of `ClassB` referred to by the second member is destroyed before the instance of `ClassA` referred to by the first member?

    std::tuple&lt; std::unique_ptr&lt; ClassA &gt;, std::unique_ptr&lt; ClassB &gt; &gt; Function1()
    {
        std::tuple&lt; std::unique_ptr&lt; ClassA &gt;, std::unique_ptr&lt; ClassB &gt; &gt; garbage;
        get&lt;0&gt;(garbage).reset( /* ... */ );
        get&lt;1&gt;(garbage).reset( /* ... */ );
        return garbage;
    }

    void Function2()
    {
        auto to_be_destroyed = Function1();
        // ... do something else
    
        // to_be_destroyed leaves scope
        // Is the instance of ClassB destroyed before the instance of ClassA?
    }

C++ std::tuple order of destruction

The strings topic in the SO Documentation used to say, in the Remarks section:

&gt; Since C++14, instead of using `&quot;foo&quot;`, it is recommended to use `&quot;foo&quot;s`, as `s` is a string literal, which converts the `const char *` `&quot;foo&quot;` to `std::string` `&quot;foo&quot;`.

The only advantage I see using

    std::string str = &quot;foo&quot;s;

instead of

    std::string str = &quot;foo&quot;;

is that in the first case the compiler can perform copy-elision (I think), which would be faster than the constructor call in the second case.

Nonetheless, this is (not yet) guaranteed, so the first one might also call a constructor, the copy constructor.

Ignoring cases where it is *required* to use `std::string` literals like

    std::string str = &quot;Hello &quot;s + &quot;World!&quot;s;

is there any benefit of using `std::string` literals instead of `const char[]` literals?

Advantages of using user-defined literal for strings instead of string literal

In a function that takes several arguments of the same type, how can we guarantee that the caller doesn&#39;t mess up the ordering?

For example

    void allocate_things(int num_buffers, int pages_per_buffer, int default_value ...

and later

    // uhmm.. lets see which was which uhh..
    allocate_things(40,22,80,...

C++ function argument safety

As I understood in C++11 `decltype(expression)` is used to deduce the exact same type of the given expression. But when the expression is put into parentheses itself, then the deduces type is *lvalue reference* to the expression type. For example:

    int x;
    decltype(x) y = x;

is equivalent to `int y = x;` but,

    int x;
    decltype((x)) y = x;

is equivalent to `int&amp; y = x;`.

Respectively

     decltype(auto) f1()
     {
       int x = 0;
       return x; // decltype(x) is int, so f1 returns int
     }

but

     decltype(auto) f2()
     {
       int x = 0;
       return (x); // decltype((x)) is int&amp;, so f2 returns int&amp;
     }

What is the rationale for this behavior to be chose by the standard committee?

**Afterwords:**

Now I observed that at least in the case of **GCC 6.2** implementation when the expression in the parentheses is more complex for example `decltype((x + x))` the deduced type is `T`, but not `T&amp;`. This is even more confusing. I don&#39;t know whether this behavior is standard.

Content Type	Original Author	Original Content on Stackoverflow
Question	Ajay	View Question on Stackoverflow
Solution 1 - C++	Benjamin Lindley	View Answer on Stackoverflow
Solution 2 - C++	Columbo	View Answer on Stackoverflow
Solution 3 - C++	DevSolar	View Answer on Stackoverflow

What is const void?

C++ Problem Overview

C++ Solutions

Solution 1 - C++

Solution 2 - C++

Solution 3 - C++

How to get react-native run-ios to open in iTerm instead of Terminal on a macOS?

How to generate fixed url with ngrok

Attributions