8 ms·

All this C++ hatred is weird. If you need to do systems level programming (eg. write a database), and you want to go beyond C's code organization capabilities,

by Maro 16y ago

All this C++ hatred is weird. If you need to do systems level programming (eg. write a database), and you want to go beyond C's code organization capabilities, and you can select a sensible subset of C++, it's a great language, and you get to control all aspects of memory and CPU. We're writing our database(s) in C++, and we're pretty much loving every minute of it, and would not switch to C, Java, Erlang or whatever. Of course we're a startup, so we got to select our own subset, write our own containers, etc: http://github.com/scalien/scaliendb http://github.com/scalien/scaliendb One downside is it's hard to find good C/C++ programmers on the market. The vast majority of applicants cannot complete our first interview filter (removing a characters from a C string and writing an instrusive stack in C++): http://scalien.com/pdf/job.pdf http://scalien.com/pdf/job.pdf

cageface 16y ago
One downside is it's hard to find good C/C++ programmers on the market. It's interesting that C++ is increasingly becoming a niche skill. When I started programming you pretty much had a choice of C++ or VB if you wanted a job. Suits me fine though. A lot of the most interesting work (DSP, kernels, graphics etc) is in C++.
pmjordan 16y ago
I think C++'s popularity comes from the fact that it is essentially a better C. Which parts of it are better than C happen to be a matter of taste and for what you need it. I don't think anyone loves all of C++. But I think there isn't a viable competitor in the "C, but better" space at the moment. Go is probably too high level to be a complete replacement. D is... a weird case. I don't think it stands much of a chance in the market because it's not sufficiently better than C++. Overcoming C++'s momentum is extremely difficult at this point. EDIT: downvoters: if you think I'm trolling, please note that I've written more code in C++ than any other language. I would love a "better C" that's universally better than C++. If you disagree with my points, please elaborate.
- gaius 16y ago
  Curious; what makes ObjC not a viable competitor IYHO? D is doomed by the Phobos/Tango schism, no-one would risk their business on it.
  - pmjordan 16y ago
    Curious; what makes ObjC not a viable competitor? The Objective-C additions just aren't very low-level. They're basically an object runtime library with some syntactic sugar. This is fine for situations where you want something a bit more high level and dynamic[1], but gives you no advantage over C in something like device drivers or programming embedded devices, because you just aren't going to use those features. Minimalistic (optional!) vtable dynamic dispatch is great for these uses, though, and generic programming can be really nice (despite C++'s version in the shape of templates) even for low-level applications. RAII also is really nice. D is doomed by the Phobos/Tango schism, no-one would risk their business on it. If D was that much better, I think a sufficient open-source ecosystem would spring up around at least one of the two libraries that you could realistically use it. As it is, I doubt it would be popular even without the schism. [1] Though in my opinion, most iOS apps would be easier to write in a managed language, especially if you could call out to C/C++. The Obj-C focus is understandable from Apple's point of view though.
    - jimbokun 16y ago
      "Though in my opinion, most iOS apps would be easier to write in a managed language" Maybe, but just as you can not easily dismiss C++ because so many people have written so many successful programs in it, it is difficult to dismiss all of the great software from Apple, and arguably the largest library of software for mobile devices in the App Store, written in Objective C. You point out the resource constraints that make C++ superior to Objective C and other languages for drivers and embedded systems. Similarly, I suspect Objective C gives Apple the right trade offs for writing sophisticated software for mobile devices that is responsive, uses memory effectively, and does not kill battery life.
      - pmjordan 16y ago
