Please create an account to participate in the Slashdot moderation system


Forgot your password?
Slashdot Deals: Prep for the CompTIA A+ certification exam. Save 95% on the CompTIA IT Certification Bundle ×

Comment Re:Very sad - but let's get legislation in place N (Score 1) 706

Oh, sure, they might get a little bad PR, and the stock might slip a little. But that asshole executive who decided security was too costly? It's not his data being stolen, and it's not him who has to deal with it.

While I agree with the overall sentiment, in this specific case the hackers look to have grabbed the full source of all the parent companies' websites, and the CEO's emails... which they recently released.

Comment Re:Incrementing (Score 1) 285

x = x++; It looks okay at first glance,

TBH, it screams "@fixme, sequence points" even at a first glance.

Whenever I see 'sequence points', I want to get all pedantic and point out that the term itself is deprecated as of C++11, in favor of using more precise terminaology concerning memory ordering (and we actually can now, because of the C++11 memory model). But then I refrain.

Comment Re:"NVidia Hopes to Sell"... CUDA (Score 1) 35

That's true in theory; the problem is that OpenCL still feels a few years (or more...) behind CUDA. I have used both, and while OpenCL is undoubtedly the future, CUDA is still by far the better choice for GPGPU today.

The worrying thing is that I've been saying that for the past 5 years, and it hasn't shown any signs of changing. AMD's OpenCL implementation (everything from the drivers to the compiler) are a total crapshoot. With each release they fix one bug, but introduce 1 new one and 1 regression. (completely) innocuous changes in kernel code can make for dramatic swings in the compiled output. All too often AMD's OpenCL still feels like it's at its proof-of-concept phase, and Nvidia (those bastards) haven't released anything OpenCL related since OpenCL 1.1 (which was something like 5 years ago).

OpenCL implementations are too uneven still as well; I have been working with an embedded system lately that has coprocessors and advertises as being OpenCL compatible. The problem is that their implementation is at best incomplete and at worst completely wrong, to the point of not being usable. Maybe in another 5 years OpenCL will be the better choice

Comment Re:Damn... (Score 5, Informative) 494

These neat little theories are always so so convenient to explain why everyone else is inferior. Yet Pakistan elected a woman as prime minister: Perhaps the world is more complicated than these little theories suggest?

... the fine print being that she too was murdered (in 2007), with Al-Qaeda claiming responsibility. Arguing that Pakistan doesn't have a problem with militant islamist groups murdering women is a pretty tough sell

Comment Re:Remind Me Again... (Score 1) 20

Why would anyone want to put a function definition in a class declaration? As I recall, defining a function in the class declaration automatically makes it inline, but that can also be achieved by declaring the function inline.

I also recall that inline functions can considerably increase the size of the resulting executable, so having large inline functions is a bad idea. If you define all your functions in the class declaration you'd end up with a very large program.

Declaring a function inline does not guarentee the function will actually be inlined -- the compiler decides whether it'll be inlined or not, and generally only small functions will be inlined, so if you're using a compiler made within the last decade, large inline functions are not a problem. What inline DOES do is modify the function's linkage specification, but that's a different matter.

Comment Re:one of a kind (Score 1) 641

C++ might not end up being faster, but it certainly has no reason to be slower*. Well-written C++ and C should run at about the same speed. However, C++ has the advantage of allowing you to use high-level constructs when performance isn't as much of an issue.

* this is contingent on your compiler -- if you're using some compiler from a decade ago, some constructs (e.g. templates) may emit shockingly poor code

Comment Re:Very relevent for small target embedded stuff. (Score 1) 641

Off topic: But I really don't know why so many people use C++ for non-embedded. It's perfectly valid for many - maybe most - applications to trade efficiency for safety, so use a different language. Why pick one that accommodates all the power of C then constantly beat on the developers with a giant list of coding guidelines? When the greatest attribute you seek in a developer is pedantry then something's wrong.

C++ is great anywhere you need performance. Numerical computing, scientific computing, image processing, computer vision, machine learning, etc -- all of these benefit greatly from C++, as you can use it as a high-level language in the non-performance critical parts, but at the same time, be able to optimize effectively in the places where it matters.

Comment Re:C is very relevant in 2014, (Score 2) 641

So why isn't there a _standard_ library for safe string handling? (I know there may be several third party libraries) A library could abstract away the management of pointers to chars, things like growing and shrinking storage of the strings, creating string objects, destroying them, etc. without programmer ever touching a raw pointer to memory containing the string data.

Sounds like you're looking for C++ and std::string

Comment Re:C is very relevant in 2014, (Score 1) 641

Actually, it's still possible to have some bugs if you improperly use auto_ptr and shared_ptr, etc, but it's still much better than the classic method of allocation.

Of course, you're not using auto_ptr anymore, right? It's been deprecated in C++11, and there's little to no reason to use it in favor of unique_ptr. auto_ptr was the attempt at implementing unique_ptr semantics prior to having rvalue references as part of the language. As for the possible pitfalls... shared_ptr can still fall prey to cyclical dependencies, but unique_ptr is very good for enforcing ownership semantics.

Comment Re:List the STL? Seriously? (Score 1) 479

Of course, the STL was written by Stepanov before C++ was standardized. What the interviewer probably meant to ask about is the C++ standard library, which is similar but different. Or maybe they really were asking about the STL, in which case I wholeheartedly agree that bullets were dodged.

You might have mail.