#include <algorithm>

#include <iostream>

#include <ostream>

#include <vector>

using namespace std;

class Foo {

public:

    explicit Foo(const int x) : m_x(x) { }

    void mult(vector<vector<int>>& outer) const {

        for_each(outer.begin(), outer.end(), [&](vector<int>& inner) {

            for_each(inner.begin(), inner.end(), [&](int& elem) {

                elem *= m_x;

            });

        });

    }

private:

    int m_x;

};

int main() {

    Foo f(1000);

    vector<vector<int>> v(3, vector<int>(4));

    for (int i = 0; i < 3; ++i) {

        for (int j = 0; j < 4; ++j) {

            v[i][j] = i * 10 + j;

        }

    }

    f.mult(v);

    for (int i = 0; i < 3; ++i) {

        for (int j = 0; j < 4; ++j) {

            cout << v[i][j] << " ";

        }

        cout << endl;

    }

}

C:\Temp>cl

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 17.00.40309 for 80x86

Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Temp>cl /EHsc /nologo /W4 meow.cpp

meow.cpp

meow.cpp(14) : error C3494: 'this' cannot be captured in a nested lambda

meow.cpp(14) : error C2065: 'm_x' : undeclared identifier

meow.cpp(14) : error C2065: 'm_x' : undeclared identifier

C:\Temp>g++ -Wall -Wextra -std=c++0x meow.cpp -o meow.exe

C:\Temp>meow

0 1000 2000 3000

10000 11000 12000 13000

20000 21000 22000 23000

There's a workaround:

C:\Temp>type meow.cpp

#include <algorithm>

#include <iostream>

#include <ostream>

#include <vector>

using namespace std;

class Foo {

public:

    explicit Foo(const int x) : m_x(x) { }

    void mult(vector<vector<int>>& outer) const {

        const Foo * const myself = this;

        for_each(outer.begin(), outer.end(), [&](vector<int>& inner) {

            for_each(inner.begin(), inner.end(), [&](int& elem) {

                elem *= myself->m_x;

            });

        });

    }

private:

    int m_x;

};

int main() {

    Foo f(1000);

    vector<vector<int>> v(3, vector<int>(4));

    for (int i = 0; i < 3; ++i) {

        for (int j = 0; j < 4; ++j) {

            v[i][j] = i * 10 + j;

        }

    }

    f.mult(v);

    for (int i = 0; i < 3; ++i) {

        for (int j = 0; j < 4; ++j) {

            cout << v[i][j] << " ";

        }

        cout << endl;

    }

}

C:\Temp>cl /EHsc /nologo /W4 meow.cpp

meow.cpp

C:\Temp>meow

0 1000 2000 3000

10000 11000 12000 13000

20000 21000 22000 23000

C:\Temp>g++ -Wall -Wextra -std=c++0x meow.cpp -o meow.exe

C:\Temp>meow

0 1000 2000 3000

10000 11000 12000 13000

20000 21000 22000 23000

#include <type_traits>

template <typename T> struct A {

    A() {

        static_assert(std::is_base_of<A<T>, T>::value, "assert1");

        typedef typename std::remove_reference<decltype(*this)>::type meow_t;

        static_assert(std::is_base_of<meow_t, T>::value, "assert2");

    }

};

struct C : public A<C> { };

void foo() {

    C c;

}

C:\Temp>cl

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 17.00.40316 for 80x86

Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Temp>cl /EHsc /nologo /W4 /c meow.cpp

meow.cpp

C:\Temp>

*this is an lvalue so decltype(*this) is indeed A<T>&.

The volatile keyword is a type qualifier used to declare that an object can be modified in the program by something other than statements, such as the operating system, the hardware, or a concurrently executing thread.

The following example declares a volatile integer nVint whose value can be modified by external processes:

int volatile nVint;

Objects declared as volatile are not used in optimizations because their value can change at any time. The system always reads the current value of a volatile object at the point it is requested, even if the previous instruction asked for a value from the same object. Also, the value of the object is written immediately on assignment.

One use of the volatile qualifier is to provide access to memory locations used by asynchronous processes such as interrupt handlers.

This means a value that can automatically change at any given instance. This is usually in reference to a hardware register that often has a different value ever time you read it. Specifically, it is useful to define some values as volatile so that a C compiler will not cache that value, but rather, get a fresh copy every time you request it's value. Otherwise, the compiler may return values which are inaccurate because it doesn't realized the value can change.

C:\tmp>type honor_volatile.c

