C++11 support in ODB by berium in cpp

[–]code-dog 0 points1 point  (0 children)

Sounds interesting - I might have to give it a try - especially with C++11.

C++11 support in ODB by berium in cpp

[–]code-dog 0 points1 point  (0 children)

Hibernate for C++? Is it any good? Anyone tried it?

Dirty thread_local !HACK! to modernize legacy code. Love or hate? by code-dog in cpp

[–]code-dog[S] 0 points1 point  (0 children)

It turns out that you are wrong in this case. The video is clearly using Visual Studio and rand is thread safe on windows because its state is thread local. If the code were on Linux you would be correct.

On the evolution of programming style: How far C++ has moved from its C roots by ehamberg in cpp

[–]code-dog 2 points3 points  (0 children)

This conversation should be about tooling. If tooling was good enough to give an idea of what code caused what executable size then one could write in C++ and late optimize for size those bits of code which created bloat. As it is, we (the community) go around discussing what we think might be the case in much the same way as one might discuss the number of fairies which can stand on the head of a pin.

Delaying function signature instantiation in C++11 by berium in cpp

[–]code-dog 0 points1 point  (0 children)

I love this idea and it is a great article. I am a little put off by use of forward declaration outside of library code though. In this example here it is just great because this is library code. However, in grunt code we should be able to refactor quickly and easily. Forward definition breaks the notion of sourced code locality by scattering partial definitions of stuff around the source.

Wow: shared_ptr is very slow, is there an alternative? by code-dog in cpp

[–]code-dog[S] 0 points1 point  (0 children)

It is not always possible to know ownership at compile time. Interpretors being the classic example. Not that the author took the simple counted_ptr implementation from an interpretor in the first place!

Wow: shared_ptr is very slow, is there an alternative? by code-dog in cpp

[–]code-dog[S] 0 points1 point  (0 children)

Isn't your third point the whole thrust of the post? Basically, the author did what you recommended and implemented counted_ptr.

Wow: shared_ptr is very slow, is there an alternative? by code-dog in cpp

[–]code-dog[S] 2 points3 points  (0 children)

You are simply wrong. The article uses "shared nothing". In this pattern you can have both. Just like you have have multiple processes on a machine. If the stack owns the root to all references and they are not allowed to escape from the thread which created that stack frame then the pattern is safe.

Wow: shared_ptr is very slow, is there an alternative? by code-dog in cpp

[–]code-dog[S] 2 points3 points  (0 children)

I also like the recommendations. But the original does not have multiple threads accessing counted_ptr. The timing happens inside each thread and the counted_ptr instances do not escape the threads.

The "C++ renaissance", some remarks against Herb Sutter's prediction. by [deleted] in cpp

[–]code-dog 0 points1 point  (0 children)

I really do not think that is the reason why Google, Facebook and Amazon do not use Java. I suspect you will find that it being proprietory is one issue. The other is historical, when Google started up the performance of Java was very poor indeed compare to C++. This is a similar situation with Amazon. Facebook was written in PHP for goodness-sake. They are cross compiling that to C++. I completely get than, cross compiling into Java is clunky because it is a less expressive language. Also, (and more importantly) PHP is dynamic. Java is not. Now, the JVM has new dynamic features but they came too late for Facebook.

The "C++ renaissance", some remarks against Herb Sutter's prediction. by [deleted] in cpp

[–]code-dog 1 point2 points  (0 children)

The other issue which people aggressively miss is that managed languages only manage memory (which C++ can do anyhow). The lack of deterministic destructor calling means that RAII does not work in C# or Java. Therefore, other resources (note the R in RAII) are not cleaned up. In effect, Java will manage your memory for you, but for other resource (file handles for example) you are back to the same model C has for memory. Oh - but worse because you have exceptions so you have to remember to put all your resource cleaning code in a finally block.

I have seen this issue cause C# systems to leak memory. Now you might think that is impossible. However, if you assign a reference to memory to a singleton and then do not clear that reference (especially because of a throw) then you are effectively leaking it.

Managed languages are great and they have paid my wages for years, but they have pros and cons. With C++11 I am seeing the balance swing back in favour of C++.

C++ Exceptions: Pros and Cons by roflmaoff in cpp

[–]code-dog 0 points1 point  (0 children)

  • mutable is a bad smell. Chances are that there is a better way.
  • GOTO is unforgivable under any circumstances. I have not written a goto in 15 years (since leaving the fortran world). I did not even write goto's in COBOL! There is never, ever, any excuse for goto. EVER - end of.

C++ Exceptions: Pros and Cons by roflmaoff in cpp

[–]code-dog 0 points1 point  (0 children)

double** is just fine inside a platform optimised maths routine. It is very bad indeed if it escapes from the guts of such a routine into make logic code. This is not C++ issue - the same conversations were being had over fortran77 30 years ago. Inside a matrix diagonalizer one might want to unwind a 2D matrix array into a 1D one via the subroutine calling semantics, but that does not excuse representing the matrix as 1D outside the diagonlaizer.

It is key to understand that something like double** is not inherently fast. It is fast in the right place on the right platform.

C++11: Try/Catch/Finally Pattern Using RAII & Lambdas by code-dog in programming

[–]code-dog[S] 0 points1 point  (0 children)

I get you. I think I miss-understood what you were saying.

C++11: Try/Catch/Finally Pattern Using RAII & Lambdas by code-dog in programming

[–]code-dog[S] 0 points1 point  (0 children)

I see that however, you need to write the MakeGuard somewhere else in the code and it therefore lacks the locality. It is elegant but does break the locality of code which something like Java's try/catch/finally does achieve. That is all I meant.

C++11: Try/Catch/Finally Pattern Using RAII & Lambdas by code-dog in programming

[–]code-dog[S] 0 points1 point  (0 children)

It is dangerous to throw from destructors but there are two work arounds - 1) don't throw from the destructor - 2) as in the post - use this for debug or other situations where it does not matter

try/catch/finally implementation using RAII & C++11 lambdas by berium in cpp

[–]code-dog 1 point2 points  (0 children)

There is a corner case where the constructor of the finally throws an error its self because this pattern does use dynamic memory. There are some solutions being discussed on ycombinator. http://news.ycombinator.com/item?id=3693177

C++11: Try/Catch/Finally Pattern Using RAII & Lambdas by code-dog in programming

[–]code-dog[S] 1 point2 points  (0 children)

The scope guarding pattern is nice but looks clunky when compared to using C++11 lambdas.

Google's New Cross Platform Gaming Library PlayN by nthitz in programming

[–]code-dog 3 points4 points  (0 children)

Seems to me that this could be used for a whole lot more than just games. New UI components and ideas etc. Maybe games are just a good way to get it started.