Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Comment Re:It's pointers all the way down, jake ! (Score 1) 262

In Java, references are pointers. Just because you call them something different doesn't mean they aren't the same. Hell, you can get a "reference" to null in Java. The only difference is that you can't do pointer arithmetic.

Garbage collection has nothing to do with whether something is a reference or a pointer. C++ has garbage collection in the form of scope based destruction of non-pointer owned objects.

Comment Re:Because it was written in Seastar or C++ (Score 1) 341

Just to remind potential programmers. Lean C before you learn any other programming language, otherwise you will not understand why your code's performance is terrible.

C doesn't let you understand why people's code has terrible performance. C has the same problems that make code slow - reference semantics. It's a mistake to conflate low level with "performance". For example, std::sort is faster than qsort, and you can't understand why just by understanding C.

Comment Re:No generics (Score 1) 221

C++ is only a large language if you are looking to implement something very generic, like the STL. If you're just using a library like the STL, it is not large. In fact it is quite a small library, in terms of surface area, and all of the "advanced" language stuff is there for the library implementers to squeeze the last bits of performance out of a generic library.

The C++ devs you've worked with you claim are "the best" probably are the ones trying to use C++ as C with classes or learned C++ from university that teaches even pre-1998 C++. In modern C++, the "strict subset" is about letting the compiler do the work (through RAII, algorithms and type deduction), rather than the C subset of C++. That is what it means to "know" C++.

Comment Re:JAVA FTW (Score 1) 457

Yes, runtime errors that are environmental cannot be caught at compile time. But many other runtime errors are the result of design errors - designs that lead to more possible mistakes. When given a bit of thought, you can make those errors get flagged at compile time.

For example, the classic criticism of C++'s resource management. C++ doesn't have those problems if people used the RAII that's provided by default. You don't need to analyze for leaks or null pointers if those cost-free features (which are also semantic signals) are used. And by leaks, even stuff like managing database resources can be taken care of by RAII, leading to reduced environmental errors that may lead to things like duplicate primary keys being created.

Static analysis tools are okay if it comes to snippets of code changes, but can't tell you much about design flaws. I too often see people making local changes to "fix" the error when they should have given more thought about reorganizing even just the code of that function a bit. The other thing that is popular these days in C++ are generic algorithms. The properties of generic algorithms are known, including the elimination of most range errors. Static analysis doesn't tell you that you should replace your hand-crafted for loop (or thread synchronization) to use a more suitable higher level construct. In Java, that may as well be a good thing, since high level implies efficiency cost in a way C++ generic high level constructs don't.

Comment Re:JAVA FTW (Score 1) 457

I'm currently writing something using Javascript and WebGL. I spent a lot of time actually writing code. But "actually writing code" doesn't make me more productive. I think there's a tendency to conflate productivity with writing code. Certainly, the relationship between writing code and testing/debugging code is also forgotten. I find using templates (and their errors) eliminates the need for a lot of tests, especially those surrounding polymorphic aspects of design. I don't have to run the program in debug and step through if I can get the compiler to do that for me.

In Nature there are neither rewards nor punishments, there are consequences. -- R.G. Ingersoll