- leon_ 16y ago
  > But I think there isn't a viable competitor in the "C, but better" space at the moment. C99 is such a contender imho.
  - pmjordan 16y ago
    C99 is such a contender imho. C99 is a pretty tiny (but welcome) incremental improvement on C. It's also almost entirely orthogonal to C++'s additions. Calling C99 a C++ replacement is pushing it, so you'll need to elaborate on why you think so. I'd be curious about an instance of something you can do better (let alone fundamentally better) in C99 than C++. I can think of plenty of examples of the opposite. C++ sometimes makes me want to tear my hair out, sure[1], but when using pure C(99), I find myself thinking, "this code would be so much more compact in C++." [1] This is usually because either I or someone else tried to be too clever. Otherwise it's because of something C++ does badly that neither C89 nor C99 do at all.
    - leon_ 16y ago
      > Calling C99 a C++ replacement is pushing it I didn't call it a C++ replacement. Just a C89 replacement. "A better C" :) > I'd be curious about an instance of something you can do better (let alone fundamentally better) in C99 than C++. It depends. If you need C++'s syntactic sugar for OOP-style code then yes - C++ is better for that. But if you don't do OO-heavy stuff you can use plain C and get away with less complexity (and more control over the instruction cache, etc). I'm in the lucky position of not needing OO so I get away with using C. And C99 makes my life, compared to the old C89 standard (and the C++ C subset), easier. I can declare variables in the middle of a function (or even within the if statement!). I can initialize structs by its member's names thanks to designated initializers. And the implicit "upcast" from void* to whatever is a blessing (though possible in C89 it isn't available in C++). Oh, and I almost forgot variable length arrays. > but when using pure C(99), I find myself thinking, "this code would be so much more compact in C++." Well, this can go the other way round, too. Just take the right tool for the job.
      - pmjordan 16y ago
- T-hawk 16y ago
  > But I think there isn't a viable competitor in the "C, but better" space at the moment. In the Microsoft ecosystem, C# is this. No, C# isn't OS-independent or hardware-independent or HTTP-server independent. It's not meant to be. C# isn't meant to be an abstractly beautiful language like Lisp or highly performant and portable like raw C. And it's not intended to be part of the LAMP free-software stack; it's intended for a business context that can spend a bit of money to make money. (The C# compiler is actually free, though the IDE isn't and of course the underlying Microsoft OS isn't.) It's C and most of C++ without the foot-shootiness or Java verbosity. For what it is meant to be and for the problem domains that it serves, C# really does make for great productivity. My company and I have used it as our primary language for several years and I like it a lot. Most of the productivity comes from tight integration to external ecosystem elements that make for a useful application, notably MS SQL databases and ASP.NET web servers, all wrapped within a solid IDE. More productivity comes from getting to ignore things like memory allocation and header files which the language just handles for you. Perfect for simply getting things done in a business context when things like price and portability are not a concern. (When they ARE a concern, then by all means use the LAMP stack and C# is not for you.)
  - pmjordan 16y ago
    I think most of what can realistically move to high level languages already has (minus legacy code). Java and VB was the first mainstream wave, C# the second. They're sometimes still lumped in with "systems" programming, but I don't think that's a useful description. As such, when I talk about C++, you can assume I'm excluding situations where a managed, VM'd language would work fine. Calling C# or Java a "better C" is therefore not terribly useful. C is not good at the things C# is good at and vice versa. I use about 6 or 7 different languages on a regular basis, and often the only choice is between C and C++. I'm not sure where you're going with the second paragraph. C and C++ were never popular for general web app development.
  - sedachv 16y ago
    "Perfect for simply getting things done in a business context when things like price and portability are not a concern. (When they ARE a concern, then by all means use the LAMP stack and C# is not for you.)" You've been brainwashed by Microsoft. No one using LAMP cares about price (that much) or portability ('L' is for Linux). Freedom from vendor lock-in (and in this case, a predatory, vengeful vendor) is the biggest practical advantage. Stability and the thing actually fucking working is another (I never enjoyed babysitting Windows servers; do you?). It's also easier to build robust applications with LAMP. Enjoy paying your Microsoft tithe, peasant.
l0nwlf 16y ago
Reminds me of fizzbuzz test : http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz.html http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz....
suraj 16y ago
Looking at your code a bit, it seems you are not using templates, operator overloading, exceptions, STL or std::string. Your test framework also looks custom built (aside: IMO UnitTest++ would have fit you style). I think if you just changed class data to structure and member functions to accept structure pointer, you would get a nice C representation (almost every class I looked at had an Init method). In effect you are using C++ to avoid very small boilerplate code in equivalent C program. No wonder you find C++ pleasurable, you are using it as C with classes! However, if you are working on an existing code base with mix of STL, boost and bunch of other libraries, you would start feeling pain of using C++. In my experience, every library author uses a different subset of C++ and as an application writer, you often have to grapple with the glaringly different idoms in your program. I find boost pleasurable to use; however looking at boost source is enough to melt my mind. Almost everywhere C++ (language and libraries) try to satisfy every corner case and sacrifice usability of common case. e. g. STL iterators (at least I have BOOST_FOREACH to soften them). Ah well this is probably contributing very little to the discussion but I feel better now :) So let me redirect to [C++ FQA](http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/) and let yourself decide whether the points in FQA make sense to you.
- Maro 16y ago
  We do use templates in our containers: https://github.com/scalien/scaliendb/tree/master/src/System/Containers https://github.com/scalien/scaliendb/tree/master/src/System/... Yes, we try to avoid op.overloading, exceptions, and we explicitly don't use the STL, Boost, <any library>. All the code is ours, which is really nice if you're debugging, finding performance problems, etc. It was our experience on previous projects that pulling in outside libraries in a systems level project like a database ends up wasting time (spent in understanding, debugging and optimizing outside code) over just writing what you need. This has proven to be a good call, we fix all bugs, however deep or nasty very quickly. Thanks for the UnitTest++ tip.
  - JoeAltmaier 16y ago
    Folks might accuse you of NIH, but the quality of outside libraries is variable, suitable for a prototype but for shipping code you need control of ALL of it.
js2 16y ago
select a sensible subset of C++, The issue is picking the particular subset and then getting everyone to adhere to it. That works okay in mature engineering shops such as google: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... So I guess I'd say it requires more discipline than, say, Java. (One could similarly argue that writing good Perl requires more discipline that writing good Python.) There's also John Carmack's quip: IMO, good C++ code is better than good C code, but bad C++ can be much, much worse than bad C code. -- http://twitter.com/ID_AA_Carmack/status/26560399301 http://twitter.com/ID_AA_Carmack/status/26560399301
- JoeAltmaier 16y ago
  Hm the Google guide looks like yet another programmers personal expression of style. The "pretty print police" at work. There may be some defensible (i.e. related to actual good programming practice)comments in there, but much is the usual personal preference stuff about braces and capitalization. Different folks internalize different features of C++, for good or bad. To take someone's comfort zone and institutionalize it is arrogant.
  - gjm11 16y ago
    > much is the usual personal preference stuff about braces and capitalization. There's nothing wrong with that; having that stuff in your style guide means that you get more consistent code, which is easier for everyone to read whatever their personal preferences. (General point: Having a rule that says "Everyone must do X rather than Y" doesn't mean claiming, or thinking, that X is better than Y. There's not much to choose between driving on the left side of the road and driving on the right, but it sure is valuable to choose one or the other and stick with it.)
  - yannickt 16y ago
    Actually most of the guide relate to good programming practices, and not just stylistic preferences. Also, I would argue that taking offense at style guidelines (which bring a lot of benefits, especially at a big software company like Google) is unprofessional.
rudiger 16y ago
For those that don't know what it means for a data structure to be "intrusive", here's a link: http://stackoverflow.com/questions/5004162/what-does-it-mean-for-a-data-structure-to-be-intrusive http://stackoverflow.com/questions/5004162/what-does-it-mean...
deleted 16y ago
[deleted]
dkersten 16y ago
I'm curious as to why you wrote your own containers instead of using the C++ Standard Library, Boost, EASTL or any of the other existing container libraries. Care to elaborate? Eg, if performance or fine-grained control over memory is an issue, take a look at EASTL, which EA use in their games (and is designed to be suitable for both PC's and consoles). They are also extremely stable and well tested. I've never tried to find C++ programmers on the market, but I do seem to come accross fewer and fewer C++ programmers now. I use a lot of C++ myself (amongst other languages, including Clojure, Java, Python and recently SML). I think having learnt it long before becoming a professional programmer may have given me a kind of attachment to it, but I actually enjoy using it (most of the time, I do often wish it did things differently or supported features I see in languages like ML or Lisp derivitives). As for your interview question, the first seems almost trivial. The second, an intrusive stack, isn't very hard either [1]. I'm surprised that most applicants have trouble with them! [1] Heres one I slapped together in ~5 minutes (no comments, only tested by running that code, etc etc): https://gist.github.com/827619 https://gist.github.com/827619
- agazso 16y ago
  (Another author here) The basic issue is that we didn't want to include external libraries, because it's a pain to debug, pain to build on multiple platforms and there are licensing issues. Also we don't use so many datastructures, so we rolled our own and we are happy with them. For example we have an intrusive treemap, that has a function for returning the middle of a sorted key which is useful when you want to split a keyspace into two. Not sure if any of STL/Boost supports that. Your solutions looks good, you are hired! ;) Seriously, we know that it is not that hard, but still the applicants have problems with it.
  - dkersten 16y ago
    The C++ standard library shouldn't cause any problems on non-embedded platforms, including phones that support C++. Boost _may_ be a bit more tricky, though most of it is header-only, so it depends on the compiler more than the platforms (but if you use g++, there shouldn't be any issues). As for licensing, STL and Boost are both released under very unrestrictive licenses, similar to the C++ runtimes, so they won't cause you any licensing issues. Not too sure what license EASTL is released under. I know its an unrestricitve license, but don't know about the exact terms, so it may or may not be suitable. Sure, obviously for niche tasks a general library may not perform as well as a container custom-made for the task at hand. That certainly is a legitimate reason to roll your own (though, if it were me, I would make my containers STL compatible, similarly to how Boost is STL compatible, that way you can mix and match between standard containers and custom ones and easily convert between them (eg, by using compatible iterators)). Regarding applicants, I am just as surprised as you are. I guess I didn't notice how much C++ is diminishing in industry (outside of its niche areas, anyway). PS: You're database does look interesting. May have to keep an eye on it.