#if !defined(VOLATILE)

#error

#endif

void test_one()

{

VOLATILE int x = 5;

}

void test_two(VOLATILE int x)

{

   x = 5;

}

C:\tmp>cl -O2 -c -Fa -DVOLATILE= honor_volatile.c

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 17.00.40308 for 80x86

Copyright (C) Microsoft Corporation.  All rights reserved.

honor_volatile.c

C:\tmp>type honor_volatile.asm

; Listing generated by Microsoft (R) Optimizing Compiler Version 17.00.40308.0

        TITLE   C:\tmp\honor_volatile.c

        .686P

        .XMM

        include listing.inc

        .model  flat

INCLUDELIB LIBCMT

INCLUDELIB OLDNAMES

PUBLIC  _test_one

PUBLIC  _test_two

; Function compile flags: /Ogtpy

;       COMDAT _test_two

_TEXT   SEGMENT

_x$ = 8                                                 ; size = 4

_test_two PROC                                          ; COMDAT

; File c:\tmp\honor_volatile.c

; Line 15

        ret     0

_test_two ENDP

_TEXT   ENDS

; Function compile flags: /Ogtpy

;       COMDAT _test_one

_TEXT   SEGMENT

_test_one PROC                                          ; COMDAT

; File c:\tmp\honor_volatile.c

; Line 10

        ret     0

_test_one ENDP

_TEXT   ENDS

END

C:\tmp>cl -O2 -c -Fa -DVOLATILE=volatile honor_volatile.c

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 17.00.40308 for 80x86

Copyright (C) Microsoft Corporation.  All rights reserved.

honor_volatile.c

C:\tmp>type honor_volatile.asm

; Listing generated by Microsoft (R) Optimizing Compiler Version 17.00.40308.0

        TITLE   C:\tmp\honor_volatile.c

        .686P

        .XMM

        include listing.inc

        .model  flat

INCLUDELIB LIBCMT

INCLUDELIB OLDNAMES

PUBLIC  _test_one

PUBLIC  _test_two

; Function compile flags: /Ogtpy

;       COMDAT _test_two

_TEXT   SEGMENT

_x$ = 8                                                 ; size = 4

_test_two PROC                                          ; COMDAT

; File c:\tmp\honor_volatile.c

; Line 14

        mov     DWORD PTR _x$[esp-4], 5

; Line 15

        ret     0

_test_two ENDP

_TEXT   ENDS

; Function compile flags: /Ogtpy

;       COMDAT _test_one

_TEXT   SEGMENT

_x$ = -4                                                ; size = 4

_test_one PROC                                          ; COMDAT

; File c:\tmp\honor_volatile.c

; Line 8

        push    ecx

; Line 9

        mov     DWORD PTR _x$[esp+4], 5

; Line 10

        pop     ecx

        ret     0

_test_one ENDP

_TEXT   ENDS

END

 

And this is assembly code from VS:

#include <stdio.h>
void main()
{
 volatile int i=10;
 int a = i;

 printf("i= %d\n",a);
 __asm {
  mov         dword ptr [ebp-4], 20h
 }

 int b = i;
 printf("i= %d\n",b);
}

Release:

009C1002  in          al,dx 

009C1003  push        ecx 

009C1004  push        esi 

 volatile int i=10;

int a = i;

printf("i= %d\n",a);

009C1005  mov         esi,dword ptr [__imp__printf (9C20A0h)] 

009C100B  mov         dword ptr [i],0Ah 

009C1012  mov         eax,dword ptr [i] 

009C1015  push        eax 

009C1016  push        offset string "i= %d\n" (9C20F4h) 

009C101B  call        esi 

009C101D  add         esp,8 

 __asm {

  mov         dword ptr [ebp-4], 20h

009C1020  mov         dword ptr [i],20h 

 }

int b = i;

009C1027  mov         eax,dword ptr [i] 

 printf("i= %d\n",b);

009C102A  push        eax 

009C102B  push        offset string "i= %d\n" (9C20F4h) 

009C1030  call        esi 

009C1032  add         esp,8 

009C1035  pop         esi 

}

009C1036  mov         esp,ebp 

009C1038  pop         ebp 

009C1039  ret 

Debug:

#include <stdio.h>

void main()

