• (cs)

    "Err, wait, do you meant C-sharp? Because I've worked quote a bit with the .NET Frame—"

  • Neeneko (unregistered) in reply to Capt. Obvious
    Capt. Obvious:
    Why wouldn't that compile in C++? malloc is valid. sizeof ( XXXX) is valid. structs are valid.

    It may not be very OO, but it should be valid compilation wise (unless it should read "sizeof(S)" as opposed to "sizeof ( struct S )"

    C++ does not allow you to assign without a cast.

    so you get:

    g++ test.cpp -o test test.cpp: In function 'int main(int, char**)': test.cpp:12: error: invalid conversion from 'void*' to 'S*' make: *** [test] Error 1

    While in C it is acceptable (in fact, correct) to assign a void* to another pointer without cast.

  • pbhj (unregistered) in reply to Anonymous Cowherd

    Um, C is procedural, C++ is OO .. or that appears to be the intention from the design of them.

    Javascript and Java are pretty different too .. did I miss your joke???

  • anonymous (unregistered) in reply to Code Slave

    right, and if you actually read that AT&T Research PDF you link to...

    I quote:

    B.2 C/C++ Compatibility With minor exceptions, C++ is a superset of C (meaning C89, defined by ISO/IEC 9899:1990). Most differences stem from C++’s greater emphasis on type checking. Well-written C programs tend to be C++ programs as well. A compiler can diagnose every difference between C++ and C.

  • Dave (unregistered) in reply to JoJo

    you know, OKCupid runs and develops its webserver entirely in C. It's incredibly efficient and stable and great. Oh and wait what language is Apache again?

  • Cheong (unregistered)

    I ceased to call these WTF long ago. Rather, I'd call them "the sad reality".

  • Cheong (unregistered) in reply to Steve
    Steve:
    #1 isn't really a WTF if they're building C/C++ modules for OKWS http://okws.org
    #1 isn't really a WTF if they're early adapter of WWW age and have a website written in C CGI either.
  • Neeneko (unregistered) in reply to Dave
    Dave:
    you know, OKCupid runs and develops its webserver entirely in C. It's incredibly efficient and stable and great. Oh and wait what language is Apache again?

    I was wondering if someone was going to bring up that example ^_^

    More websites are written in c cgi then people probably think. It isn't generally recommended since the skill set is uncommon but you can do some pretty powerful (and fast) stuff when you don't have to worry about all the extra layers and simplifications that web-centric languages have.

  • Kef Schecter (unregistered) in reply to Smash King
    Smash King:
    I disagree. I have never used or studied C++, but I often see C++ WTFs here and can fully understand them. It would take me just a few hours to grasp the differences, receive the official title of CPP programmer and start on the new project.

    Then you greatly underestimate how C++ really differs from C. C++ is monstrously complicated compared to C and getting it right takes much, much longer than "a few hours" even coming from a C background. I know this because I learned C++ from a C background myself.

    Prior experience with OOP reduces the learning curve, obviously, but some things such as exception safety can be pretty difficult to grasp. I remember I picked up the book Exceptional C++ some years ago thinking I already knew everything and came away with the realization that I knew nothing.

    • Kef
  • JSmith (unregistered) in reply to Divide by Zero
    From the IBM document in your own link
    An excerpt from the book The C++ Programming Language, Special Edition by Bjarne Stroustrup is most certainly not an IBM document!
  • Cpt (unregistered) in reply to JoJo
    JoJo:
    DeLos:
    I always put puppies and kittens on my resume ... who doesn't love puppies and kittens?!?

    I tried that, but it was hard to get them in the envelope. Plus the staples never held them very securely.

    You should try glueing them on, or one of those pitbull-clamps.

  • Dave G. (unregistered) in reply to Kef Schecter
    Kef Schecter:
    Smash King:
    I disagree. I have never used or studied C++, but I often see C++ WTFs here and can fully understand them. It would take me just a few hours to grasp the differences, receive the official title of CPP programmer and start on the new project.

    Then you greatly underestimate how C++ really differs from C. C++ is monstrously complicated compared to C and getting it right takes much, much longer than "a few hours" even coming from a C background. I know this because I learned C++ from a C background myself.

    Prior experience with OOP reduces the learning curve, obviously, but some things such as exception safety can be pretty difficult to grasp. I remember I picked up the book Exceptional C++ some years ago thinking I already knew everything and came away with the realization that I knew nothing.

    • Kef

    +1.

    I've done exactly the same thing. Long C background but have been learning and using C++ over the last year and a half or so.

    The Scott Meyers books on C++ really opened my eyes to how hugely complicated C++ is and how thoroughly little I knew about it, despite writing C for many years and studying C++ seriously.

    I think a C programmer would be able to mostly follow along with C++ code (given a small primer on the STL and maybe template syntax), but in no way would that C programmer be able to write good, safe code that works properly without a fair amount of actual C++ programming experience.

    Take for instance virtual destructors. If you have a derived class where either the parent or the child class either does not declare any destructor or does NOT declare its destructor virtual, the child's destructor is never called when the object is destroyed. You receive no warnings about this behaviour.

    This tiny, absolutely puny little detail will leave your program riddled with serious, impossible to find bugs and resource leaks. You need to know specifically of this behvaiour before you can fix it.

    This is merely one example of probably thousands of such tiny little details of complexity that a C programmer would simply have no clue about - details which will render your programs utterly useless if you don't know about them. And even if you know about them, there are so many things to remember that you WILL forget some of them from time to time. Even experts can write C++ code that is just wrong.

    A C++ programmer should be able to write decent C. On the othe rhand, I would not expect a C programmer to write even half-decent C++.

  • Procedural (unregistered) in reply to BCS
    BCS:
    I seem to recall someone giving advice on résumés and pointing out that some jobs get like 100x more applicant than they have positions and just to cut it down, some of those résumés get trashed in the first pass at a rate of about 1 a second. Never done it, never seen it done but if you have more résumés than you even have time to skim what else are you going to do?

    Ridiculous. That`s why HR exists. I think the CIA guy was testing the candidate on his ability to deal with adversity in a partially-understood context. The candidate failed. The arrows obviously never mattered.

  • Dave G. (unregistered) in reply to Procedural
    Procedural:
    Ridiculous. That`s why HR exists. I think the CIA guy was testing the candidate on his ability to deal with adversity in a partially-understood context. The candidate failed. The arrows obviously never mattered.

    I've got it. The CIA guy was actually doing a drop for a spy, and the suggestions about the arrows were a code phrase used to identify the correct person to receive the microfilm.

    Had the OP been savvy enough to detect this obvious spy behaviour, he might have landed his hands on something awesome, which he could be sharing with us now instead.

    I submit that the arrows matter tremendously.

  • Vollhorst (unregistered) in reply to pbhj
    pbhj:
    Um, C is procedural, C++ is OO .. or that appears to be the intention from the design of them.

    Javascript and Java are pretty different too .. did I miss your joke???

    Wrong. C++ only allows OO but can also be as "old school" as C if you want to.

  • fresch (unregistered) in reply to Neeneko
    Neeneko:
    Ugh. That old faq. yeah, real great perspective there. It makes me wonder how much C this person _really_ programmed in vs 'I could do this better!'. Claiming he needed to develop a whole new language to get generic programming, OOP, and data abstraction really makes me wonder how he was using C since it has all of those things. C++ makes these things easier (most of the time) and safer (pretty much all of the time) but it does not add any actual new expressive power.

    And of course all the "C is never better then C++ under any circumstances" are just dripping with lack of perspective. To this day C++ does not have the flexibility (without lots of extra code) of C in things like polymorphism. Runtime modification of classes in C++ has always been a pain unless you add wrapper syntax at which point you are back to the C method but with more code (and symbol table clutter).

    Oh, sure I could drive an old Model T, where I have to use a crank to manually start the engine... but I'd much rather drive a Prius that not only has an automatic starter, but also has other really useful features over that Model T.

    Or I could just walk everywhere and dream about how wonderful it would be if there just was a way to get there faster, more comfortable and less exhausting.

    So you like C and I like C++.

  • Dablador (unregistered) in reply to JoJo

    Next time, add the last time line in the 'additional information' section down the bottom of your resume and hit in: "On my free time I sit on my father's right side passing down judgements on the living and the dead."

    Works like a miracle.

  • Simon (unregistered) in reply to testx

    Im my job I have to write documentation as well as software. I wouldn't hire someone with a poorly formatted CV, it you can't be bothered to make something that important look nice, will you be bothered to format a document properly?

    I'm not talking about 'I don't like that style', but things that make it harder to read and harder to skim for the details.

    Same goes for poor grammer and spelling. I've probably made a mistake or two in this post, but it's not something that I'm trying to use to get a job!

  • grammernazee (unregistered)

    The real WTF is Alex's grammar:

    "a certain founded-and-headquartered-in-the-Netherlands electronics company was hiring ". OK, if you are going to use this disturbingly convoluted adjectival construction, it is correct to hyphenate it, but this is supposed to be English, not German or Jedi. I'm a confused-by-your-use-of-verbal-clauses person...

  • Médinoc (unregistered) in reply to Steve
    Steve:
    Argh! I hate people who keep claiming that because C++ is not a proper subset of C that therefore they are completely different languages.

    Firstly, are we talking about K&R C, ANSI C, or C99(doubtful)? What code would you write in ANSI C that you would actually want to write that wouldn't compile in C++?

    Yes you can write crap C code that a C++ compiler won't compile, but why would you want to?

    For all intensive porpoises C++ is a superset of C.

    This is ANSI C: http://www.developpez.net/forums/m2880445-30/ And it doesn't compile in C++.

    Also, the errata section of the K&R2 now tells not to put an explicit cast between a pointer and a call to malloc(), which means that an officially recommended ANSI C convention won't compile in C++.

    About the 3 : Yes, patenting in the states has become a WTF.

  • Steve (unregistered) in reply to Médinoc
    Médinoc:
    Steve:
    Argh! I hate people who keep claiming that because C++ is not a proper subset of C that therefore they are completely different languages.

    Firstly, are we talking about K&R C, ANSI C, or C99(doubtful)? What code would you write in ANSI C that you would actually want to write that wouldn't compile in C++?

    Yes you can write crap C code that a C++ compiler won't compile, but why would you want to?

    For all intensive porpoises C++ is a superset of C.

    This is ANSI C: http://www.developpez.net/forums/m2880445-30/ And it doesn't compile in C++.

    Also, the errata section of the K&R2 now tells not to put an explicit cast between a pointer and a call to malloc(), which means that an officially recommended ANSI C convention won't compile in C++.

    About the 3 : Yes, patenting in the states has become a WTF.

    Seriously that has to be one of the lamest, won't compile in C++ examples I've ever seen. Simply replace the #ifdef with #ifdef __cplusplus #define class _class #define template _template #define new _new #endif

    And OMG, minus the malloc issue it will compile. And the malloc casting thing is mainly a non issue. Regardless, the argument is whether C++ is a proper superset of ANSI C. Which we all know it isn't, but the porpoises are pretty sure that 99% of the time it is.

    C99 does actually have features not in C++.

  • ais523 (unregistered) in reply to Anonymous Cowherd
    Anonymous Cowherd:
    dubbreak:
    C++ is a proper superset of C.

    Incorrect. There are all kinds of things that are legal in C that are not legal in C++. void * conversions are the obvious example. C++'s compatibility with C is more or less limited to making sure you can use C headers and libraries in programs without any difficulty; running non-trivial C code through a compiler as C++ will generally not work.

    It's possible to deliberately write a program so as to be simultaneously valid C and C++. Doing this directly leads to a program which is bad style in C and very bad style in C++; however, it's possible to make it good C style (but not good C++ style) by using macros or similar to wrap around the differences. Unfortunately, that makes it harder to read. So choosing one and sticking to it is usually better.

  • ais523 (unregistered) in reply to Steve
    Steve:
    Metalehad:
    To be fair - why would a C developer write code that compiled in both languages? C is still in heavy use in embeded applications right now, and there is no need to go to C++ in the future anyway. Why would a person spend a bunch of time making it cross-language?

    Generally (although I admit not always) if a C programmer is writing good C it will just work in C++. For the malloc example above the C Programming Language (2nd ed, I can't find my first edition to see if it has changed), says that you should explicitly cast malloc. If you do that then the code becomes valid C++ code also.

    There's a reason it says that, which is that when K&R2 was written, the authors didn't have a C89 compiler (due to the standard only just having come out), so they had to use a C++ compiler instead. Many programmers consider unnecessary casts to be bad style because they hide compiler warnings (forgetting to include <stdlib.h> is a somewhat common mistake, and will often result in code that works on a 32-bit system but not on a 64-bit system), and take up space for no reason.

  • ais523 (unregistered) in reply to Steve
    Steve:
    Franz Kafka:
    fred:
    Neeneko:
    Though that is another difference... arithmetic on void pointers doesn't work in C++. So C programs that do raw memory stuff tend to have to be rewritten by casting all the void* to unsigned long pointers (and then pray that u32s are the right size).
    This is why Jesus invented uintptr_t.

    Nah, Knuth gave us char*, which is almost always size 1.

    Almost never :-), sizeof(char) perhaps?

    sizeof(char) is 1 by definition. However, the smiley implies that you may have known that already...

    Besides, char* is generally quite a bit larger than char; 4's a common value for the sizeof char*, although I've seen both 2 and 8 before, and there may be weirder values out there.

  • José Reis (unregistered) in reply to JoJo

    LOL

  • IByte (unregistered)
    David:
    "Just look at it," she responded, "it's everything, all around. For example, you used dots for your bullet points and he has these nice arrows."
    And if that's not bad enough, to help this kind of people in their quest for unreasonable grounds for rejection, on several job search sites you can upload your resume as a MS Word file, which will then be parsed by the web site, not exactly preserving formatting. That shouldn't really matter, of course, unless you apply with people like this.

    (BTW, for someone in the Intelligence business, she doesn't appear to be acting very intelligently...)

    -- IByte (looking for a non-WTF job)

  • (cs) in reply to Hells Bells
    Hells Bells:
    Good God Man!!! How can a one page resume even begin to outline what a good candidate has done in their career. I agree resume shouldn't be too long, but one page is a bit short, isn't it?
    Every essay I have ever read on getting hired, plus my Business and Professional Speaking class in college, have recommended that you not go beyond one page on your resume. A resume isn't an interview; it's a request for an interview. The details can come out in the interview.
    Hells Bells:
    That's a bit of a problem, seeing as one of those points wasn't Contact Details.
    You don't need to see contact details in the first three to five seconds. There will be time enough for that on the second pass through the stack.
    Hells Bells:
    I find it strange that someone who (presumably) works in IT would shrug off a 66% time increase in reading (ie taking five secs instead of 3). Over 100 Resumes, this makes more than 3 minute difference. Over 1000 Resumes this makes more than 33 minutes difference.
    I wasn't the one who set the initial 3 second figure, and I see no reason for it to become an industry standard for resume perusal. It's a randomly grabbed figure being used by the two priors in the discussion to make a point about quick scans.
  • (cs) in reply to Leak

    [quote user="Leak"] Ewww... if anything, that should be "puppies with ketchup". Just try eating one without ketchup...

    Barbarian -- everyone knows it's mustard on puppies and barbecue sauce on kittens.

  • Chris G (unregistered)

    In a certain POSIX real-time processng book I have one comment that sticks in my mind is that becuase of virtual function pointers inherent in C++, it isn't a true realtime language. Using C allows a predictable control flow that can be evaluated.

    Just thought I'd add to the already growing C differences.

  • (cs) in reply to Simon
    Simon:
    Im my job I have to write documentation as well as software. I wouldn't hire someone with a poorly formatted CV, it you can't be bothered to make something that important look nice, will you be bothered to format a document properly?

    I'm not talking about 'I don't like that style', but things that make it harder to read and harder to skim for the details.

    Same goes for poor grammer and spelling. I've probably made a mistake or two in this post, but it's not something that I'm trying to use to get a job!

    My grammer wood agree with you. She cain't spell neather.

  • Steve (unregistered) in reply to Chris G
    Chris G:
    In a certain POSIX real-time processng book I have one comment that sticks in my mind is that becuase of virtual function pointers inherent in C++, it isn't a _true_ realtime language. Using C allows a predictable control flow that can be evaluated.

    Just thought I'd add to the already growing C differences.

    There is nothing inherent about virtual function pointers in C++. As with other language features, you only get them if you ask for them. It's a bit like using gets.

  • Orbstart (unregistered) in reply to ruijoel
    ruijoel:
    2nd: Actually, it's well known that people with no sense of style/taste are awful interface designers...

    Weak troll attempt, FTFY.

    ruijoel:
    3rd: erm, Computer Science is Engineering. Oh, and this WTF explains a lot about the state of patents today.

    If you take Software Engineering, that is Engineering and is typically awarded by either a Bachelor or Master of Engineering degree. Typically Computer Science courses award a BSc. (In the UK at least)

  • Wolfgang (unregistered) in reply to Steve

    C++ and C today are quite distinct languages. You might be able to include C headers into a C++ program, but that's about it.

    It starts the way how pointer typing works in those language.

    In C you write:

    char *str = malloc(len);

    In C++ you do:

    char *str = (char*) malloc(len);

    Note the typecasting in C++, which without it you will get a error if compiled with a C++ compiler. OTOH doing that typecast is utterly wrong in C, since typecasting may allow for type reinterpretation, however the C standard states, that the value of a type void* must be able to be assigned to any kind of pointer without changing the value (casting may change it!). Most compilers will do it right, if explicitly typecasting things and not complain, but the standard would allow it. For the sake of compatibility most libraries written in C (like GLib, GTK) do explicit typecasting of void* but it may break if a compiler insists on exploiting this subtelty of the C language.

  • Médinoc (unregistered) in reply to Steve
    Steve:
    Seriously that has to be one of the lamest, won't compile in C++ examples I've ever seen. Simply replace the #ifdef with #ifdef __cplusplus #define class _class #define template _template #define new _new #endif

    And OMG, minus the malloc issue it will compile. And the malloc casting thing is mainly a non issue.

    Actually it will not compile, because you missed one other issue: A variable has the same name as a struct, which C++ forbids.

    As you can see, it's trickier than you thought!

  • Steve (unregistered) in reply to Wolfgang
    Wolfgang:
    C++ and C today are quite distinct languages. You might be able to include C headers into a C++ program, but that's about it.

    It starts the way how pointer typing works in those language.

    In C you write:

    char *str = malloc(len);

    In C++ you do:

    char *str = (char*) malloc(len);

    Note the typecasting in C++, which without it you will get a error if compiled with a C++ compiler. OTOH doing that typecast is utterly wrong in C, since typecasting may allow for type reinterpretation, however the C standard states, that the value of a type void* must be able to be assigned to any kind of pointer without changing the value (casting may change it!). Most compilers will do it right, if explicitly typecasting things and not complain, but the standard would allow it. For the sake of compatibility most libraries written in C (like GLib, GTK) do explicit typecasting of void* but it may break if a compiler insists on exploiting this subtelty of the C language.

    I think we've done that one already. So to add more fuel, if you don't want to typecast in C but need it to work in C++, do this:

    #ifdef __cplusplus #define mallocPlus(x,y) (y)malloc(x) #else #define mallocPlus(x,y) malloc(x) #endif

    Then call char str = mallocPlus(len, char);

    It is called mallocPlus for two reasons. One because it will annoy people who would write it malloc_plus and two because it is half way between C & C++.

    Now you have code that will compile in C & C++ and also won't cast in C.

  • Médinoc (unregistered) in reply to ais523
    steve:
    For the malloc example above the C Programming Language (2nd ed, I can't find my first edition to see if it has changed), says that you should explicitly cast malloc. If you do that then the code becomes valid C++ code also.
    The errata section of the K&R2 says otherwise:
    142(§6.5, toward the end): The remark about casting the return value of malloc ("the proper method is to declare ... then explicitly coerce") needs to be rewritten. The example is correct and works, but the advice is debatable in the context of the 1988-1989 ANSI/ISO standards. It's not necessary (given that coercion of void * to ALMOSTANYTYPE * is automatic), and possibly harmful if malloc, or a proxy for it, fails to be declared as returning void *. The explicit cast can cover up an unintended error. On the other hand, pre-ANSI, the cast was necessary, and it is in C++ also.
  • nottheieee (unregistered)

    Stop bitching about C++ people! He did it for us all.

  • Neeneko (unregistered) in reply to fresch
    fresch:
    Oh, sure I could drive an old Model T, where I have to use a crank to manually start the engine... but I'd much rather drive a Prius that not only has an automatic starter, but also has other really useful features over that Model T.

    A closer analogy would be an automatic vs stick shift.

    Or perhaps 'car you can work on yourself' vs 'car that can only be worked on by a shop'. Car analogies only go so far.

    So you like C and I like C++.

    Incorrect.

    I like both. I use C in places where C shines, and C++ in places where C++ shines. There are times where C's simplicity and control are simply more useful then C++'s sugar, complexity, redundancy, side effects, and obfuscation turn from helpful to hurtful.

  • Wizard Stan (unregistered) in reply to Code Dependent
    Code Dependent:
    Every essay I have ever read on getting hired, plus my Business and Professional Speaking class in college, have recommended that you not go beyond one page on your resume. A resume isn't an interview; it's a request for an interview. The details can come out in the interview.
    http://tinyurl.com/9b4ku6 You haven't been keeping up with the times. Much like how C has evolved and is no longer close enough to current C++ to be considered a subset under even the loosest definition of the word, the skill of resume writing has, as well, undergone quite a few changes. Only 12% of polled businesses agree with your statement, more suggest you should have as many as it takes (3+), while the most think you should stop at 2. My resume from late 90s, once considered the epitome of proper formatting, was recently passed off as "terrible" by several businesses. Changing the format a little, and the calls started coming in again. The computer industry is always adapting to new challenges, as new techniques and technologies become prevalent. Resume writing is simple by comparison, and if you can't afford the 10-20 minutes it takes to clean up your resume to match current standards (easily found by a google search) before sending it out, how can it be trusted that you've kept up with the plethora of new skills brought about by the latest fad in information technology? Updating your resume is a one time deal with a finite deadline: you find the current standard format, make your resume look like that, and start sending it out. There's no need to keep a constant watch on changes to "resume technology" like there is for programming. To add an analogy, how many WTFs have we read on here where a developer has done something technically correct, but so obviously wrong that it gives the site its name? Somewhere out there is a group of HR reps looking at a resume laughing, saying "can you believe this guy? He put his name in centered 10pt font when left justified bold 12pt is OBVIOUSLY so much better."
  • Neeneko (unregistered) in reply to Steve
    Steve:
    There is nothing inherent about virtual function pointers in C++. As with other language features, you only get them if you ask for them. It's a bit like using gets.

    Actually this is a common problem with C++ and real time applications. While it is true that C++ only inserts implicit functions (like the constructors, destructors, overloaded operators, etc) if you ask for them, the ease at which is slips them in and the lack of clear syntax makes figuring out exactly what will execute quite difficult. C++ obfusicates these details because normally the programmer doesn't need to know, but if the programmer DOES need to know what execution side effects a line has in it, it can be quite difficult to figure out. C++ is just too unpredictable when you need predictability.

    There have been many times that I've had to actually use a disassembler on a C++ object file to figure out what gets run between point A and point B.

  • Befuddled (unregistered) in reply to Jim
    Jim:
    So...you assume HR will know what skills you want, and then you filter on presentation? Sounds a little backward to me.
    I assume they can match one list with another and they can, I don't see CVs without the relevant skills.

    I still get too many with the relevant skills so I adopt the easiest means of eliminating a chunk. It's pretty common practise.

  • Kef Schecter (unregistered) in reply to Simon
    Simon:
    Same goes for poor grammer and spelling. I've probably made a mistake or two in this post, but it's not something that I'm trying to use to get a job!

    Indeed, but spelling "grammar" as "grammer" always strikes me as particularly ironic.

  • Buddy (unregistered) in reply to Wizard Stan
    Wizard Stan:
    ... Now suppose you get 1000 resumes. Do you read all 1000 just to find the statistical 20 candidates that are a good fit for the job? I'm glad you have that much time and money to spend...

    The biggest problem I have is getting swamped with hack resumes with little or no relevance. These are guys that just e-mail their crappy resumes without regard for applicability.

    What I do, and I find it works very well, is to put in the posting specific instructions, e.g.

    In your cover letter, please address the first and second requirements [or some other specific task] ... You may also fax your resume, attention [my name].

    From that it's fairly easy to check these points:

    Dear [generic] cover letter missing didn't address specific requirements

    Any of the above implies lack of attention to detail and the applicant is filtered out. Last time maybe one percent of the resumes got through this "intensive" filtering process.

    When I apply for a position, I tailor the cover letter and resume, do some research on the company, just basically visualize myself working there.

    In the old snail mail days, applicants would stoop to adding rice or whatever to envelopes to make them rattle!

  • Andy (unregistered) in reply to testx
    testx:
    What kind of actual criteria can you get in 3 seconds? That's not enough time to actually read the resume. Do you mean stuff like reading the name, guessing the person's ethnicity, and letting your prejudices make the decision?

    I three seconds I could do at least one of the following :

    -Skim the resume for a computer language of choice. -Skim the resume for the highest degree the person claims. -Skim the resume and make sure that "Microsoft Word" is not mentioned in the same bullet point as the applicant's primary programming qualifications. -Eliminate all resumes decorated with obnoxious clip-art.

    Granted, any one of these has a small possibility of eliminating a good candidate with a poorly formatted resume. (Or even a good candidate with unusual but acceptable qualifications.) But if I had hundreds of resume's to get through, I think this would be a reasonable first pass at dealing with them.

  • Wyrd (unregistered)

    The process of selecting whom to hire via interview is much like capitalism and standardized testing: it's the worst possible system to achieve the goal... except for all of the other systems.

    I mean, I don't actually know of any systems to filter through prospective hires besides the interview, but I'm just saying it's not that great.

    There is something you, the potential hire-ee can do about it though. You have to apply all over the place to as many companies as you can think of.

    Putting puppies in envelopes probably isn't a good idea. However, with really crazy interviewers, who can ever say for sure?

    -- Furry cows moo and decompress.

  • Ken (unregistered)

    I've actually worked at the Patent Office examining compiler patents. I'm interested when Dan M. applied, but I can assure him, he dodged a bullet there.

  • Wyrd (unregistered) in reply to testx
    testx:
    The more I think about it, the first one isn't even necessarily a wtf (except on the interviewees part). It's an electronics manufacturer. Perhaps they were developing embedded web servers/applications for their electronics. In that case, C would be a perfectly acceptable language if not the best language.
    Perhaps.

    But, IMHO show me a website running on straight C and I'll show you a buffer-overflow-leads-to-root-access bug just begging to happen.

    -- Furry cows moo and decompress.

  • Wyrd (unregistered) in reply to Metalehad
    Metalehad:
    To be fair - why would a C developer write code that compiled in both languages? C is still in heavy use in embeded applications right now, and there is no need to go to C++ in the future anyway. Why would a person spend a bunch of time making it cross-language?
    I don't know if it would always make sense to write for both languages.

    The only time I can see it making sense is if you're working on a project that has started in C that just keeps growing and growing. You know that, at some point in the future, it's probably going to grow so much that Object Oriented really is the way to go. So you start pushing for re-writes to get things as C++ compatible as you can in preparation for The Big Switch.

    The MAME project is kind of like that right now. I mean I don't think they have any plans to ever switch to C++, but as it's moved on and on they've been re-writing things more and more in a more object-ish oriented-ish paradigm.

    If you find yourself in a project that is written in C and you know you need to re-write it object oriented because of the project's behemoth-like size and complexity, C++ is the logical choice.

    -- Furry cows moo and decompress.

  • Wyrd (unregistered) in reply to pink_fairy
    pink_fairy:
    Anonymous Cowherd:
    The following is a legal C program that will not compile with a C++ compiler:
    #include <stdlib.h>
    
    struct S
    {
        int x;
    };
    
    int main(int argc, char * argv[])
    {
        struct S * f = malloc(sizeof(struct S));
        free(f);
    }
    

    Are you seriously telling me C programmers never use malloc?

    I believe your original point was "non-trivial."

    This, however, is a trivial C program, and as such I have submitted it to a trivial C++ compiler -- MinGW's g++. Yes, there's an error:

    "trivial.cpp: In function int main(int, char**)': trivial.cpp:19: error: invalid conversion fromvoid*' to `S*'"

    Refining to (struct S*)malloc(...) removes the error. The behaviour will be the same in C/C++.

    Are you seriously telling us that you don't understand what a straw-man argument is?

    But, in all fairness, it's not a strawman argument. A strawman argument is when you throw up a silly/weak example to try to make your broad grand point, and in so doing, distort things badly. This isn't a strawman because the assertion under dispute was very logical and mathy. Suppose I made the assertion: "ALL animals have symmetrical body structure." Well my assertion would be incorrect because the sponge is considered to be an animal and it does not have symmetric body structure.

    The strawman problem comes into play in more real-world debate scenarios with many shades of grey, subtleties, and complexities and then someone frames the argument in such a way as to make it appear that a very weak example is representative of the whole thing, and then proceeds to destroy the weak example.

    An example of strawman would be if I were to talk about the bogusness of the point of view of a specific nutball religious extremest, and then went on to generalize from that, that all religious persons are nuts. That's strawman.

    The specific claim that he was trying to refute was that "C++ is a proper superset of C". "proper superset" is a precise mathematical term and it has a precise mathematical meaning. When we apply that term to the previous assertion, we see that it should mean, in part, that every C program will compile under C++. This is not the case. The fact that the bug in question might be trivial and easy to fix is not itself trivial. If there is even one (trivial) C program that cannot compile under C++ without first being modified then there exists a computer program within the set of valid C programs that is not an element within the set of valid C++ programs.

    Therefore, C++ is not a proper superset of C.

    Maybe we should make up a new term like... fuzzy superset. :-) We could then call C++ a fuzzy superset of C. Yeah. That sounds good.

  • Steve H (unregistered) in reply to Leak
    Leak:
    np: Tocotronic - Aber Hier Leben, Nein Danke (Kapitulation Live)

    You really think we give a damn, huh?

Leave a comment on “It's All About C, The CIA Interview, & Not People Like You”

Log In or post as a guest

Replying to comment #:

« Return to Article