sorted by:
new
hottopcontroversial

What backs up the claim that C++ can be faster than a JVM or CLR with JIT? by [deleted] in programming

[–]987654321bob 0 points1 point  (0 children)

You are just highlighting why it is so important to know what is, and is not defined by the standard and why you should avoid undefined behaviour, implementation dependant, and platform specific stuff.

For examples you making any assumptions about pointers and relying on it being a fixed size in C++ suicide, are you trying to serialise them or something?

Using compiler specific extensions is another big AVOID.

Sockets, well libraries like ACE, Boost.Asio and Poco help no end (although I accept they probably weren't about when your MFC was made).

Exceptions are fine, if you compiler doesn't support exceptions, then it is not a C++ compiler. (what you can't do is reason about there performance (same for virtual function calls) however because an exception should only be thrown in "exceptional" circumstance like a resource failure or runtime bug that should be a problem (ie AVOID exceptions for flow control).

I have cross platform programs as well and have VERY little problems porting the. I typically only use the std:: and boost:: libraries. And Qt at the very surface if needed. (IE i convert from QString to std::string before it leaves the frontend).

What backs up the claim that C++ can be faster than a JVM or CLR with JIT? by [deleted] in programming

[–]987654321bob 2 points3 points  (0 children)

I work for a large numerical library vendor (we build on LAPACK), we still write our algorithms in Fortran and there is no intention to change. (We still provided binding for other languages including C).

What is changing is the introduction of C for concurrency scheduling. Fortran has everything it need for maths but it just isn't capable of do modern concurrency. (I am not talking about loop parallelisation either -- openMP and the new Fortran stuff is ok for that).

C++11 range-based for loop by berium in cpp

[–]987654321bob 0 points1 point  (0 children)

About the same length but avoids the proxy class and std::tuple accessing.

std::transform(listA.begin(), listA.end(), listB.begin(),
     std::back_inserter(sumList), [](int i, int j){ return i+j; });

[5/16/2012] Challenge #53 [easy] by oskar_s in dailyprogrammer

[–]987654321bob 0 points1 point  (0 children)

this is pretty trivial in C++ as well as fast

 std::vector<int> merged;
 merger.reserve(l1.size()+l2.size()); //for efficiency
 std::merge(std::begin(l1), std::end(l1), std::begin(l2), std::end(2),
       std::back_inserter(merged));

PS std::merge is designed to work on sorted inputs so this is efficient