I'm sorry about asking a weird question about this. I googled and looked up to here for a solution, but none of the answers satisfy what actually I want.
I am really confused about this question. It's been almost 2 years that I have been studying for security based work. So, I have good knowledge about Python and C.
The company that I referred gave me advise to learn about Win32. But when I begin to learn about it, I encountered that Win32 is C++ based. But I don't want to waste time again to study it. Some blogs talk about Windows Programming in C/C++, and this makes more confusion for me as C and C++ are essentially separate from each other, I think.
My questions are:
Can I learn Win32 with only C?
If no, then can I learn it over C?
If yes, how deep do I have to go (so, all context of it or specific)?
So again sorry. I'm really very confused at the moment that I don't know what I have to do.
As far as I know - yes, it should be possible. The older Windows APIs were in fact C based and that's what I learned myself 20 years ago. They're quite straightforward. The newer ones are based on COM which is a bit more of a hassle to do in C, but by no means impossible. I remember reading some good tuorials on doing just that (COM in C), although I don't have any handy links to give out I'm afraid.
That said, C and C++ are quite close. In fact, C++ was originally intended to be a superset of C - every valid C program was supposed to be a valid C++ program. Now, they didn't quite make that happen, but the differences are subtle and for the most part shouldn't bother you much. So you might as well continue writing code in C, using just a bit of C++ for interfacing with COM. The C++ compiler should accept this just fine.
Correct me if I am wrong, but in one book I have read that every C++ program is converted to C while it is going through different compiling phases.
I just want to see the C code.
Can any one tell me how to view that code?
Search for CFront for the answer to your question; Wikipedia has a good summary
C++ started out as a C code generator called CFront, but this was abandoned in 1993. Since then, all C++ compilers have been normal compilers, not C front-ends. Exceptions were the original difficulty, but there are weird corners like the subtle difference in the meaning of "void" that would be awkward too.
It is a good approach to learning C++ to think "What would the C equivalent of this be?", but you can no longer generate it from the compiler, sorry.
Edit: some people are commenting that there are products available to do what you want. I was unaware of these. I would say that although this is what you want, it probably isn't what you need. If your aim is to understand C++, read about C++.
I recently learned about the wonderful memory management technique of RAII, which seems so much cleaner than the new/delete headache I learned in school years ago (I haven't looked at much C++ during the intervening years).
I'm trying to track down when this great technique was added to C++. Was it always there and I just missed the memo? What's the oldest version of the C++ standard which supports RAII?
[UPDATE: OK I realize now why this isn't an ideal SO question -- I have no practical way to verify whether any given answer is correct! Nonetheless I'm still very interested to learn the answer, and I assume the majority opinion will be true.
What I'm hearing is that it's always been there, which I don't doubt is true, but begs the question how come none of my old text books mention it? I just checked Meyers' Effective C++ 2nd edition which I have handy, and will check older texts tonight. Maybe the term was only recently coined, while the technique existed long before?]
When exactly the term "RAII" was coined, I'm not sure. But the technique itself existed in C++ from the moment of its invention, circa 1979.
The first version of the C++ ISO standard was published in 1998.
Any language that has scoped variables with automatic destructor calls is able to do RAII. C++ had this concept from the very beginning as calling destructor when execution leaves scope where variable is declared was in C++ from the very beginning.
Wikipedia's claim that Stroustrup invented RAII is backed by a reference to his book Design and Evolution of C++, published in 1994.
I don't have a copy to check, but it would seem to date from at least this time.
This may seem a trivial question, but it's one that's bothered me a lot lately. Why do some programmers refer to "C++/STL" like it's a different language? The STL is part of the C++ standard library -- and therefore is part of the language, "C++". It's not a separate component, and it does not live alone in the scope of things C++. Yet some continually act like it's a different language altogether. Why?
It's possible to be a competent and experienced C++ programmer and never use the STL. You may be using Boost or ACE, or been an MFC windows programmer for 10 years.
If you want someone experienced in using the STL, asking for someone who knows C++ is no guarantee that you'll get one.
Also for my mind, writing code that's heavily dependent on the STL feels very different to writing, say, MFC code. They might as well be different languages. They certainly won't look particularly similar.
An understanding of the STL isn't necessary to understand C++. It's useful to have when you need ADTs, but you can go (could have gone?) through your whole C++ career without needing it.
The above answers are really good; I'm only going to add to their content in a broader context.
Developers might refer to language/api|library e.g. C/Win32, Java/Struts, Java/Spring, C#/.net MVC because there are in essence two knowledge bases - knowledge of the language in question and knowledge of how to use that specific library, API or framework. Something like Win32 is pretty huge, as is say Django, which I'm currently learning. Django itself works in a very specific way and knowing that is what I'm learning, not Python.
The same is true of C++/MFC or C++/Boost or C++/STL. The language is C++ - the API/library you're using is MFC, Boost or STL.
Probably because STL came a little late to the C++ game, and many people have written code that does not use any STL. For example, think early win32 programming with MFC.
Guess:
When C++ was first released, the STL did not exist. It came into existence later as an optional addition and then was incorporated into the standard.
When writing a resume, people would often list C/C++ as a language, which, in many cases means they don't know either.
Sometime resumes would list "Visual C++" as a language, trying to indicate they don't know what a language is.
This, together with "great knowledge of C++ and PHP" statements, go strait into recycle bin at my firm. Not because they are necessarily bad programmers - but because the interview time waste is not worth it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I've seen a lot of questions around that use improperly the expression "C/C++".
The reasons in my opinion are:
Newbie C and C++ programmers probably don't understand the difference between the two languages.
People don't really care about it since they want a generic, quick and "dirty" answer
While C/C++ could sometimes be interpreted as "either C or C++", I think it's a big error. C and C++ offer different approaches to programming, and even if C code can be easily implemented into C++ programs I think that referring to two separate languages with that single expression ( C/C++ ) is wrong.
It's true that some questions can be considered either as C or C++ ones, anyway.
What do you think about it?
C/C++ is a holdout from the early days of C++, where they were much more similar than they were today. It's something that wasn't really wrong at first, but is getting more-so all the time.
The basic structure is similar enough that most simple questions do still work between the two, though. There is an entire Wikipedia article on this topic: http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B
The biggest fallacy that comes from this is that because someone is well-versed in C, they will be equally good at C++.
Please remember that the original implementations of C++ were simply as a pre-compiler that output C code for the 'real' compiler. All C++ concepts can be manually coded (but not compiler-enforced) in plain C.
"C/C++" is also valid when referring to compilers and other language/programming tools. Virtually every C++ compiler available will compile either - and are thus referred to as "C/C++" compilers. Most have options on whether to treat .C and .CPP files based on the extension, or compile all of them as C or all of them as C++.
Also note that mixing C and C++ source in a single compiler project was possible from the very first C/C++ compiler. This is probably the key factor in blurring the line between the languages.
Many language/programming tools that are created for C++ also work on C because the language syntax is virtually identical. Many language tools have separate Java, C#, Python versions - but they have a single "C/C++" version that works for C and C++ due to the strong similarities.
We in our company have noticed the following curious fact: if a job applicant writes in his CV about "advanced C/C++ knowledge", there is usually a good chance that he really knows neither ;)
The two languages are distinct, but they have a lot in common. A lot of C code would compile just fine on a C++ compiler. At the early-student level, a lot of C++ code would still work on a C compiler.
Note that in some circumstances the meaning of the code may differ in very subtle ways between the two compilers, but I suppose that's true in some circumstances even between different brands of C++ compiler if you're foolish enough to rely on undefined or contested/non-conformant behavior.
Yes and no.
C and C++ share a lot in common (in fact, the majority of C is a subset of C++).
But C is more oriented "imperating programming", whereas C++, in addition to C paradigm, has more paradigms easily accessible, like functional programing, generic programing, object oriented programing, metaprograming.
So I see the "C/C++" item saying either as "the intersection of C and C++" or "familiarity with C programing as well as C++ programing", depending on the context.
Now, the two languages are really different, and have different solutions to similar problems. A C developer would find it difficult to "parse/understand" a C++ source, whereas a C++ developer would not easily recognize the patterns used in a C source.
Thus, if you want to see how far the C is from the C++ in the "C/C++" expression, a good comparison would be the GTK+ C tutorials, and the same in C++ (GTKmm):
C : GTK+ Hello World: http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD
C++ : GTKmm Hello World: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-helloworld.html
Reading those sources is quite enlightening, as they are, as far as I parsed them, producing exactly the same thing, the "same" way (as far as the languages are concerned).
Thus, I guess the C/C++ "expression" can quite be expressed by the comparison of those sources.
:-)
The conclusion of all this is that it is Ok if used on the following contexts:
describing the intersection of C and C++
describing familiarity with C programing as well as C++ programing
describing compatible code
But it would not be for:
justifying keeping to code in a subset of C++ (or C) for candy compatibility with C (or C++) when compatibility is not desired (and in most C++ project, it is not desired because quite limitating).
asserting that C and C++ can/should be coded the same way (as NOT shown by the GTK+/GTKmm example above)
I think it's more of the second answer - they want something that's easily integrated into their project.
While a C answer may not be idiomatic C++ (and vice versa), I think that's one of C++'s big selling points - you can basically embed C into it. If an idiomatic answer is important, they can always specify C/C++/C++ with STL/C++ with boost/etc.
An answer in lisp is going to be pretty unusable. But an answer in either C or C++ will be directly usable.
Yeah, C/C++ is pretty useless. It seems to be a term mostly used by C++ newbies. We C-only curmudgeons just say "C" and the experienced C++ folks know how much it has diverged from C and so they properly say "C++".
Even if C is (nearly) a subset of C++, this doesn't really have any bearing on their actual usage. Practically every interesting C feature is frowned upon in modern C++ code:
C pointers (use iterators/smart pointers/references instead), macros (use templates and inline functions instead), stdio (use iostreams instead), etc. etc.
So, as Alex Jenter put it, it's unlikely that anyone who knows either language well would say C/C++. Saying that you know how to program in "C/C++" is like saying you know how to program in "Perl/PHP"... sure they've got some significant similarities, but the differences in how they are actually used are vast.
C/C++ often means a programiing style, which is like C and classes, or C and STL :-) Technicaly it is C++, but minimum of its advantages are used.
I agree. I read the C tag RSS feed, and I see tons of C++ questions come through that really don't have anything to do with C.
I also see this exchange a lot:
Asker: How do you do this in C?
Answer: Use the X library for C++.
Asker: OK, how about someone actually answer my question in C?
I use that term myself, and it is because it is my style, I don't use boost, stl or some other things, not even standard C++ libs, like "cout" and "cin", I program C but using classes, templates and other (non-library) features to my advantage.
I can say that I am not a master of C, neither a master of C++, but I am really good at that particular style that I use since 10 years ago. (and I am still improving!)
I was under the impression that all c code is valid c++ code.
Isn’t saying “C/C++” wrong?
No, it isn't. Watcom International Corporation for example, founded more than 25 years ago, called their set of C and C++ compilers and tools "Watcom C/C++", and this product is still developed and available in the open-source form as OpenWatcom C/C++
If it is a complex question needing to write more than one function, yes, it can be wrong.
If it is just to ask a detail about sprintf or bit manipulation, I think it can be legitimate (the latter can even be tagged C/C++/Java/C#, I suppose...).
Whoever is asking the question should write C, C++ or C/C++ depending on the question.
From what I've seen, you can write C++ code the C way or the C++ way. Both work, but C++ code that is not written C style is usually easier to maintain in the long run.
In the end, it all depends on the particular question. If someone is asking how to concatenate strings, than it is very important whether he wants C or C++ solution. Or, another example, if someone is asking for a qsort algorithm. To support different types, you might want to use macros with C and templates with C++, etc.
This was too long for a comment, so I had to make it an answer, but it's in response to Jeff B's answer.
Please remember that the original
implementations of C++ were simply as
a pre-compiler that output C code for
the 'real' compiler.
I have a friend (who writes C++ compilers -- yes, plural), who would take offense to your first sentence. A compiler whose object code is C source code is every bit as much a compiler as any other. The essence of a compiler is that it understands that syntax of the language, and generates new code based on that. A pre-processor has no knowledge of the language and merely reformats its input.
Remember that the C Compilers which would compile the output of those C++ compilers, would themselves output ASM code would would then be run through an assembler.
I tend to put C / C++ in my questions.
Typically I am looking for something that I can use in my c++ application.
If the code is in C or in C++ then I can use it, so I would rather not just limit the possible answers to one or the other.
Not only these two languages are different, but also the approaches are different. C++ is an OO language, while C is procedural language.
Do I have to mention templates?
Also, there are differences in C and C++ standards. If something is good in C, doesn't have to compile in C++