chollida1 16y ago
> and writing an instrusive stack in C++) What is an instrusive stack?
- roel_v 16y ago
  It's explained in the link.
  - deleted 16y ago
    [deleted]
  - chollida1 16y ago
    Thanks;) I guess I was thrown off by the typo and was looking for something else.
GrooveStomp 16y ago
The remove_char function was fun to write, and I found a bug in my first implementation! The Intrusive Stack problem; however, is confusing to read. I searched for a description of what an intrusive stack is on DuckDuckGo, and the first result was for the Scalien job application. Further down on the page (through what appears to be several quasi-related links) I found a Boost article on intrusive containers which explained the idea much more clearly. After reading the Boost description, then re-reading the Scalien description another 3 or 4 times, I'm not comfortable to write an intrusive stack. Are you sure applicants aren't failing because the application problem for the intrusive stack is written in a confusing manner?
- GrooveStomp 16y ago
  Edit: "I'm now comfortable to write an intrusive stack." I mispelled it as "not" by accident. I tried editing the post, but edit functionality doesn't appear to be working correctly.
- dkersten 16y ago
  "Are you sure applicants aren't failing because the application problem for the intrusive stack is written in a confusing manner?" I don't know, its very possible. I found the application problem very easy to understand and writing an intrusive stack is really easy, so unless I'm very disconnected from the "average applicant", who apparently 1) isn't very good at C++ and 2) doesn't know how to implement common data structures, the problem must be with the application.