{

001B13B0  push        ebp 

001B13B1  mov         ebp,esp 

001B13B3  sub         esp,0E4h 

001B13B9  push        ebx 

001B13BA  push        esi 

001B13BB  push        edi 

001B13BC  lea         edi,[ebp-0E4h] 

001B13C2  mov         ecx,39h 

001B13C7  mov         eax,0CCCCCCCCh 

001B13CC  rep stos    dword ptr es:[edi] 

 volatile int i=10;

001B13CE  mov         dword ptr [i],0Ah 

 int a = i;

001B13D5  mov         eax,dword ptr [i] 

001B13D8  mov         dword ptr [a],eax 

printf("i= %d\n",a);

001B13DB  mov         esi,esp 

001B13DD  mov         eax,dword ptr [a] 

001B13E0  push        eax 

001B13E1  push        offset string "i= %d\n" (1B573Ch) 

001B13E6  call        dword ptr [__imp__printf (1B82D4h)] 

001B13EC  add         esp,8 

001B13EF  cmp         esi,esp 

001B13F1  call        @ILT+300(__RTC_CheckEsp) (1B1131h) 

 __asm {

  mov         dword ptr [ebp-4], 20h

001B13F6  mov         dword ptr [ebp-4],20h 

 }

int b = i;

001B13FD  mov         eax,dword ptr [i] 

001B1400  mov         dword ptr [b],eax 

 printf("i= %d\n",b);

001B1403  mov         esi,esp 

001B1405  mov         eax,dword ptr [b] 

001B1408  push        eax 

001B1409  push        offset string "i= %d\n" (1B573Ch) 

001B140E  call        dword ptr [__imp__printf (1B82D4h)] 

001B1414  add         esp,8 

001B1417  cmp         esi,esp 

001B1419  call        @ILT+300(__RTC_CheckEsp) (1B1131h) 

}

C:\Temp>type meow.cpp

#include <stdio.h>

int main() {

    MEOW int i = 10;

    int a = i;

    printf("a: %d\n", a);

    __asm {

        mov dword ptr [ebp - 4], 20h

    }

    int b = i;

    printf("b: %d\n", b);

}

C:\Temp>cl /EHsc /nologo /W4 /MTd /DMEOW= meow.cpp && meow

meow.cpp

a: 10

b: 32

C:\Temp>cl /EHsc /nologo /W4 /MT /O2 /DMEOW= meow.cpp && meow

meow.cpp

a: 10

b: 10

C:\Temp>cl /EHsc /nologo /W4 /MTd /DMEOW=volatile meow.cpp && meow

meow.cpp

a: 10

b: 32

C:\Temp>cl /EHsc /nologo /W4 /MT /O2 /DMEOW=volatile meow.cpp && meow

meow.cpp

a: 10

b: 32

Volatility inhibits optimizations, as expected.

function<void()> task = [&](){ File::HashFile( bind(&Comparator::CompareData, ref(compare), _1, _2, _3, false), *pFile1 ); };

function<void()> task = [&](){ File::HashFile([&](const void *pv, size_t cb, const char *szDesc) { compare.CompareData(pv, cb, szDesc, false); }, *pFile1 ); };

(Random comment: The 170 lines of incomprehensible errors you get if you forget the static_cast<HashFn> on the first line is completely obnoxious.  [HashFn is a typedef for function<void(const void *, size_t, const char *)>])

 

The last one is the best

Lambdas supersede bind() 99% of the time - they are easier to read, easier to write, more efficient, and don't explode horribly.  The remaining 1% of cases are better handled by handwritten functors (e.g. with templated function call operators).

This is especially true now that 16.1/VC11's lambdas v1.1 handle nested lambdas just fine.  (In contrast, nested bind() is a bug farm, which has been tormenting me for years.)

 

I wish it was true…

         Lambdas aren’t polymorphic (and even when I write my own ad hoc function objects I prefer to make them stateless and just use bind for state)

         You do not have to specify the argument(s) type(s)

         IMHO, for simple bindings, bind is easier to read

         Bind has been around for so many years that, at least to me, it just come natural.

I completely agree about nested binds: understanding them is mindbending.

http://msdn.microsoft.com/en-us/library/dd465215(VS.100).aspx says:

The Visual C++ compiler lets you use the nullptr keyword with native code or with managed code. ... The compiler interprets nullptr to be managed code when you use the /clr compiler option, and native code when you do not use the /clr option.

Then adds:

The Microsoft-specific __nullptr keyword has the same meaning as nullptr, but it applies to native code only. If you compile native C/C++ code by using the /clr compiler option, the compiler cannot determine whether the nullptr keyword is a native or a managed term. To make your intention clear to the compiler, use the nullptr keyword to specify the managed term, and __nullptr to specify the native term.

