• Kef Schecter (unregistered) in reply to Porpus
    Porpus:
    It's difficult for me to get upset or surprised about the fact that something's being written in C. To me, plain C plays the role of lingua franca in the world of programming.

    Indeed, but the WTFness about it was the interviewer's "C is all the rage now!" attitude -- the way it's written, it's clear that the interviewer thinks there's something new about coding things in C and doing things in PHP, etc. is now obsolete.

  • Wizard Stan (unregistered)

    Consider you get 100 resumes. After reading through all 100, 2 candidates stand out. One has a beautiful resume, the other is just ok. Either candidate will work out perfectly, but you spent a fair bit of time to find those 2 candidates. 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. First run, look for the nice resumes, cutting the task in half. You're down to only 500 to read through now. Still a lot, but much better than 1000. Boo hoo, you've thrown away 10 perfectly good candidates for the job. Big deal, you've still got 10 others that would be equally good. Or even better, take only the top 1/4 resumes. 250 applications to read now. You pass over 15 perfect candidates, but you've still got 5 left in that pile somewhere. Complain all you want about being passing up "the perfect candidate" because your resume might not look the prettiest, but remember, you're rarely ever the only perfect candidate for the job. And if it is the kind of job where I'm the only proper fit for the position that applied, maybe it's not the kind of place I want to work for anyway. That being said, arguing that arrows are better than bullets is asinine.

  • (cs)

    Dude, you could have easily gotten that CIA job. Your resume just needed...

    A BIT MORE COWBELL ^G^G^G

  • Jeff (unregistered)

    I remember trying to write a portion (one feature) of a website using a C module (as I wasn't really a web developer and my main language was C). I did about 25% of it, thought "there must be an easier/better way". I then rewrote it in PHP. Even learning the language from scratch, I developed it a LOT faster and managed to add a lot more features by the same deadline :)

  • Tom Woolf (unregistered)

    About #2...

    While searching through resumes for technical writers, I ran across one that had a bunch of bells and whistles. WordArt was apparently the applicant's favorite tool.

    The resume had about 15 different fonts, a mixture of bold, italics, underlines, etc. The thing that stood out the most on the resume was the phrase "I'm a lean, mean, tech-writing machine!" vertically in the margins.

    It reminded me of the class I was TA for in college many years ago, where the professor required we grade on the number of font changes on a document rather than how the document actually looked (it was a beginning computer class, and the assignment was a first use of a word processing program).

    Pretty does not mean quality (or qualified)...

  • Eric (unregistered) in reply to Porpus
    Porpus:
    It's difficult for me to get upset or surprised about the fact that something's being written in C. To me, plain C plays the role of lingua franca in the world of programming.

    There are good reasons for this fact - C's not just an unfortunate artifact of the past. It manages to abstract the true nature of the hardware without hiding it, in a way that, uh, Anaconda, Gem, and Visual J-Widgets, for example, cannot.

    I'm not saying everything should be written in C. But during the tools selection phase of many projects, I think a good starting point is to ask "should we just do this in C?"

    And during the programmer selection process, one can ask "does this candidate know C?" and that question will basically be a proxy for "does this candidate know the basics of computer programming?

    This touches on something that I think about on occassion as a programmer (for reference, I started with C++ and now work with .NET). As I progress, the tools I use, and likely the tools I will use in the future, increasingly separate me from the hardware that runs the programs I write. I wonder how much more efficient my programs could be in a language like C++; on the other hand, there's the question of whether they actually need to be more efficient at all, which brings into play Moore's Law. I haven't had any poignant thoughts on the matter, personally, but ocassionally it bothers me.

  • IT Girl (unregistered) in reply to testx
    testx:
    Sutherlands:
    Are you... trying to say that the first screen should be... random??? It's really not hard to glance at a resume for about 3 seconds and decide if it's going to make some first cut based on ACTUAL criteria, not how the resume looks.

    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?

    If you really have an overload of applications (and there are many positions that fall in this category even in a good economy), filtering based on how the resume looks doesn't sound so bad. At the very least, it shows the person spent the time to make their resume look good.

    edit prior to posting: pretty sure the code for this website is one big wtf... so slow

    I've been on the receiving end of more resumes than one really wants to look at and it is possible to tell something about a resume very quickly. The first thing I looked for is exactly what the interviewee in question did in the story. That is, a section that just listed skillsets. Anyone who didn't have a quick reference to their skillsets was set on the "look at if you get time and there's no one skilled in the other pile" pile.

    I've never dumped a CS CV for not being pretty enough, but I have dumped a secretary's CV for that reason. It's all a question of what skillsets you're looking for and let's face it, a good coder doesn't need to know how to make a resume pretty.

  • blah (unregistered) in reply to Tom Woolf
    Tom Woolf:
    Pretty does not mean quality (or qualified)...
    More importantly, immense variety rarely ever means pretty or pleasing. Those people have no sense of aesthetics.
  • Steve (unregistered) in reply to Eric

    When .NET CF was first released for PDAs I did some performance tests of C# vs an app I wrote in C++. C# was something like 10-100 times slower for the things I needed to do :-(, worse than that, I wrote a very basic RDP & VM in C++ that was between 2-50 times faster than .NET CF. Needless to say most of my PDA code is still written in C/C++ :-) (I have not benchmarked latest .NET CF release...)

    On the desktop, our code is split about 50/50 between C++ & C#.

  • Neeneko (unregistered) in reply to dubbreak

    [quote user="dubbreak"] [quote]C++ is a proper superset of C. Java and Javascript are completely unrelated to each other (syntax may look vaguely similar, but so does c# and a plethora of other languages). [/quote]

    Not entirely accurate. C++ is almost a superset of C, but there are C programs that will not compile under C++ because the changed those aspects of the language.

    Objective C is a true superset though.

  • (cs) 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.

    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. I think a nice analogy is playing acoustic guitar and electric guitar. You can play almost anything you do in one with the other, but if you need to use vibrato or harmonics or pull the distortion lever on an acoustic guitar you're stuck.

  • anon (unregistered) in reply to Sutherlands
    Sutherlands:
    James:
    I'm going to defend the guy/girl in the 2 one. Like they said they had a folder full of applications already. Let’s face it they aren't going to read them all and a 1st "screening" of how good the CV looks is as good a “random” filtering process as any.
    Are you... trying to say that the first screen should be... random??? It's really not hard to glance at a resume for about 3 seconds and decide if it's going to make some first cut based on ACTUAL criteria, not how the resume looks.

    I always go through a stack of resumes and throw away every other one. I mean, who wants to hire someone that is unlucky?

  • Rufus Brown (unregistered)

    Founded and headquartered in the Netherlands? Sounds like Philips to me...

  • Steve (unregistered) in reply to Smash King
    Smash King:
    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.

    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. I think a nice analogy is playing acoustic guitar and electric guitar. You can play almost anything you do in one with the other, but if you need to use vibrato or harmonics or pull the distortion lever on an acoustic guitar you're stuck.

    I would say that a good C++ programmer can write good C code straight away. A good C programmer can pick up C++ quickly but would need to learn the ++ part of the language/std library.

  • (cs) in reply to Eric

    C++ itself has been progressing as well, with more compliant compilers available and more libraries available. Boost in particular makes C++ a lot more usable and productive to code in.

  • (cs) in reply to ruijoel
    ruijoel:

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

    I have to balk at that. CS is not Engineering. It's much closer to Math - a science. Now, there is a Computer Engineering as a major, and I suspect that many CS grads do much more hands-on architectural work as a profession. But, CS people and CpE people think VERY differently about problems. They've been trained that way.

  • Neeneko (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.

    Who said they are completely different? They are an overlapping set, C++ derives from C, but it is by no means a superset. And simply writing off any difference as 'crap C' codes doesn't help your case.

    Some of the biggest differences are 'under the hood' in ways the fundamentally effect how you can interact with the language. Even if a C++ complier compiles a C program that does not mean it will behave the same way. When dealing with binary data, metaprograming, self-aware programs, or any other low level operation these differences can make a big deal.

    So what you are really saying is they are not different in any way that is useful to YOU therefor they are the same.

  • Neeneko (unregistered) in reply to Steve
    Steve:
    I would say that a good C++ programmer can write good C code straight away. A good C programmer can pick up C++ quickly but would need to learn the ++ part of the language/std library.

    I have to disagree. I've found that good C++ programmers THINK they are writing good C code, but often they don't. I used to work in a mixed C and C++ environment and sometimes got headaches when the C++ programmers tried to 'help' on sections of C code. They were bright programmers who really know thier C++ stuff but they just didn't think of the types of problems you encounter in C or how to deal with them. It got esp messy when try tried resource management, overloading, or polymorphisms.. things that are done magically for you in C++ but you have to do them manually in C.

    Now granted with had similiar problems when it came to the pure C programmers trying to help in C++ code.... usually they were unaware of all the things the language helps you with and thus kept doing things the "C" way... or they discovered a useful feature and used it to death rather then were it was appropriate.

  • (cs)
    "Let me show you something," the interviewer said, pulling out another résumé from his folder

    w?t?f?

    So a dude from the CIA-- a agency whose job is to maintain and protect secrets-- just grabs someones private information and shows it to a random stranger?

    "Hey, buddy. Ever seen a cipher key? It's so cool! You should make all yours like it."

  • Steve (unregistered) in reply to Neeneko
    Neeneko:
    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.

    Who said they are completely different? They are an overlapping set, C++ derives from C, but it is by no means a superset. And simply writing off any difference as 'crap C' codes doesn't help your case.

    Some of the biggest differences are 'under the hood' in ways the fundamentally effect how you can interact with the language. Even if a C++ complier compiles a C program that does not mean it will behave the same way. When dealing with binary data, metaprograming, self-aware programs, or any other low level operation these differences can make a big deal.

    So what you are really saying is they are not different in any way that is useful to YOU therefor they are the same.

    I disagree, can you give an actual example? (I will assume that you are talking about ANSI C and the current C++ standard.)

    C++ is definitely more useful for me than C, but can you show me an actual example of a C program with fundamental under the hood differences?

  • Steve (unregistered) in reply to Neeneko
    Neeneko:
    Steve:
    I would say that a good C++ programmer can write good C code straight away. A good C programmer can pick up C++ quickly but would need to learn the ++ part of the language/std library.

    I have to disagree. I've found that good C++ programmers THINK they are writing good C code, but often they don't. I used to work in a mixed C and C++ environment and sometimes got headaches when the C++ programmers tried to 'help' on sections of C code. They were bright programmers who really know thier C++ stuff but they just didn't think of the types of problems you encounter in C or how to deal with them. It got esp messy when try tried resource management, overloading, or polymorphisms.. things that are done magically for you in C++ but you have to do them manually in C.

    Now granted with had similiar problems when it came to the pure C programmers trying to help in C++ code.... usually they were unaware of all the things the language helps you with and thus kept doing things the "C" way... or they discovered a useful feature and used it to death rather then were it was appropriate.

    They can't be very good C++ programmers if they can't write decent C code. Seriously, I'd like to see some pure C code that a C++ programmer wouldn't understand.

  • Paul (unregistered)

    Just so I get the CIA WTF - the person who was in charge of resume receiving gave the person criteria (pointless criteria from our POV) by which their resume would be considered - and - this is a bad thing?

    So what if the criteria was pointless/meaningless/useless - a specification was given to someone who, perhaps, would be given a large responsibility and strict legal requirements for their position and have access to sensitive, critical and personal information for the citizens of the country - and they didn't want to comply?

    Given I dislike the government, I seriously doubt they thought this deep in to the situation, but, it would be an interesting way to filter out people who will be subject to stupid laws (written by congress) and be unable to grasp their compliance is required in order to achieve the goals of the organization.

    All the applicant was asked to do was to get a pattern paper to print their resume and add some graphically interesting features to it. Not really a huge obstacle. Compared to the legal requirements in intelligence collecting agencies with the bill of rights and international laws... (ok, I don't assume they follow the laws, just that they exist and they need to cover up when the violate them...)

    Having said that - yeah, pretty stupid....

  • 5|i(3_x (unregistered) in reply to Smash King
    Smash King:
    I think a nice analogy is playing acoustic guitar and electric guitar. You can play almost anything you do in one with the other, but if you need to use vibrato or harmonics or pull the distortion lever on an acoustic guitar you're stuck.

    Guitar troll? Enjoy your feeding: --You can add a bit of vibrato to an acoustic with your fretting hand although I've never seen an acoustic with a tremolo ('whammy') bar http://www.youtube.com/watch?v=WiI1maWrZHo. --You can still play harmonics on an acoustic guitar http://www.youtube.com/watch?v=laKU2ptXJ6Y. --Most electric guitars do not have built-in effects but outboard effects could also be engaged on an acoustic. I'll call this one imprecise rather than inaccurate.

    Barring a few details though, I think your analogy works.

  • (cs) in reply to testx
    testx:
    What kind of actual criteria can you get in 3 seconds?
    Given that a resume should be one page in length, in three seconds I can get:

    Skill set Education What was last job How many jobs, and how long at each one

    That's enough to know in which pile this resume goes.

    Okay, maybe it would take five seconds.

  • Mike (unregistered) in reply to Steve
    Steve:
    I disagree, can you give an actual example? (I will assume that you are talking about ANSI C and the current C++ standard.)

    C++ is definitely more useful for me than C, but can you show me an actual example of a C program with fundamental under the hood differences?

    I suspect this is far less significant of an example than you are looking for but in C (I could be wrong about the specifics, its been some time since I dealt with this :)) enums are actually integers that can be incremented through with the ++ operator. In C++ this is not true.

    In our system we have some low level C modules while everything else is C++. Someone had the bright idea that for testing they could just add the pp to the .c extension for testing the .c modules but for this reason the module failed the test (or may have just failed to compile)...

  • (cs)

    C'mon, prospective web developers! It's so simple maybe you need a refresher course. It's all ball bearings nowadays!

  • Neeneko (unregistered) in reply to Steve
    Steve:
    I disagree, can you give an actual example? (I will assume that you are talking about ANSI C and the current C++ standard.)

    C++ is definitely more useful for me than C, but can you show me an actual example of a C program with fundamental under the hood differences?

    The classic one is loadable modules. Not linking to an .so but actually loading object code at runtime. In C the function names are predictable strings while in C++ they are mangled. Under GCC at least there is no way to ask 'if I have a function that takes these parameters, what is it's managed string equivalent?'. So any C code that uses loaded modules will fail when compiled as C++.

    Any time you need to know stack details (frame format, backtrace data, i.e. runtime debugging) c++ also produces different code that will likely not work.

    They also handle enums slightly differently. C++ tries to scale the enum while C gives it a fixed size. This can make a difference when overlaying structs onto binary data (big deal in drivers, audio/video/sensor decoding, anything with memory mapped I/O).

  • Dirk Diggler (unregistered) in reply to anon
    anon:
    Sutherlands:
    James:
    I'm going to defend the guy/girl in the 2 one. Like they said they had a folder full of applications already. Let’s face it they aren't going to read them all and a 1st "screening" of how good the CV looks is as good a “random” filtering process as any.
    Are you... trying to say that the first screen should be... random??? It's really not hard to glance at a resume for about 3 seconds and decide if it's going to make some first cut based on ACTUAL criteria, not how the resume looks.

    I always go through a stack of resumes and throw away every other one. I mean, who wants to hire someone that is unlucky?

    I only keep the resumes that have a $20 bill paper clipped to them. (But I deduct points if the paper clip is plastic or on the wrong corner.)

  • Neeneko (unregistered) in reply to Steve
    Steve:
    They can't be very good C++ programmers if they can't write decent C code. Seriously, I'd like to see some pure C code that a C++ programmer wouldn't understand.

    Oh they understand it, but people trained to rely on things like constructors/destructors doing all thier inits and cleanups for them tend to make a lot of mistakes when having to sit and manage their data manually.

    They also tend to forget that the language will not stop them from doing odd things (like calling a function with prototype foo(int bar) via foo("hello world!") since C functions do not carry type data with them).

    Such programmers understand the literal code, but they don't understand the pitfalls. Nor do they tend to know the classic C ways of solving problems and thus to not recognize say, an object in C or how a macro differs in use and behavior from a template.

    C++ has more tools, so it tends to have different solutions. And just because someone knows a language well and knows the syntax of another language doesn't mean they will magically know how to use the language well.

  • Brian C (unregistered) in reply to SomeCoder
    SomeCoder:
    This is completely a WTF. Passing over a resume because it has dots instead of arrows for bullet points is one of the biggest WTF I've ever seen and as someone who lives in America, I now fear for my safety if this is the criteria that the mighty CIA is using to select candidates.

    Its not the CIA thinks this makes better agents, if thier final reports don't look the same way with pretty colors and bullets the politicians will never read them... you know how congress members like their shiny objects and pretty pictures.

  • Daniel (unregistered)

    To respond to the many criticisms of post #1 on this story:

    HTML/DHTML are in there because they were still a big deal at the time. Also this was my first job out of college, I was attempting to take up space.

    The job posting for this company was very specific about developing "web sites," another reason why web languages and web markup were pushed to the top of the list.

    C/C++ were lumped together specifically because recruiters are stupid and I didn't want to confuse them.

  • (cs) in reply to Dirk Diggler
    Dirk Diggler:
    I only keep the resumes that have a $20 bill paper clipped to them.
    Wow, a twenty dollar interview whore. Who knew?
  • Daniel (unregistered) in reply to Daniel

    Oh, and I do know C and C++, which is why they're on my resume. I don't LIKE them, which is why I applied for a web programming job. I was attempting to downplay my C skills so that she wouldn't shove me into an embedded programming applicant pile, and was completely taken aback when she declared that C was the next Spice Girls.

  • Anonymous Cowherd (unregistered)

    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?

  • soup (unregistered)

    What's ironic is that the CIA is probably one of the first organizations in the world to use OCR technology. I would have thought that most HR departments these days use it to scan resumes, especially for technical positions.

    I better update my triangle skills (and add that skill to my resume, of course.)

  • Neeneko (unregistered) in reply to Daniel
    Daniel:
    C/C++ were lumped together specifically because recruiters are stupid and I didn't want to confuse them.

    nods which unless the company is specifically looking for a C specialist makes perfect sense. 99.99% of the time writing C/C++ is the way to describe one's skillset.

    And that remaining .01% of the time, any company that doesn't suck will include in the posting that they want C as a separate skill.

  • Bill (unregistered) in reply to JoJo

    No word of a lie: I once got interviewed because I had a cartoon pig on my application letter. As they told me later: "We couldn't find anybody and then I said, "Why don't we call that guy with the pig on his resume?"... and the rest is history...

  • 01001001011101000010011101110011001000000110110101100101 (unregistered) in reply to DOA
    DOA:
    Who puts HTML in their resume? Honestly! Not to mention DHTML... you might as well start putting Web 2.0, etc in there.

    Edit: I posted first, but ObiWayneKenobi's post was better formatted and got first place.

    What makes you think they don't? I frequently interview for web developer positions and I see "web 2.0", ajax, XML (as a language), etc all the time. Then you ask them an actual question about javascript and you get an answer like "I just write code in JavaScript, I don't try to understand it."

    And yes that is an actual quote from an interviewee. The interview ended shortly thereafter.....

  • Neeneko (unregistered) in reply to Anonymous Cowherd
    Anonymous Cowherd:
    Are you seriously telling me C programmers never use malloc?

    To many this would simply be an example of 'crap C' since C++ makes a very big deal about compile time type checking. C++ would probably dropped void pointers completely if they could get away with it.

    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).

  • Franz Kafka (unregistered) in reply to halcyon1234
    halcyon1234:
    So a dude from the CIA-- a agency whose job is to maintain and protect secrets-- just grabs someones private information and shows it to a random stranger?
    1. It's a resume - hardly secret
    2. the CIA only protects its own secrets.
    Neeneko:
    They also tend to forget that the language will not stop them from doing odd things (like calling a function with prototype foo(int bar) via foo("hello world!") since C functions do not carry type data with them).

    It will stop them if the have prototypes in their header file - a warning about inconsistent declarations is good as an error. Of course, you can just create a prototype for the function with the wrong arguments and call that - it'll work until you try to run it.

  • Steve (unregistered) in reply to Neeneko
    Neeneko:
    Steve:
    I disagree, can you give an actual example? (I will assume that you are talking about ANSI C and the current C++ standard.)

    C++ is definitely more useful for me than C, but can you show me an actual example of a C program with fundamental under the hood differences?

    The classic one is loadable modules. Not linking to an .so but actually loading object code at runtime. In C the function names are predictable strings while in C++ they are mangled. Under GCC at least there is no way to ask 'if I have a function that takes these parameters, what is it's managed string equivalent?'. So any C code that uses loaded modules will fail when compiled as C++.

    Any time you need to know stack details (frame format, backtrace data, i.e. runtime debugging) c++ also produces different code that will likely not work.

    They also handle enums slightly differently. C++ tries to scale the enum while C gives it a fixed size. This can make a difference when overlaying structs onto binary data (big deal in drivers, audio/video/sensor decoding, anything with memory mapped I/O).

    Ok my responses fwiw :-) I never use enums when an explicit size needs to be used, instead I cast the value to int or whatever first and use that. So yes I agree that enum sizes are different but when passing data between systems I would not use enums directly.

    For function names that need to be exposed I use extern "C" {...}

    Regarding stack details, both use the cdecl calling convention by default. You can usually ask the compiler to change calling conventions/frame format etc if you need specific settings.

  • Anon (unregistered) in reply to Brian C
    Brian C:
    SomeCoder:
    This is completely a WTF. Passing over a resume because it has dots instead of arrows for bullet points is one of the biggest WTF I've ever seen and as someone who lives in America, I now fear for my safety if this is the criteria that the mighty CIA is using to select candidates.

    Its not the CIA thinks this makes better agents, if thier final reports don't look the same way with pretty colors and bullets the politicians will never read them... you know how congress members like their shiny objects and pretty pictures.

    You actually think congressman read any of those reports rather than getting four sentence summaries from their staff?

  • fred (unregistered) in reply to Neeneko
    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.
  • Steve (unregistered) in reply to Anonymous Cowherd
    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?

    Are you seriously telling me you couldn't write that so it wouldn't compile in both C & C++?

  • Anonymous Cowherd (unregistered) in reply to Steve
    Steve:
    Are you seriously telling me you couldn't write that so it wouldn't compile in both C & C++?
    Of course I could. The point is, though, that C++ is not a superset of C. There are lots of things that are legal in C that are not legal in C++. The two are different languages, and the only reason C++ retains many of C's more braindead misfeatures is to allow programmers to carry on using Unix headers. See the 'struct stat' vs stat(2) mess for a perfect example.
  • Beldar the Phantom Replier (unregistered)
    One booth that looked particular interesting was the CIA's...
    How exact would one go about making something of particular interesting?
  • Neeneko (unregistered) in reply to fred
    fred:
    This is why Jesus invented uintptr_t.

    Heh. Good point. If those typedefs are avaiable on your system that gives you a good platform independent way to work with a pointer.

  • Steve (unregistered) in reply to Anonymous Cowherd
    Anonymous Cowherd:
    Steve:
    Are you seriously telling me you couldn't write that so it wouldn't compile in both C & C++?
    Of course I could. The point is, though, that C++ is not a superset of C. There are lots of things that are legal in C that are not legal in C++. The two are different languages, and the only reason C++ retains many of C's more braindead misfeatures is to allow programmers to carry on using Unix headers. See the 'struct stat' vs stat(2) mess for a perfect example.

    To quote some book written by some random people:

    The question of the type declaration for a function like malloc is a vexing one for any language that takes its type-checking seriously. In C, the proper method is to declare that malloc returns a pointer to void, then explicitly coerce the pointer into the desired type with a cast.

    So you should really be casting that malloc...

  • Neeneko (unregistered) in reply to Steve
    Steve:
    I never use enums when an explicit size needs to be used, instead I cast the value to int or whatever first and use that. So yes I agree that enum sizes are different but when passing data between systems I would not use enums directly.

    Normally neither would I (I prefer the various u16 s32 etc style typedefs or macros) but it is a difference that can cause things to fail in subtle ways. I have encountered enums used in raw network packets that broke because of this.

    For function names that need to be exposed I use extern "C" {...}

    Yep, that is the general solution. Not saying the issues can't be worked around.. one can always extern the prototypes or entire blocks of code (externing then wrapping dlsym stuff is common). But my point was that C code as written, while still correct enough to compile, will fail at runtime if compiled as c++.

  • Metalehad (unregistered) in reply to Steve

    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?

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