joe_the_user 16y ago
"...you can select a sensible subset of C++" I love programming in a sensible subset of C++ too. The problem is that C++ has long history and when it began, many programmers had erroneous ideas about OO - some skipped it completely, some built absurdly deep inheritance trees, some engaged in ridiculous tricks to stay within "doctrine" (remember a fellow who had a pointer-member to the same object in a parent and a child class just avoid something about down-casting). So from this history, there's a lot of really bad C++ code "out there". And just much, when you take two code bases or two groups of programs, each happy with their different sensible subset of C++ and combine them, without being careful, you also wind-up with a hellish mess.

by Maro 16y ago

cageface 16y ago

One downside is it's hard to find good C/C++ programmers on the market. It's interesting that C++ is increasingly becoming a niche skill. When I started programming you pretty much had a choice of C++ or VB if you wanted a job. Suits me fine though. A lot of the most interesting work (DSP, kernels, graphics etc) is in C++.

pmjordan 16y ago

I think C++'s popularity comes from the fact that it is essentially a better C. Which parts of it are better than C happen to be a matter of taste and for what you need it. I don't think anyone loves all of C++. But I think there isn't a viable competitor in the "C, but better" space at the moment. Go is probably too high level to be a complete replacement. D is... a weird case. I don't think it stands much of a chance in the market because it's not sufficiently better than C++. Overcoming C++'s momentum is extremely difficult at this point. EDIT: downvoters: if you think I'm trolling, please note that I've written more code in C++ than any other language. I would love a "better C" that's universally better than C++. If you disagree with my points, please elaborate.