Highlighted part indicates that compiler cannot determine whether it is native or managed, but the previous paragraph just said it will interpret it as managed.

http://msdn.microsoft.com/en-us/library/4ex65770.aspx says the same "cannot determine" thing and then gives an example to contrary:

The following sample shows that nullptr can be assigned to a native pointer when you compile with /clr.

// mcpp_nullptr_6.cpp

// compile with: /clr

int main() {

   int * i = 0;

   int * j = nullptr;

}

So what should I expect from all of this? I am guessing that the compiler takes nullptr as managed with /clr,
 because otherwise there wouldn't be a way to say nullptr in managed, and the sample is just an old garbage?
  

Here's how it's supposed to work, and what MSDN should say:

__nullptr is always the Native Nullptr, regardless of whether the compilation is native, /clr, or /clr:pure.

std::nullptr_t is always the Native Nullptr's Type, regardless of whether the compilation is native, /clr, or /clr:pure.  It is defined by <cstddef>.  For good measure (as permitted but not required by C++0x), both <cstddef> and <stddef.h> define both std::nullptr_t and ::nullptr_t.  JonCaves even made the compiler join the fun - it defines std::nullptr_t (but not ::nullptr_t) even in the absence of any headers whatsoever.

nullptr is the Native Nullptr when compiled as native (as required by C++0x).

nullptr is the Managed Nullptr Of Doom when compiled as /clr or /clr:pure (as required by the Necronomicon, 

which is to say C++/CLI).

That said, I don't know how the Managed Nullptr works, except that I've heard that "it doesn't have a type", 

a concept from which my mind recoils in fear.  There's been a little talk of unifying these things, 

but I don't think anybody has figured out what that would involve yet.  When this came up I said:

> Regarding A Tale Of Two Nullptrs, I've heard several times that the problem is that the managed nullptr 

"doesn't have a type", whatever that means, while the native nullptr has a type.  

I don't know what it'd take to unify them (I assume that the native nullptr would have to "win", 

since it cannot be infected with managedness, and conversions to managed stuff would have to be added to make 

up the difference - and too bad for anyone who inspects nullptr closely and is surprised to discover that it 

now has a type - I think all of those words in that order make sense), other than the fact that it 

wasn't obviously simple enough for JonCaves to do in the first place.

> The Iron Nullptr Curtain causes more user suffering than STL suffering, though - 

our only real interaction is in the definition of std::nullptr_t where we simply say decltype(__nullptr).  

In the rest of our implementation, we just use NULL/0 (Dinkumware overwhelmingly prefers 0, as I recall).

 
In this case, perhaps the ambiguity in the docs is a reflection of the thing itself. If nullptr is always 
the MNOD when compiled with /clr, then why does the compiler allow int* j to be initialized with it, 
as shown in the code example referred to below? I don’t know why the docs say “the compiler cannot determine…” 
because at least in these simple initializations it seems to know what to do (converting nullptr to nullptr_t 
when the lhs is a native type, regardless of /clr?). But I’m curious what pain this causes or might cause for users. 
Is there ever a case where the non-identity of these two things leaks out? If so, then we should really mention that 
in the docs.
 
// mcpp_nullptr_6.cpp
// compile with: /clr
int main() {
   int * i = 0;
   int * j = nullptr; //what IS j now?
   int^ k = nullptr; //the same or different?
}

 
C:\Temp>type doooooooom.cpp
#include <iostream>
#include <memory>
#include <ostream>
using namespace std;
 
int main() {
    auto sp = make_shared<int *>(nullptr);
    cout << sp.get() << endl;
}
 
C:\Temp>cl /EHsc /nologo /W4 doooooooom.cpp
doooooooom.cpp
 
C:\Temp>doooooooom
00227B2C
 
C:\Temp>cl /clr /nologo /W4 doooooooom.cpp
doooooooom.cpp
doooooooom.cpp(7) : error C2664: 'std::tr1::shared_ptr<_Ty> std::tr1::make_shared<int*,nullptr>(_Arg0 &&)' : cannot conv
ert parameter 1 from 'nullptr' to 'nullptr &&'
        with
        [
            _Ty=int *,
            _Arg0=nullptr
        ]
        nullptr can only be converted to pointer or handle types
doooooooom.cpp(7) : fatal error C1903: unable to recover from previous error(s); stopping compilation