What's better for coding, say, a server. Like a SOCKS server. C or C++? I'm guessing C and that makes me sad. See, right now I'm learning PHP/MySQL. I'm determined to stick with it because I've bounced around too much in the past year and I haven't gotten anywhere. But my ultimate desire is to learn C. In about 6 months I'm going to be taking programming classes and AFAIK they will be involving C++. I've often heard it's a bad idea to try to learn two languages at once and I REALLY wanted to focus on C after focusing on PHP/MySQL for the next 6 months but now it appears I'll be forced to learn C++. Not that that's a bad thing I had wanted to learn that eventually too, so if I took the class I would want to learn it but I wanted to learn C first..
I'm going in circles you get my point.
A server, including a SOCKS server, could be created in either language. Technically C++ would make certain things potentially much easier, depending on the service for which you're coding. Please keep in mind that sockets are still typically C-based and whilst there do exist pure-C++ impelementations, they're rarely used and almost never taught/permitted in classes.
Whilst I believe it best to learn C before C++, thousands of people have taken alternate routes and turned out just fine. Some elements may be a little more difficult to wrap your head around during the first iteration or two but it certainly doesn't make it impossible or even a 'bad' thing to learn C++ first.
I strongly recommend that you take the time to fully understand what it is that you're doing. When learning C++, take some extra time to learn a few of the details(though, no need to overload yourself) so that you can get a grasp of how and why it works. What you should be after, ultimately, is knowing the language well enough to predict how the computer will react to the statements that you input BEFORE actually asking the computer to do it(e.g. before compilation).
Well just like the name suggests C++ is meant to be supersede C.
Woah. Let me stop you right there for a second. Perhaps this was not the intention, but the term 'supercede' indicates the obsoletion of something. In this case, the statement denotes that with the invention of C++, C is obsolete. I assure you, such is most certainly NOT the case.
Perhaps, instead, you mean that C++ is a 'superset' of C. In a way, this is far more correct. Essentially, you take the C language and add a bunch of features to it to create additional language elements, syntax, constructs, etc. that provide a better 'fit' for certain applications(meaning 'uses', not 'programs'). This term fits C++ very well though it is not quite enough. C++ is indeed an independent language in its own right. This is evident in some ways with the addition of function overloading, the creation of vtables to support such a feature, and the resultant generated object code.
Most C code can be complied and run perfectly in C++ while the reverse isn't true, so learning C++ isn't that bad, and is quite possibly an advantage.
A C++ compiler can usually compile C code. The advantage is in the use of the C++ compiler, not in the language(not with this statement, anyway). If I were to create an interpreter that could interpret both Perl and Python code, it may be an advantage for my program..but not for 1 language or the other.
C is sometimes seen as a low level programming language and is faster than C++ which is why there are a lot of drivers are written in C. and C++ supports OOP and is in my opinion easier to understand than C. So i think transferring from C++ to C wont really be that much of a challenge.
C is not low-level. I admit that people these days do 'see' it as low-level, but it isn't. As for its speed; it really depends on what you're doing with the code. There are several instances where C++ actually performs faster than equally-optimized C. GCC 4.8 marks a full switch to C++ from C(meaning the compiler itself is now coded in C++) and benefits from a few performance enhancements as a result. Intel's C & C++ compiler have been C++-based for years and, whilst its own compilation speed may not be that fantastic by comparison, can produce very heavily optimized executables. C++ allows these compilers to use additional features in different ways to analyze code and apply optimizations in manners more difficult to do in C. Of course, this is not to say that it couldn't be done in C; only that, with the additional features, it is easier in C++.
I want to stick with PHP and MySQL mainly because I wanted an actual understanding of SQL injections work instead of taking the skid approach and just learning common SQL injection syntax, and the two languages are practically inseparable in my opinion. Plus I've already started learning PHP and I can't keep jumping between languages without actually learning anything. I plan to learn PHP/MySQL over the next six months until I start my programming classes.
If I am to understand this... Do you see C++ as taking a 'skid' approach? Perhaps because certain things may be easier in C++ than C? If this is so, please don't confuse 'difficult' with 'better'. Using Gentoo doesn't make one a more 'hardcore' Linux user(only, hopefully, a more patient one). Just because something is easier doesn't mean that it's a shortcut or excuse or some cheap way out.
Sounds reasonable.
I see your problem, but there is not much you can do. Just be patient. Everything you learn has a value. You don't do it for nothing.
Indeed; everything you learn has a value. Deque, you are fast becoming one of my favourite members.
I suppose you're right. The only reason I asked about coding a server by the way is because I know C is more for drivers and such and C++ more for games and whatnot, and I really have no interest in coding game-related stuff.
C is not necessarily more for drivers. C may be used more often for drivers than C++ but that is not necessarily because the language is better suited for the task. Of all the different operating systems that exist in the world, the vast majority of them are C-based. Some of this is because the code base existed prior to the popularization of C++. With C-based operating systems usually comes C-coded kernels and system libraries supporting a minimum C 'standard'(even if it's not fully 'standards-compliant'). This means that you are more likely to have an easier time coding something in C than in C++ as services for C++ may not be available within the lower levels of the OS code. Of course, once you create your own 'essential' OS component in C, you more or less force others that use it to also code in C. Thus, such a trend becomes de facto.
As for C++ being "for games". I think you can understand the error in the statement. Again, the language may more often be used for such a thing but that doesn't mean that there's any limitation either with the game field nor with the languages used. C++ has enjoyed much success in many areas, including servers. For example, InspIRCd is quickly becoming one of the most popular IRCd's available and it is written, to its core, in C++. There are webservers, mailservers, authentication systems, etc. that are all coded in C++. Whilst the C-based ones may be more popular and more common, it is not either language's fault.
EDIT: Ok one last question. Sorry it's kind of a noob one. I just want to know how long I'm going to have to wait to learn C. Because goddamnit I want to learn more low-level shit. My ultimate ultimate goal is to learn ASM. So when I started C I had planned to very slowly learn a little ASM along side it, like debugging and disassembling my own programs and shit.
I don't advise learning ASM along side C. ASM isn't really that 'difficult', per se, but it is certainly different. ASM will introduce quickly concepts that are likely to confuse someone who is just beginning in C. If you are already well familiar with ASM, it poses an advantage to learning certain parts of C. If you're already well familiar with C, learning ASM is merely understanding how C works in additional depth and thus the advantage plays into creating better C code. However, learning them at the same time leads one to try to tie both languages closely together and results in not understanding either one completely. You would be better to pick a direction; top-down(C++ -> C -> ASM) or bottom-up(ASM -> C -> C++). Whilst I personally advocate the bottom-up approach, it seems that your current path and experience would indicate it best to use a top-down approach instead.
As for how long it'll take; everyone is different. I know someone who learned C in as little as a week or two. I know someone else who learned it in 48 hours. I've known several others who took a year or more. I myself learned the essentials of C in about a month and then added to that understanding for years afterward. It was probably a decade before I noticed that I'd stopped seeing anything new. Everyone is a little different. Trying to measure it will only slow you down; just learn.
3 months to learn basic syntax, 2 more months to learn OOP(you could skip this cause C isnt OOP) and the Standard Template Library. after that transferring to C would take about 2-4 weeks although i really think you should stick with C++. I personally dont know long it will take to learn the low level stuff. i think learning ASM would be a living hell but once you do, i think you would make a really badass cracker 
I'm going to disregard indicated times since any accuracy would be entirely coincidental and should not be perceived as anything more.
Classroom environments tend to alter learning speed drastically; be it for better or worse. Object-orientation is possible in C. Saying "C isn't OOP" is simply incorrect, but few seem to understand that. Unfortunately, few classes teach STL adequately.
ASM really isn't a "living hell". As with most things, the syntax itself is finite and in the case of ASM, it's even more true. Once you understand the basic syntax and structure, every else is just reference/memorization. There are thousands of potential instructions that could be used in ASM. Many are common among different processors and even architectures. Many others are specific to just even a single model of a specific line of processors. You needn't memorize all of it. Just learn the basic syntax and find some good reference material.
The important thing to remember when writing in ASM is to PLAN your code. Plan it out, draw a flowchart, write a process flow, figure out how it's meant to work. Then step through each part of the plan and carefully determine what method you would prefer to use to accomplish that section. When you figure out the method, you use your reference material to find what would best be used to follow it. Then it's just a matter of repeating the process as necessary and putting the pieces together. The language itself is not difficult. The discipline involved in becoming good at it is a different matter.
I suppose so. I mean, it's not like I wasn't planning on learning C++ at some point, I just wanted to do C first because I hear it's a better idea. Oh well, I guess there's nothing I can do. I guess I could learn C++ through all the classes I'm going to take and then when I'm done I can switch to C and ASM.
Cool.
Whilst it is best to learn C prior to C++, what matters is that you're learning. As previously mentioned, many people have gone from C++ to C and turned out fine. Many others have gone from C++ to Java to C# to Objective-C and then, somehow, to C. Some people never learn C. Walking the correct path is more important than choosing the correct entrance.
Again, don't do C and ASM together.