gaius 16y ago
Curious; what makes ObjC not a viable competitor IYHO? D is doomed by the Phobos/Tango schism, no-one would risk their business on it.
- pmjordan 16y ago
  Curious; what makes ObjC not a viable competitor? The Objective-C additions just aren't very low-level. They're basically an object runtime library with some syntactic sugar. This is fine for situations where you want something a bit more high level and dynamic[1], but gives you no advantage over C in something like device drivers or programming embedded devices, because you just aren't going to use those features. Minimalistic (optional!) vtable dynamic dispatch is great for these uses, though, and generic programming can be really nice (despite C++'s version in the shape of templates) even for low-level applications. RAII also is really nice. D is doomed by the Phobos/Tango schism, no-one would risk their business on it. If D was that much better, I think a sufficient open-source ecosystem would spring up around at least one of the two libraries that you could realistically use it. As it is, I doubt it would be popular even without the schism. [1] Though in my opinion, most iOS apps would be easier to write in a managed language, especially if you could call out to C/C++. The Obj-C focus is understandable from Apple's point of view though.
  - jimbokun 16y ago
    "Though in my opinion, most iOS apps would be easier to write in a managed language" Maybe, but just as you can not easily dismiss C++ because so many people have written so many successful programs in it, it is difficult to dismiss all of the great software from Apple, and arguably the largest library of software for mobile devices in the App Store, written in Objective C. You point out the resource constraints that make C++ superior to Objective C and other languages for drivers and embedded systems. Similarly, I suspect Objective C gives Apple the right trade offs for writing sophisticated software for mobile devices that is responsive, uses memory effectively, and does not kill battery life.
    - pmjordan 16y ago
