Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:I reckon (Score 1) 256

RAII is wrong. It's sloppy. Stop drinking the kool-aid.

How would you know? Judging by our conversation, it's obvious you know nothing about it. You obviously stopped learning C++ long before the 98 standard, or you didn't bother to learn something properly.

I never used any sort of garbage collection or STL classes

You use garbage collection. You just stupidly write code that a machine could do for you because you have gross misunderstanding based on an unwillingness to learn.

Not needed, same as templates

Templates can make code faster than C code. Just compare std::sort to qsort. Templates allow high level optimizations not possible with pointer based "generic" code. Templates aren't needed, but they're better.

Call me when your *nix OS is written in c++ - then we'll talk.

Whatever. The compilers used to build those C Unixes are written in C++. GCC has been compiling as C++ for a while now, but you probably didn't want to know about it either.

same as all the modern build tools, the whole "we have a problem to solve that no language solves, so let's invent yet another language", shit like ruby, the gazillion javascript libraries, etc

We are talking about C++ here, so the whole "let's invent another language" doesn't EVEN apply here. But trust you to not bring up any points of relevance.

Comment Re:Epicycles (Score 1) 256

The great thing about C is that you can quite easily understand all of it. C++ can trip you up easily.

What I find though is that libraries written in C are harder to understand than C++. Compare qsort to std::sort. In qsort, I have to manually pass in sizes, counts and a function pointer. In std::sort, I just need to pass in a begin and end iterator. The "size" and "count" are all worked out for me at compile time, and uses the default "
So yes, you can easily understand C. But you can't easily get the gist of a program written in C.

It is harder to understand C++. But you can easily get the gist of a program written in C++, but without sacrificing performance.

Comment Re:I reckon (Score 1) 256

YOU can't determine that since you don't determine when there are no more references to the code

Yes you can. Most things are not shared pointers, and shouldn't be shared pointers. Most C++ Standard Library objects are decidely NOT shared pointers but use RAII. Get with the times - that was the case since C++98, but apparently you won't bring yourself to accept it. Hell, even in C++98, the "smart pointer" library type was auto_ptr, which is decidely NOT shared, and that's been superseded by unique_ptr, which is NOT shared, which was based on Boost's scoped_ptr, which is NOT shared. Keep staying stuck in your pre-98 knowledge

And you SHOULD write free() every time you write malloc().

Yes, you should, if you're writing malloc and free. But if a compiler can call the equivalent of free for you every time, why stupidly keep doing it yourself? I call "free" every time I "malloc" because I create and/or use types which make that happen automatically. AND THEY DO NOT SHARE REFERENCES. Get that through your head please.

Also, if UI frameworks are a mess, blame the authors.

No, UI frameworks written in C are a mess. Frameworks like Qt are just fine, WITHOUT the use of shared pointers. But, hey, keep ignoring that point because it's inconvenient. Even Linus changed his diving software from GTK to Qt, even though he hates C++. He could not find a UI framework he liked written in C, that's how bad it is.

It should always be possible to know with 100% certainty which piece of code "owns" the resource. . . . Allocate it in one place, use it, free it. Anything else is just begging for problems.

Yet tools like Valgrind exist because that's what C programmers need. In a perfect world, everything would work perfectly. You should be complaining about the world not being perfect.

Even Java runs faster if you expressly call the garbage collector when you're done

Yes, and even better is if I don't even need a garbage collector, especially a mark and sweep garbage collector because I'm NOT using shared resources almost all of the time.

Comment Re:I reckon (Score 1) 256

C++ destructors are deterministic. It isn't that hard of a concept.

Having to write clean up code more than once, ie outside of a destructor, is excessive work. I can write a vector, with one destructor, knowing everywhere the vector is used, its destructor will get called when its scope has ended without me having to write it. Deterministic and an efficient use of my time.

Whereas with malloc, you have to write free every single time afterwards.

Do the maths.

And what about shared ownership? Very common pattern in user interfaces. Look at the mess C UI frameworks are with their manual reference counting.

Seriously, if in this day and age you can't understand that scope based resource management is deterministic, maybe you should seriously consider actually learning the concept.

Comment Re:Agreed. I've moved on. (Score 1) 256

Except Microsoft, Google, Facebook, Intel, Bloomberg, and many other companies are giving it more attention as the standard moves on. C++17 is on track, with all the major compilers having implemented most of the features already. Standardization is almost moving to become a mere formality, and most of the design and implementation testing is done at the compiler level years before the next standard.

As for ECMA-standardized C#, C++ is ISO standardized, and there's no possible patent threat with it.

Comment Re:I reckon (Score 1) 256

You can free up non-critical code allocations early to avoid background gc impacting performance

Nothing in C++ stopping from doing that. That's what scope based resource management gives you automatically. In C++, you allocate in the precise scope you need it and when that scope ends it's freed for you. You don't even have to think about impacting gc performance. You kind of proved my point that a compiler just makes that easier while sacrificing none of your control.

or re-purpose already allocated memory in critical code to reduce overhead

Again, nothing in C++ stopping you from doing that. In fact, move and perfect forwarding makes it even easier to repurpose resources but without sacrificing the deterministic destruction. And you STILL don't have to waste time writing clean up code.

Because in many circumstances you can do it better.

None of yours were examples of that and in fact shows its better to leave it to the compiler because it's a waste of productivity in most cases. And given the amount of access bounds and resource management errors in C code written today, it is a fact that it is not better to leave it to humans.

Comment Re:In Putin's Russia (Score 1) 256

Why shouldn't you use volatile, especially if you're writing hardware interfacing code?

Most of the new C++ stuff actually reduces the "complexity" budget. Type deduction outside of function interfaces greatly simplifies most everyday code. I find using C++11 and 14 and then going back to C++98 or 03 or TR1 actually helped understand the older stuff without much effort.

Comment Re:I reckon (Score 1) 256

Why would we want to do something the compiler can do? There is no bragging rights to stupidly doing what a compiler can do. I can know exactly the scope of some malloc'd buffer, but so can a wrapped type like a vector. Why would I possibly want to waste time writing and testing/valgrinding to make sure every malloc is freed when the compiler can automatically call the destructor for me?

Only idiots brag about doing excessive work.

Comment Re:Not good enough! (Score 1) 256

The fact that the C++ committee still rejected Concepts shows they're not willing to add in any old feature because reasons.

Funny how other languages don't get shit for actually including parallelism, networking, GUI, XML, JSON, etc into their standard library.

At least in C++ if you don't need those libraries, you don't have to still download/install a huge runtime environment, or rely on online package managers that have to be up all the time.

Comment Re:In Putin's Russia (Score 1) 256

Then learn the new features. What's the problem? You learn a new language when one annoys you too much. This is a different issue from C++ altogether. Java 8 has some new features. Learn to use them. Perl 6 has new features. Learn to use them. Javascript, Go, Rust, Swift, whatever - tell me what language doesn't acquire new features over time that you have to learn and maintain?

"I'm too scared to learn new stuff" is a stupid attitude.

Slashdot Top Deals

Life would be so much easier if we could just look at the source code. -- Dave Olson