C++ instead of C[not what you think]

[pllaybuoy]

That's C#.net, there is also c++.net VC++

Alright , I am going to google that . Sorry for the misconception .

[lucid]

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

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.

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

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.

Indeed; everything you learn has a value.  Deque, you are fast becoming one of my favourite members.

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.

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.

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.

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.

First of all, thanks for taking the time to write that long and informative post. There's quite a bit of info in there.

Second, and I know this thread isn't about me keeping everyone updated about my life, but I realized I won't have enough money to take the programming classes. Which, actually excites me because I think I'm going to take Xires' recommendation of the bottom up approach. (ASM->C->C++). I've never heard anyone advocate it that way and the mere thought of learning ASM sooner than later literally makes me feel like a horny schoolgirl.

So thanks Xires for that input as well.

[rasenove]

Damn, i thought i was going to have a rivel here.  Im learning c++ and thats just what i wanted, good luck lucid. I guis ill have to compeet with someone els :p.

[bluechill]

Uhh...no?  You should know better than that.  Rephrasing is the very least of what needs to happen here.  The sheer level of interdependent structures involved with a system supporting all the complexity of every language means that it's impossible to correctly make such a statement.

...

I don't really note any change with void-pointer casting in C++ from C.  As well, your class-to-struct suggestion doesn't appear to emphasize your point as an example of C handling object-orientation.

So I made a simplification, however, if you start using C++ features such as OOP and advanced OOP then my statement is correct.  You could the the equivalent in C but it's just messy.  Now this is still a bit generalized and not always true so I shouldn't have generalized that much and it's a bit misleading but meh... And well try doing:

void* test = 1;

int* test2 = (int*)test; // This will not compile

int* test3 = static_cast<int*>(test); // Probably will compile.

Just one little nit pick, not really worth a mention in retrospect.

[Xires]

So I made a simplification, however, if you start using C++ features such as OOP and advanced OOP then my statement is correct.  You could the the equivalent in C but it's just messy.  Now this is still a bit generalized and not always true so I shouldn't have generalized that much and it's a bit misleading but meh... And well try doing:

void* test = 1;

int* test2 = (int*)test; // This will not compile

int* test3 = static_cast<int*>(test); // Probably will compile.

Just one little nit pick, not really worth a mention in retrospect.

I apologize for not being able to explain in appropriate detail.  I had a seizure a couple hours ago and am still in recovery.  I did at least want to respond since I don't want others getting confused when they come across it.

void* isn't used that way.

Code: (cpp) [Select]

#include <iostream>

int main(void) {
    void *t1 = 1;
    int *t2 = (int*) t1;

    std::cout << *t1 << " : " << *t2 << std::endl;

    return 0;
}


Code: (bash) [Select]

$ g++ -Wall -Wextra -W -ansi -pedantic -o cast_test{,.cpp}
cast_test.cpp: In function 'int main()':
cast_test.cpp:4:13: error: invalid conversion from 'int' to 'void*' [-fpermissive]
cast_test.cpp:7:16: error: 'void*' is not a pointer-to-object type

The error obviously points to the improper void* use.  Better usage below.

Code: (cpp) [Select]

#include <iostream>

int main(void) {
    int t0 = 100;
    void *t1 = &t0;
    int *t2 = (int*) t1;

    std::cout << *((int*) t1) << " : " << *t2 << std::endl;

    return 0;
}

This casting is the same between both C and in C++.  There is no difference just because STL gives us static_cast, dynamic_cast, const_cast, etc.  C++ just gives more options, per usual.

Traditional use below.

Code: (cpp) [Select]

#include <iostream>

void* func(void);

int main(void) {
    int *t1;

    t1 = (int*) func();

    std::cout << *t1 << std::endl;

    return *t1;
}

void* func(void) {
    static int test = 125;

    return &test;
}

C++ will do classic void* casting just like C.  There is no change, you just didn't do it right.

--
Now that I have a little more clarity, I'd like it to be known that I have the utmost respect for bluechill so comments like "you schooled him even after a seizure" are not welcome.  bluechill is a trusted and competent member of our staff and should be respected as such.  Not everyone can know everything and I myself have consulted bluechill for assistance more than once.

[bluechill]

I apologize for not being able to explain in appropriate detail.  I had a seizure a couple hours ago and am still in recovery.  I did at least want to respond since I don't want others getting confused when they come across it.

void* isn't used that way.

Code: (cpp) [Select]

#include <iostream>

int main(void) {
    void *t1 = 1;
    int *t2 = (int*) t1;

    std::cout << *t1 << " : " << *t2 << std::endl;

    return 0;
}


Code: (bash) [Select]

$ g++ -Wall -Wextra -W -ansi -pedantic -o cast_test{,.cpp}
cast_test.cpp: In function 'int main()':
cast_test.cpp:4:13: error: invalid conversion from 'int' to 'void*' [-fpermissive]
cast_test.cpp:7:16: error: 'void*' is not a pointer-to-object type

The error obviously points to the improper void* use.  Better usage below.

Code: (cpp) [Select]

#include <iostream>

int main(void) {
    int t0 = 100;
    void *t1 = &t0;
    int *t2 = (int*) t1;

    std::cout << *((int*) t1) << " : " << *t2 << std::endl;

    return 0;
}

This casting is the same between both C and in C++.  There is no difference just because STL gives us static_cast, dynamic_cast, const_cast, etc.  C++ just gives more options, per usual.

Traditional use below.

Code: (cpp) [Select]

#include <iostream>

void* func(void);

int main(void) {
    int *t1;

    t1 = (int*) func();

    std::cout << *t1 << std::endl;

    return *t1;
}

void* func(void) {
    static int test = 125;

    return &test;
}

C++ will do classic void* casting just like C.  There is no change, you just didn't do it right.

--
Now that I have a little more clarity, I'd like it to be known that I have the utmost respect for bluechill so comments like "you schooled him even after a seizure" are not welcome.  bluechill is a trusted and competent member of our staff and should be respected as such.  Not everyone can know everything and I myself have consulted bluechill for assistance more than once.

On Unix yes however on Windows (and this is what I was remembering) I ran into issues with using void* for threading and casting from them (generic argument passed) to a class pointer.  Apparently VS complains but I just tried some stuff in clang++ and g++ and it all works as you say.  So.... we're both right? Although really VS shouldn't complain but it did (at least in 2010 sp1).