leon_ 16y ago
> But I think there isn't a viable competitor in the "C, but better" space at the moment. C99 is such a contender imho.
- pmjordan 16y ago
  C99 is such a contender imho. C99 is a pretty tiny (but welcome) incremental improvement on C. It's also almost entirely orthogonal to C++'s additions. Calling C99 a C++ replacement is pushing it, so you'll need to elaborate on why you think so. I'd be curious about an instance of something you can do better (let alone fundamentally better) in C99 than C++. I can think of plenty of examples of the opposite. C++ sometimes makes me want to tear my hair out, sure[1], but when using pure C(99), I find myself thinking, "this code would be so much more compact in C++." [1] This is usually because either I or someone else tried to be too clever. Otherwise it's because of something C++ does badly that neither C89 nor C99 do at all.
  - leon_ 16y ago
    > Calling C99 a C++ replacement is pushing it I didn't call it a C++ replacement. Just a C89 replacement. "A better C" :) > I'd be curious about an instance of something you can do better (let alone fundamentally better) in C99 than C++. It depends. If you need C++'s syntactic sugar for OOP-style code then yes - C++ is better for that. But if you don't do OO-heavy stuff you can use plain C and get away with less complexity (and more control over the instruction cache, etc). I'm in the lucky position of not needing OO so I get away with using C. And C99 makes my life, compared to the old C89 standard (and the C++ C subset), easier. I can declare variables in the middle of a function (or even within the if statement!). I can initialize structs by its member's names thanks to designated initializers. And the implicit "upcast" from void* to whatever is a blessing (though possible in C89 it isn't available in C++). Oh, and I almost forgot variable length arrays. > but when using pure C(99), I find myself thinking, "this code would be so much more compact in C++." Well, this can go the other way round, too. Just take the right tool for the job.
    - pmjordan 16y ago
T-hawk 16y ago
> But I think there isn't a viable competitor in the "C, but better" space at the moment. In the Microsoft ecosystem, C# is this. No, C# isn't OS-independent or hardware-independent or HTTP-server independent. It's not meant to be. C# isn't meant to be an abstractly beautiful language like Lisp or highly performant and portable like raw C. And it's not intended to be part of the LAMP free-software stack; it's intended for a business context that can spend a bit of money to make money. (The C# compiler is actually free, though the IDE isn't and of course the underlying Microsoft OS isn't.) It's C and most of C++ without the foot-shootiness or Java verbosity. For what it is meant to be and for the problem domains that it serves, C# really does make for great productivity. My company and I have used it as our primary language for several years and I like it a lot. Most of the productivity comes from tight integration to external ecosystem elements that make for a useful application, notably MS SQL databases and ASP.NET web servers, all wrapped within a solid IDE. More productivity comes from getting to ignore things like memory allocation and header files which the language just handles for you. Perfect for simply getting things done in a business context when things like price and portability are not a concern. (When they ARE a concern, then by all means use the LAMP stack and C# is not for you.)
- pmjordan 16y ago
  I think most of what can realistically move to high level languages already has (minus legacy code). Java and VB was the first mainstream wave, C# the second. They're sometimes still lumped in with "systems" programming, but I don't think that's a useful description. As such, when I talk about C++, you can assume I'm excluding situations where a managed, VM'd language would work fine. Calling C# or Java a "better C" is therefore not terribly useful. C is not good at the things C# is good at and vice versa. I use about 6 or 7 different languages on a regular basis, and often the only choice is between C and C++. I'm not sure where you're going with the second paragraph. C and C++ were never popular for general web app development.
- sedachv 16y ago
  "Perfect for simply getting things done in a business context when things like price and portability are not a concern. (When they ARE a concern, then by all means use the LAMP stack and C# is not for you.)" You've been brainwashed by Microsoft. No one using LAMP cares about price (that much) or portability ('L' is for Linux). Freedom from vendor lock-in (and in this case, a predatory, vengeful vendor) is the biggest practical advantage. Stability and the thing actually fucking working is another (I never enjoyed babysitting Windows servers; do you?). It's also easier to build robust applications with LAMP. Enjoy paying your Microsoft tithe, peasant.

l0nwlf 16y ago

Reminds me of fizzbuzz test : http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz.html http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz....

suraj 16y ago

Looking at your code a bit, it seems you are not using templates, operator overloading, exceptions, STL or std::string. Your test framework also looks custom built (aside: IMO UnitTest++ would have fit you style). I think if you just changed class data to structure and member functions to accept structure pointer, you would get a nice C representation (almost every class I looked at had an Init method). In effect you are using C++ to avoid very small boilerplate code in equivalent C program. No wonder you find C++ pleasurable, you are using it as C with classes! However, if you are working on an existing code base with mix of STL, boost and bunch of other libraries, you would start feeling pain of using C++. In my experience, every library author uses a different subset of C++ and as an application writer, you often have to grapple with the glaringly different idoms in your program. I find boost pleasurable to use; however looking at boost source is enough to melt my mind. Almost everywhere C++ (language and libraries) try to satisfy every corner case and sacrifice usability of common case. e. g. STL iterators (at least I have BOOST_FOREACH to soften them). Ah well this is probably contributing very little to the discussion but I feel better now :) So let me redirect to [C++ FQA](http://yosefk.com/c++fqa/ http://yosefk.com/c++fqa/) and let yourself decide whether the points in FQA make sense to you.

Maro 16y ago
We do use templates in our containers: https://github.com/scalien/scaliendb/tree/master/src/System/Containers https://github.com/scalien/scaliendb/tree/master/src/System/... Yes, we try to avoid op.overloading, exceptions, and we explicitly don't use the STL, Boost, <any library>. All the code is ours, which is really nice if you're debugging, finding performance problems, etc. It was our experience on previous projects that pulling in outside libraries in a systems level project like a database ends up wasting time (spent in understanding, debugging and optimizing outside code) over just writing what you need. This has proven to be a good call, we fix all bugs, however deep or nasty very quickly. Thanks for the UnitTest++ tip.
- JoeAltmaier 16y ago
  Folks might accuse you of NIH, but the quality of outside libraries is variable, suitable for a prototype but for shipping code you need control of ALL of it.

js2 16y ago

select a sensible subset of C++, The issue is picking the particular subset and then getting everyone to adhere to it. That works okay in mature engineering shops such as google: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... So I guess I'd say it requires more discipline than, say, Java. (One could similarly argue that writing good Perl requires more discipline that writing good Python.) There's also John Carmack's quip: IMO, good C++ code is better than good C code, but bad C++ can be much, much worse than bad C code. -- http://twitter.com/ID_AA_Carmack/status/26560399301 http://twitter.com/ID_AA_Carmack/status/26560399301

JoeAltmaier 16y ago
Hm the Google guide looks like yet another programmers personal expression of style. The "pretty print police" at work. There may be some defensible (i.e. related to actual good programming practice)comments in there, but much is the usual personal preference stuff about braces and capitalization. Different folks internalize different features of C++, for good or bad. To take someone's comfort zone and institutionalize it is arrogant.
- gjm11 16y ago
  > much is the usual personal preference stuff about braces and capitalization. There's nothing wrong with that; having that stuff in your style guide means that you get more consistent code, which is easier for everyone to read whatever their personal preferences. (General point: Having a rule that says "Everyone must do X rather than Y" doesn't mean claiming, or thinking, that X is better than Y. There's not much to choose between driving on the left side of the road and driving on the right, but it sure is valuable to choose one or the other and stick with it.)
- yannickt 16y ago
  Actually most of the guide relate to good programming practices, and not just stylistic preferences. Also, I would argue that taking offense at style guidelines (which bring a lot of benefits, especially at a big software company like Google) is unprofessional.

rudiger 16y ago

For those that don't know what it means for a data structure to be "intrusive", here's a link: http://stackoverflow.com/questions/5004162/what-does-it-mean-for-a-data-structure-to-be-intrusive http://stackoverflow.com/questions/5004162/what-does-it-mean...

deleted 16y ago

[deleted]

dkersten 16y ago

I'm curious as to why you wrote your own containers instead of using the C++ Standard Library, Boost, EASTL or any of the other existing container libraries. Care to elaborate? Eg, if performance or fine-grained control over memory is an issue, take a look at EASTL, which EA use in their games (and is designed to be suitable for both PC's and consoles). They are also extremely stable and well tested. I've never tried to find C++ programmers on the market, but I do seem to come accross fewer and fewer C++ programmers now. I use a lot of C++ myself (amongst other languages, including Clojure, Java, Python and recently SML). I think having learnt it long before becoming a professional programmer may have given me a kind of attachment to it, but I actually enjoy using it (most of the time, I do often wish it did things differently or supported features I see in languages like ML or Lisp derivitives). As for your interview question, the first seems almost trivial. The second, an intrusive stack, isn't very hard either [1]. I'm surprised that most applicants have trouble with them! [1] Heres one I slapped together in ~5 minutes (no comments, only tested by running that code, etc etc): https://gist.github.com/827619 https://gist.github.com/827619

agazso 16y ago
(Another author here) The basic issue is that we didn't want to include external libraries, because it's a pain to debug, pain to build on multiple platforms and there are licensing issues. Also we don't use so many datastructures, so we rolled our own and we are happy with them. For example we have an intrusive treemap, that has a function for returning the middle of a sorted key which is useful when you want to split a keyspace into two. Not sure if any of STL/Boost supports that. Your solutions looks good, you are hired! ;) Seriously, we know that it is not that hard, but still the applicants have problems with it.
- dkersten 16y ago
  The C++ standard library shouldn't cause any problems on non-embedded platforms, including phones that support C++. Boost _may_ be a bit more tricky, though most of it is header-only, so it depends on the compiler more than the platforms (but if you use g++, there shouldn't be any issues). As for licensing, STL and Boost are both released under very unrestrictive licenses, similar to the C++ runtimes, so they won't cause you any licensing issues. Not too sure what license EASTL is released under. I know its an unrestricitve license, but don't know about the exact terms, so it may or may not be suitable. Sure, obviously for niche tasks a general library may not perform as well as a container custom-made for the task at hand. That certainly is a legitimate reason to roll your own (though, if it were me, I would make my containers STL compatible, similarly to how Boost is STL compatible, that way you can mix and match between standard containers and custom ones and easily convert between them (eg, by using compatible iterators)). Regarding applicants, I am just as surprised as you are. I guess I didn't notice how much C++ is diminishing in industry (outside of its niche areas, anyway). PS: You're database does look interesting. May have to keep an eye on it.

