Forgot your password?

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

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.

Comment: Re:No trouble finding single player games.... (Score 1) 291

by GiganticLyingMouth (#47920799) Attached to: The Growing Illusion of Single Player Gaming

Most of those games you quoted are very old and OP has probably played them all and is looking for something new.

Wasteland 2 comes out this Friday (9/19) and Pillars of Eternity is still in Beta. Unless you've got a time machine that's about as new as it gets.


Why Women Have No Time For Wikipedia 579

Posted by timothy
from the busy-doing-real-stuff dept.
Andreas Kolbe writes Wikipedia is well known to have a very large gender imbalance, with survey-based estimates of women contributors ranging from 8.5% to around 16%. This is a more extreme gender imbalance than even that of Reddit, the most male-dominated major social media platform, and it has a palpable effect on Wikipedia content. Moreover, Wikipedia editor survey data indicate that only 1 in 50 respondents is a mother – a good proportion of female contributors are in fact minors, with women in their twenties less likely to contribute to Wikipedia. Wikimedia Foundation efforts to address this "gender gap" have so far remained fruitless. Wikipedia's demographic pattern stands in marked contrast to female-dominated social media sites like Facebook and Pinterest, where women aged 18 to 34 are particularly strongly represented. It indicates that it isn't lack of time or family commitments that keep women from contributing to Wikipedia – women simply find other sites more attractive. Wikipedia's user interface and its culture of anonymity may be among the factors leading women to spend their online time elsewhere.

Comment: Re:Programming: You're doing it completely wrong (Score 1) 120

lambdas can be faster than say, function pointers, mostly because the compiler can have more information about pointer aliasing. They should be a wash speed-wise relative to loops. Also, you say functors, which can take a few forms; this can be a callable object (e.g. a struct with its operator() overloaded, no templates needed), a stored lambda function, or a std::function object (e.g. as created through std::bind, lambdas, etc). They all look rather different; do you find all of them unreadable? Not all of them require 'enormous' header files

Comment: Re:Templates all over again (Score 1) 427

by GiganticLyingMouth (#47674457) Attached to: Interviews: Ask Bjarne Stroustrup About Programming and C++
Not as many as possible. Use the right tool for the right job, as always. But don't rule out libraries because they use templates -- that's downright silly. Templates are made for writing generic code, which maps very well to libraries. Lastly, I don't claim to be a *good* programmer, but I do at least make an effort to understand the language that I'm using.

Comment: Re:Is the complexity of C++ a practical joke? (Score 1) 427

by GiganticLyingMouth (#47673617) Attached to: Interviews: Ask Bjarne Stroustrup About Programming and C++

Might I ask what you feel to be unpleasant about C++11's additions? Do you have any specific cases in mind?

A lot of people will (and do) use the =delete syntax. Prior to that you would have to declare the method as being private, but this wasn't perfect. Class friend and member functions could still access them, and the errors would only be detected at link time. Alternately you could use boost noncopyable, but you can't always use boost. With the =delete syntax, errors are detected at compile time, and provide some semantic information about your code to anyone reading it.

Also, it's actually 6 implicit functions that compilers generate; you forgot about the copy-assignment and move-assignment operators.

Comment: Re:Templates all over again (Score 1) 427

by GiganticLyingMouth (#47673387) Attached to: Interviews: Ask Bjarne Stroustrup About Programming and C++

Sorry but this is nonsense. Templates aren't any slower than hand-written code. Compilers may have had problems with templates a decade ago, but template support among the major compilers nowadays are very solid and consistent.

You say "many programmers minimize their use of templates, both in their own code and in their use of templated library code" -- are you saying "many" programmers writing C++ don't use boost or the standard library? Because that too is nonsense. Many bad programmers perhaps?

Lastly, partial specialization is very convenient for performing compile time recursion, which is pretty essential to template metaprogramming.

Comment: Re:Multiple Return Types? (Score 1) 427

by GiganticLyingMouth (#47673061) Attached to: Interviews: Ask Bjarne Stroustrup About Programming and C++

When is C++ going to natively support multiple return types? i.e.

float sin, cos, angle; sin, cos := SinCos( angle );

Right now we can use a struct hack, but native support would be appreciated.

You could always just return a tuple, then use tie on the caller side. To use your example,

std::tuple SinCos(float angle) {
return std::make_tuple(sin, cos);

float sin, cos;
std::tie(sin, cos) = SinCos(angle);

Also, your last question isn't really a question, is it?

Comment: Re:Much less should be written in C (Score 1) 637

If you change a private implementation detail in a class, you have to recompile everything which uses the class. This is the opposite of encapsulation.

Yes, that's what the PIMPL idiom is for. Here's a nice introduction to it .

As with most everything, there's a way to solve that problem in C++, it just takes some work and knowledge to know what, when, and how to use it. I do agree that the language is too big though; conceptually, C++ could be broken into 4 distinct components (C, STL, templates, OOP), as each have their own quirks and idioms that don't necessarily carry over well to the other, and some are even Turing complete on their own (ie template metaprogramming)

Comment: Re:Much less should be written in C (Score 1) 637

I'm not quite sure I understand your gripe properly. You're saying that since C++ has classes, and classes are defined in header files, that calling code is dependent on the class because... it's in a header file?

If it bothers you so much, use the PIMPL idiom. Or forward declarations where you can. Or template your calling code and write to static interfaces. You've got plenty of options, you just need to know how to use them. C++ is admittedly a very large (arguably too large) language, which is both it's most compelling feature and it's biggest drawback. You can use it for pretty much everything, but fully grasping the language and knowing when to use what feature takes time. This is partly due to trying to maintain backward compatibility with C, while still incorporating new language features. Because of this hodgepodge, iterative development, some dubious choices have been made. D is meant to take the good parts of C++ and cut out the bad; it is a good idea, and a lot of the foremost C++ experts are D supporters. It's a shame that D will probably never take off.

If you're going to complain about C++, at least use valid complaints. Like about how 2 primary aspects of the language (templates and OOP/dynamic polymorphism) are partly incompatible, or about how there's no dynamic multi-dispatch built in to the language still, or how there's no concepts, or how C++11 async doesn't really give task parallelism. (And yes, there are others, many others). But classes and header files? Cmon.

And yes, the famous, fictional interview...

"There is hopeful symbolism in the fact that flags do not wave in a vacuum." --Arthur C. Clarke