vs2008 vs vs2010 issue

Was the near/far thing a 64 bit thing? I though the near/far dated back to win16 programming?

Regardless, it compiles.

The UTF-8 BOM, signifying nothing, and annoying the hell out of developers and users.

sure.

UnitTest is something that runs at every server startup. so they must very light and fast.

"real" tests should go in dbtests / test binary (or jstests if applicable)

running tests v good idea. see "smoke" page on wiki

Dwight,

Shouldn't we also check the error cases?

I'll confess I'm not running the unit tests on my machine. I'll start doing that.

Test code I used for this.:

#include 
#include 
#include 
namespace mongo {
    inline void uasserted(int msgid , char* msg) { printf("Msg: %s", msg); exit(4); }
    /* "user assert".  if asserts, user did something wrong, not our code */
    #define MONGO_uassert(msgid, msg, expr) (void)( (!!(expr)) || (mongo::uasserted(msgid, msg), 0) )
    #define uassert MONGO_uassert
    inline long long parseLL( const char *n );
    // expect that n contains a base ten number and nothing else after it
    // NOTE win version hasn't been tested directly
    inline long long parseLL( const char *n ) {
        long long ret;
        uassert( 13307, "cannot convert empty string to long long", *n != 0 );
#if !defined(_WIN32)
        char *endPtr = 0;
        errno = 0;
        ret = strtoll( n, &endPtr;, 10 );
        uassert( 13305, "could not convert string to long long", *endPtr == 0 && errno == 0 );
#else
#if _MSC_VER>=1600
        size_t endLen = 0;
        try {
            ret = std::stoll( n, &endLen;, 10 );
        } catch ( ... ) {
            endLen = 0;
        }
        uassert( 13306, "could not convert string to long long", endLen != 0 && n[ endLen ] == 0 );
#else // stoll() wasn't introduced into VS 2010.
        char* endPtr = (char *)&n;[strlen(n) - 1];
        try {
            ret = _strtoi64( n, &endPtr;, 10 );
        } catch ( ... ) {
            endPtr = 0;
        }
        uassert( 13310, "could not convert string to long long", *endPtr == 0 );
#endif // _MSC_VER >= 16
#endif // !defined(_WIN32)
        return ret;
    }
}
void main () {
    //printf("_MSC_VER: %d\n", _MSC_VER);
    char szNumber[] = "999999999";
    printf("number '%s': %d\n\n", szNumber, mongo::parseLL(szNumber));
    
    char szNumberWhitespace[] = "   999999999   999";
    printf("number '%s': %d\n\n", szNumberWhitespace, mongo::parseLL(szNumberWhitespace));
    
    char szNumberBad[] = "99r9dd999999";
    printf("number '%s': %d\n\n", szNumberBad, mongo::parseLL(szNumberBad));
}

The older, more conservative function is _strtoi64()
Fix in https://github.com/zippy1981/mongo/commit/f7b7c07e2a72011b8dbd72d10dcbaa22d8e5fb54
Stackoverflow discussion is in https://stackoverflow.com/questions/3106026/is-there-a-stoll-stroll-string-to-long-long-alternative-in-visual-studio-20/3106060#3106060

stoll() doesn't exist in Visual Studio 2008. I'm installing the windows 7 SDK to see if that will rectify it, but perhaps even being dirty and calling atol() would be better than causing build problems.

Shouldn't the constant MaxBSONObjectSize be used instead? In case one wants to customize the size.

Confirmed that actually worked.

that's an accident. will remove.

Is it necessarily a good idea to have class diagrams in the visual studio projects? These projects will always be an afterthought (and rightly so) to the scons project.

Good to see I'm not the only one improving error messages!

Bravo :)

Looks like a typo here:

https://github.com/mongodb/mongo/commit/2b7eb102159a36129222afa1883ea3b15145e08b#L0R40

See &7 instead of &&

lol ;)

this was just a test.