chollida1 16y ago

> and writing an instrusive stack in C++) What is an instrusive stack?

roel_v 16y ago
It's explained in the link.
- deleted 16y ago
  [deleted]
- chollida1 16y ago
  Thanks;) I guess I was thrown off by the typo and was looking for something else.

GrooveStomp 16y ago

The remove_char function was fun to write, and I found a bug in my first implementation! The Intrusive Stack problem; however, is confusing to read. I searched for a description of what an intrusive stack is on DuckDuckGo, and the first result was for the Scalien job application. Further down on the page (through what appears to be several quasi-related links) I found a Boost article on intrusive containers which explained the idea much more clearly. After reading the Boost description, then re-reading the Scalien description another 3 or 4 times, I'm not comfortable to write an intrusive stack. Are you sure applicants aren't failing because the application problem for the intrusive stack is written in a confusing manner?

GrooveStomp 16y ago
Edit: "I'm now comfortable to write an intrusive stack." I mispelled it as "not" by accident. I tried editing the post, but edit functionality doesn't appear to be working correctly.
dkersten 16y ago
"Are you sure applicants aren't failing because the application problem for the intrusive stack is written in a confusing manner?" I don't know, its very possible. I found the application problem very easy to understand and writing an intrusive stack is really easy, so unless I'm very disconnected from the "average applicant", who apparently 1) isn't very good at C++ and 2) doesn't know how to implement common data structures, the problem must be with the application.

joe_the_user 16y ago

"...you can select a sensible subset of C++" I love programming in a sensible subset of C++ too. The problem is that C++ has long history and when it began, many programmers had erroneous ideas about OO - some skipped it completely, some built absurdly deep inheritance trees, some engaged in ridiculous tricks to stay within "doctrine" (remember a fellow who had a pointer-member to the same object in a parent and a child class just avoid something about down-casting). So from this history, there's a lot of really bad C++ code "out there". And just much, when you take two code bases or two groups of programs, each happy with their different sensible subset of C++ and combine them, without being careful, you also wind-up with a hellish mess.