Massassi Forums Logo

This is the static archive of the Massassi Forums. The forums are closed indefinitely. Thanks for all the memories!

You can also download Super Old Archived Message Boards from when Massassi first started.

"View" counts are as of the day the forums were archived, and will no longer increase.

ForumsDiscussion Forum → Learning C++
123
Learning C++
2007-06-04, 7:23 AM #41
The question you should ask yourself is "do I want to learn the intricacies of a language that was the preferred development platform during the 90's, or do I want to learn how to develop applications quickly, elegantly and efficiently?" If it's the former, learn C++. If the latter, C#.
Dreams of a dreamer from afar to a fardreamer.
2007-06-04, 7:54 AM #42
Originally posted by Brian:
:words:

And this is why Linux will never really become a contending OS, the Linux userbase. Refusing a technology that's well established because Microsoft invented it is perhaps the dumbest idea ever. Seriously, if Linux people stick only to C/C++ and Perl, it's going nowhere fast. An OS is useless w/o applications to run on it. Mono is indeed robust. I've used it. The C# compiler is quite solid. All that is left really is just to implement .NET 2.0. Yes .NET 3.0 and even 3.5 are out but they are still 1-2 years from seeing wide-scale implimentation. That gives Mono some catch-up time. FYI, developing an application for QT/KDE or Gnome in C++ isn't that easy too. I'd argue that it's easier than using MFC, but not by a whole lot.
Code to the left of him, code to the right of him, code in front of him compil'd and thundered. Programm'd at with shot and $SHELL. Boldly he typed and well. Into the jaws of C. Into the mouth of PERL. Debug'd the 0x258.
2007-06-04, 8:34 AM #43
Originally posted by West Wind:
lots of words implying the UNIX world is significant in application development
No.

1.) GCC isn't just a "compiler collection." GCC is more of a compiler system, with a frontend (which processes a source file and produces an intermediate language output) and a backend (which converts the intermediate language output into machine code for the specified host).

2.) The only reason you should be using GCC/MinGW/family under Windows is if you use inline assembly and you need AT&T syntax. Visual C++ code is faster - I think the only better compiler is ICC, and only then on Intel (non-AMD) processors. GCC is easily the worst compiler you can choose if you are writing a C++ game. Remember what I said about using the right tool for the right job?

3.) You aren't going to learn anything valuable or worthwhile by mucking around with the GNU toolchain. You can learn make inside and out and you aren't going to see any benefit in 99.9999% of situations.

4.) You don't need GNU toolchain magic in order to use SVN or CVS. In fact, they work just fine with Visual Studio projects or even with plain text.

5.) Preprocessor macros are ridiculously Bad Coding Style and a large amount of the C++ spec was added to stop people from using them (templates, const, inlining). What does the preprocessor have to do with anything, anyway? Both C# and C++ (as I mentioned) offer language features designed to eliminate the problem that macros "solve."

6.) There is no GNU toolchain support for C# because the GNU toolchain does not satisfy the needs of C#. The GCC frontend takes in a source file and converts it into an intermediate language object. The GCC backend takes the intermediate language and converts it into a machine code object file for the specified host. The linker collects those object files and produces a binary (a.out, elf, coff, pe, whatever). It's the textbook compiler design.

With C# you take in source files (a single source file is syntactically meaningless in the scope of an entire assembly) and... produce a Common Intermediate Language file. That's it.

You don't really know what C# does. That's fine, I don't expect anybody to automatically know these things, but I do wish you had stayed that particular bit of criticism since it's very far off base. This is a lot like asking why you can't use a car factory to build submarines.

7.) GDB does not work with C# for the same reason.

8.) Visual Studio is free and it's better. If you are developing a Windows game and you pass up Visual Studio in favor of Dev-C++ and GCC/MinGW... well... you're daffy. Besides, you tried to say that the GNU toolchain is the 'standard tool of the trade' which is just completely untrue. Bolded for emphasis (so if you avoid reading the rest of the post you can at least read this): Visual Studio is the standard tool of the trade for PC game development.

9.) What is an Old School-style programmer? Is it the kind of programmer that invented null-terminated strings? Please explain in a 5 paragraph essay.
2007-06-04, 11:23 AM #44
You can be an Application Developer and know absolutely nothing about GCC or Unix software Development. You can probably even manage to be an OK Software Engineer. But if you want to be an actual Programmer and have a conceptual understanding of the code you are writing from the very top to the very bottom, then you absolutely must be familiar with Unix Development tools. (there is one exception to this, which is where you have access to Microsoft’s private development tools and source code, but I don’t think most of us fall into that category).

1.) GCC is a modular compiler collection, just look it up. Sure you can break it down in the many Compilers, the Assembler, the Linker, and all the other individual modules that can be invoked separately or re-configured on the fly, but I don’t see how that changes anything.

2.) How about wanting to develop platform independent code on a windows machine? Or utilizing the tremendous body of open source software that has not yet been ported to Win32 yet. Or running an X Windows Server locally. Or using industry standard connectivity and security tools? Also, Cygwin does not use MinGW libraries, its default build makes use of the Cygnus libraries, hence the name.

3.) Oh, so the ability to make a large self configuring cross platform program or package is only relevant 0.0001% of the time? Wow, I must be living a very improbable life. As for what you can learn from mucking around with the GCC toolchain, well, lets see. Object code, linking methods, optimization levels (and tradeoffs)…

4.) Your right, and I even said that in my post. Nothing special about SVN or CVS, except that you probably do need to know how to use it, windows or unix.

5.) WTF. Using Preprocessor Macros is usually #2 on the List of top 10 ways to improve your code, right after proper commenting. Sure you can abuse Preprocessor Macros (especially under C), just like everything else, but if they are so bad, then tell me why the C# developers felt the need to include a fully functional Preprocessor?

6.) There is no reason why GCC can’t stop at intermediate object code. Hey, GCC can even produce portable Java Bytecode if you want.

7.) Very true, and quite a pity considering how useful GDB is, but I guess if you want to just stick with Visual Studio’s Debugger, you can.

8.) Ok, you got me on a rough topic change here. I agree, developing Windows Games under a Cygwin/GCC dev environment is stupid. Very Very Stupid. Windows Games I was recommending he use Python. But if he wanted to learn C++ and gain more in-depth knowledge, then Cygwin is the perfect environment.

9.) Five Paragraph essay will come later, when I’m not at work. But an Old School-Style Programmer is the kind of Programmer who can tell you both the advantages and disadvantages of Null-Terminated Strings and know exactly how to use them safely each and every time. An Old School-Style Programmer is the kind of Programmer who could, if he ever wanted to, could figure out every single step involved in a system call, and who can actually understand and explain the low level state of the system before and after every single one. Are Old School Programming skills absolutely necessary in this day and age? No, but Trust me when I say they help allot. (and no, I’m not yet a full Old School Programmer, but I’m not afraid to keep learning old languages and OS’s just because someone can say that there is something newer and better available)
"Well, if I am not drunk, I am mad, but I trust I can behave like a gentleman in either
condition."... G. K. Chesterton

“questions are a burden to others; answers a prison for oneself”
2007-06-04, 11:59 AM #45
Originally posted by West Wind:
You can be an Application Developer and know absolutely nothing about GCC or Unix software Development. You can probably even manage to be an OK Software Engineer. But if you want to be an actual Programmer and have a conceptual understanding of the code you are writing from the very top to the very bottom, then you absolutely must be familiar with Unix Development tools. (there is one exception to this, which is where you have access to Microsoft’s private development tools and source code, but I don’t think most of us fall into that category).

...Microsoft's private development tools? Microsoft uses Visual Studio and MASM like the rest of us lowlifes, mang.

Quote:
1.) GCC is a modular compiler collection, just look it up. Sure you can break it down in the many Compilers, the Assembler, the Linker, and all the other individual modules that can be invoked separately or re-configured on the fly, but I don’t see how that changes anything.
what did I say? :confused:

Quote:
2.) How about wanting to develop platform independent code on a windows machine? Or utilizing the tremendous body of open source software that has not yet been ported to Win32 yet. Or running an X Windows Server locally. Or using industry standard connectivity and security tools? Also, Cygwin does not use MinGW libraries, its default build makes use of the Cygnus libraries, hence the name.
I know what Cygwin is.

As long as you aren't using inline assembly (because Microsoft and Intel use the Intel syntax, while GCC uses AT&T syntax) your code will be cross-platform. This is why standards exist.

I would also like to definitively state that it'll be easier to port a well-written standards-conscious app to the GNU toolchain after completing it with Visual Studio, since hitting Ctrl+Shift+A to add a new source file is decidedly more convenient than having to crack open your makefile in vim.

Quote:
3.) Oh, so the ability to make a large self configuring cross platform program or package is only relevant 0.0001% of the time? Wow, I must be living a very improbable life. As for what you can learn from mucking around with the GCC toolchain, well, lets see. Object code, linking methods, optimization levels (and tradeoffs)…
See above.

Also, GCC is far from the only compiler that uses configurable linking options and optimization levels, and the majority of the command line switches are even shared amongst GCC, ICC and CL. This is to the extent that you can even use ICC and CL as a drop-in replacement for GCC (which is useful if you wanted to, for instance, use DISTCC with a Visual Studio project).

Quote:
5.) WTF. Using Preprocessor Macros is usually #2 on the List of top 10 ways to improve your code, right after proper commenting. Sure you can abuse Preprocessor Macros (especially under C), just like everything else, but if they are so bad, then tell me why the C# developers felt the need to include a fully functional Preprocessor?


Yeah, improve your code by getting rid of them. I don't know where you got the idea that preprocessor macros are good but they aren't. They make your code more complex, less readable, less machine-readable (which is important for things like code completion), they don't offer invocation-time type safety (go go BIGINTEGER(x, y) macro that lets you mash together two floats just as easily as two integers) and... as I have already said... C++ already gives you better, more readable options.

Also, the C# preprocessor is not like the C preprocessor. You cannot write macros with C#. It isn't even technically a preprocessor - directives are handled during tokenization.

#using is a compiler hint (to tell it what namespaces to look under)
#region/#endregion is used by Visual Studio for readability.
#warning, #error - again, used by the compiler to emit a specific error
#line forces the compiler to use a specified line number and code file (code generation programs like parser generators would use this)
#define, #undef, #if, #elif, #else, #endif, etc. - closest it gets to C++, and they're still only used for things like "#ifdef DEBUG" and "#if XBOX".

Quote:
6.) There is no reason why GCC can’t stop at intermediate object code. Hey, GCC can even produce portable Java Bytecode if you want.
As far as I know, only GCJ can produce portable Java bytecode. Optionally. I guess there's no real reason a GCSharp compiler couldn't produce either GCC IL or CIL but that would defeat the purpose, wouldn't it?

Quote:
7.) Very true, and quite a pity considering how useful GDB is, but I guess if you want to just stick with Visual Studio’s Debugger, you can.
Yeah, it's a pity you'd be stuck with Visual Studio's debugger seeing as how it only manages to be as feature-rich and capable as GDB, with support for edit and continue, and is only integrated directly into the IDE so you can visually step through a program while looking at your original code without having to use a command line tool.

Quote:
8.) Ok, you got me on a rough topic change here. I agree, developing Windows Games under a Cygwin/GCC dev environment is stupid. Very Very Stupid. Windows Games I was recommending he use Python. But if he wanted to learn C++ and gain more in-depth knowledge, then Cygwin is the perfect environment.
You'd recommend Python for Windows game development? If you're going to recommend it for game development at least be consistent, because Python is just as good on Linux as it is on Windows and that'd be its main advantage.

Quote:
9.) Five Paragraph essay will come later, when I’m not at work. But an Old School-Style Programmer is the kind of Programmer who can tell you both the advantages and disadvantages of Null-Terminated Strings and know exactly how to use them safely each and every time.
Welp, this programmer has never existed.

IIRC, the first documented buffer overflow exploit was on UNIX. Old versions of UNIX had a 128 character limit on filenames (not including null terminator) while the file manipulation functions in the old LIBC used a fixed 128 character buffer. Not even the people who invented the idea fit the description you gave.

Software programming is a massive discipline and there is specialization. You can't be good at everything. If you want to be an OS programmer then you might be worried about interrupts (what you probably meant when you said "system call"), but knowing how to write bare metal code or switch into protected mode or write a scheduler doesn't mean you're going to be sod all good at writing a game or a text editor.
2007-06-04, 12:25 PM #46
Originally posted by West Wind:
5.) WTF. Using Preprocessor Macros is usually #2 on the List of top 10 ways to improve your code

:suicide:

Here is some code from the original Bourne shell for UNIX:
Code:
#define IF    if(
#define THEN    ){
#define ELSE    } else {
#define ELIF    } else if (
#define FI    ;}

#define BEGIN    {
#define END    }
#define SWITCH    switch(
#define IN    ){
#define ENDSW    }
#define FOR    for(
#define WHILE    while(
#define DO    ){
#define OD    ;}
#define REP    do{
#define PER    }while(
#define DONE    );
#define LOOP    for(;;){
#define POOL    }

:gonk:
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-06-04, 12:35 PM #47
Also, Dev-C++ is horrible. The CDT plugin for Eclipse actually makes a half-decent C/C++ IDE, and Code::Blocks is even better.
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-06-04, 12:44 PM #48
Originally posted by West Wind:
5.) WTF. Using Preprocessor Macros is usually #2 on the List of top 10 ways to improve your code, right after proper commenting. Sure you can abuse Preprocessor Macros (especially under C), just like everything else, but if they are so bad, then tell me why the C# developers felt the need to include a fully functional Preprocessor?

You have yet to write and debug MFC code. It is a ****ing nightmare because MFC loves the macros. ON_COMMAND(), ON_WM_PAINT() Ugh.
Code to the left of him, code to the right of him, code in front of him compil'd and thundered. Programm'd at with shot and $SHELL. Boldly he typed and well. Into the jaws of C. Into the mouth of PERL. Debug'd the 0x258.
2007-06-04, 12:53 PM #49
Originally posted by Emon:
Here is some code from the original Bourne shell for UNIX:


because the guy who wrote it was used to writing code in ALGOL and thought it was a good language.

funny how things like that keep happening.


Edit: Oh, that reminds me. Did you know that in BCPL (the original 'draft' for a C type language) the assignment operator was :=? This used to be a standard convention in programming languages, since it was felt that just using '=' would lead to typos where the programmer had intended to use a comparison operator (==) but used the assignment operator instead.

B was designed to fit into the memory limitations of a PDP-7 (as I said). Among other things, it removed the preceeding colon because Ken Thompson thought that saving 1 byte was worth losing an important safety net.

This is even more :awesome: when you remember that C never had any type safety - everything is an integer - so something like that would silently fail. This behavior was deliberately retained for C++ for compatibility reasons (everything is 'true'). Silent failure = bad language.
2007-06-04, 2:33 PM #50
geez, WestWind... I might still use C++, but at least I use standard containers and smart pointers.

Quote:
I've done a lot of lisp too.
I just realized I said that like it was some sort of drug.
Wikissassi sucks.
2007-06-04, 2:54 PM #51
It might as well be. [http://img364.imageshack.us/img364/7733/emotdownsrimeq9.gif]
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-06-04, 3:04 PM #52
All my lisp programs ended with the same line of code.

Quote:
)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
Wikissassi sucks.
2007-06-04, 3:27 PM #53
((((((((((Scheme))))))))))
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-06-04, 5:20 PM #54
I find it amusing that this was just posted less than a Week ago on Slashdot, Six Ways to write more comprehensible code. Go take a look especially at #2 (and you might as well read the rest of it while your at it, who knows what you might learn :P

I also decided to dig through some code I had standing around. Go ahead and tell me what this does, it’s not that hard, I won’t even change the variable names:

Code:
*(size_t *)(char *)(bp) = ((size)|(alloc))


It writes the block headers for a very rudimentary Malloc

Now, compare the above code with this:

MAKE_HDR(bp, size, alloc)

Which is easier to read?

Now quite often your right, complex pre-processor macros are better off as functions. There are exceptions, but not many. But do you honestly want to tell me #define is not a pre-preocessor macro? Can you imagine a world without #ifdef?


As for python, yes I recommend python specifically for windows Game development. Sure there is the added plus that its equally easy to develop Linux or MacOS games in Python, but that not my main reason for recommending it. I recommend it because of the exemplarily online documentation, robust module libraries, and large active community.


Now, for the Old School-Style Programmer, sure they exist, I know quite a few of them of them.
One of them is a burnt out old hacker, one of them is fellow student who has a soft spot for perl, One of them is a large hairy man who couldn’t find his left hand without his wife to show him where it was…

I could go on, but what ties them all together is that they took the time to understand what they were doing, and learn to do things the right way. None of them code bare-metal stuff. I’ve probably done more bare-metal coding that the most of them combined, but they can still explain it all to you conceptually. You can sit there writing Groovy, the “latest and greatest” programming language (I am intentionally satirical here), not know a thing about how x86 handles virtual memory, and write code that is just fine. But someone who understands the system better will simply have the recourses to write better code. And someone who takes the time to learn the concepts behind computing in general (which while a daunting task, is far from insurmountable for anyone willing to spend a little time one it) will find that learning new languages and even new programming paradigms significantly easer.

Finally, GCC does not have a monopoly on being feature rich or useful. I even said that when I first brought it up. And the fact that Visual C++ has graphical debugger and shortcut keys means jack beans. GCC can be configured with all these things (DDD and Xemacs if you so desire), but this isn’t a feature race. It’s simply about what’s used, what’s expected, and what’s taught. And from what I’ve seen, hands down that’s Unix programming. Furthermore, it makes sense. Once someone knows how to write good code using the Unix Dev tools, they can go right ahead and start making games in C# using MS’s latest version of Visual Studio, but they will still have the advantage of KNOWING and UNDERSTANDING instead just going through the motions.

(also FYI, system calls are a class of interrupts, but they are unique in that their calling sequences are usually much more complex than normal interrupt routines, so when I said system call, I meant system call.)
"Well, if I am not drunk, I am mad, but I trust I can behave like a gentleman in either
condition."... G. K. Chesterton

“questions are a burden to others; answers a prison for oneself”
2007-06-04, 6:10 PM #55
Originally posted by West Wind:
blah blah blah blah


do you just not understand that joncy > you. END OF STATEMENT
joncy knows what he's talking about. srsly.
free(jin);
tofu sucks
2007-06-04, 6:27 PM #56
Originally posted by West Wind:
It’s simply about what’s used, what’s expected, and what’s taught. And from what I’ve seen, hands down that’s Unix programming.

You seem to have been confused into thinking that UNIX development somehow represents a large portion of the market and employment positions.
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-06-04, 6:38 PM #57
Originally posted by landfish:
do you just not understand that joncy > you. END OF STATEMENT
joncy knows what he's talking about. srsly.


Eh, why bother stopping this? It's interesting to read.
2007-06-04, 6:45 PM #58
Originally posted by West Wind:
I find it amusing that this was just posted less than a Week ago on Slashdot, Six Ways to write more comprehensible code. Go take a look especially at #2 (and you might as well read the rest of it while your at it, who knows what you might learn :P


Uh, I'll learn that Jeff Vogel doesn't know how to use C++ properly?

Code:
#define PIXEL_WIDTH_OF_PLAY_AREA	800


serves the same purpose as

Code:
static const unsigned int PIXEL_WIDTH_OF_PLAY_AREA = 800


except defines are:

1.) Not limited to a scope,
2.) Interpreted by the compiler as a literal (cannot be used efficiently for non-integral types)
3.) Lacking in safety nets (i.e., a const actually is constant unless the const-ness is explicitly cast away - a define can be changed arbitrarily by any arbitrary code file including code written later and by other users)

Furthermore, the article you linked to doesn't mention preprocessor macros at all, but I will because you seem to enjoy them for some unexplainable reason:

4.) Preprocessor macros do not have any inherent type safety prior to preprocessing which means it's very difficult to guarantee correct behavior when the situation isn't absolutely predictable.

Quote:
Now, compare the above code with this:

MAKE_HDR(bp, size, alloc)

Which is easier to read?
That's super. If I know what MAKE_HDR means the macro is a lot more readable, but are you seriously suggesting that your macro is preferable to an inlined function? You are using C++, right? If you're using C it's forgivable, but if you're using C++ it simply is not.


Quote:
Now quite often your right, complex pre-processor macros are better off as functions. There are exceptions, but not many.
What exceptions are those? An inline function compiles down to exactly the same code as a preprocessor macro unless the optimizer is deliberately set to ignore inlining. The exact same thing can be said of templates and static, global or function constants.

Quote:
Finally, GCC does not have a monopoly on being feature rich or useful. I even said that when I first brought it up. And the fact that Visual C++ has graphical debugger and shortcut keys means jack beans. GCC can be configured with all these things (DDD and Xemacs if you so desire), but this isn’t a feature race. It’s simply about what’s used, what’s expected, and what’s taught. And from what I’ve seen, hands down that’s Unix programming. Furthermore, it makes sense. Once someone knows how to write good code using the Unix Dev tools, they can go right ahead and start making games in C# using MS’s latest version of Visual Studio, but they will still have the advantage of KNOWING and UNDERSTANDING instead just going through the motions.
Again: are you seriously so ignorant about Visual Studio that you seriously believe this?

I don't want to repeat myself but I guess I'll have to: Visual Studio does everything that the GNU toolchain does (although lacking in architecture support).

Microsoft uses the exact same tools to make all of their software that they sell in the big box. Or, rather, I guess it's a plexiglas hinged sliding case thing now. Whatever. My point is, Visual Studio is every bit as robust a development toolchain as the GNU toolchain - if you know how to use it (the same exact caveat you keep using for GCC) - and it comes with an IDE that is actually... like... good. Are you saying that the tools used to develop Windows, Visual Studio, Microsoft Office, IIS, the .NET Framework, virtually all Windows applications, Windows drivers, Xbox and Xbox 360 games, and DirectX are not adequate?

And to really push this, even the executable format produced by Visual Studio is called PE, a format derived from COFF which is a UNIX executable format. Not a huge surprise, is it? Microsoft started with XENIX and they worked on OS/2 - Visual Studio is in the UNIX toolchain lineage!

Quote:
(also FYI, system calls are a class of interrupts, but they are unique in that their calling sequences are usually much more complex than normal interrupt routines, so when I said system call, I meant system call.)
hahaha, what? a system call is not an interrupt. afaik you'd typically use a software interrupt to implement them (since you'd use it for marshalling program access to privileged code) but I admit it's been a while. I'm 99% sure a syscall is not an interrupt though!
2007-06-04, 7:22 PM #59
I still find this thread amusing. Are you guys seriously contending that you can program a game in C# on linux and it will also compile on windows and perform similarly on both platforms? You also seem to be reading a lot into what I'm saying. I'm not saying everything made by MS is bad. But MS is all about vendor lock-in. Further, a 12MB distributable runtime isn't exactly an ideal way to get people to use the typical 3MB application.

Blah blah about linux. I never contended that linux would be a great desktop. Or that somehow linux should compete with windows. Or even that I somehow think everyone should be using linux. I never said any of that.

What I did do was answer the original poster's question. Instead of going off on some religious war about how C# is the be-all and end-all of greatness (which is a load of bull). For every one programmer that switches over to .NET there's another one leaving the MS platform and going open source. Trust me, commerical software companies HATE IT when the underlying technologies change and require extensive reworking to get existing code working (or converting existing code to take advantage of pointless new features so it matches the windows "look and feel" but does nothing "real" for the user experience).

Quote:
It is "educated" in that there are a number of very smart, experienced, qualified and educated people posting advice in this thread. You are not one of them.
Emon, it's very funny you should say that. How many years experience programming commercial, distributable applications do you have again? How many multi-million and multi-billion dollar pharmaceutical companies use software you are lead developer on to manage their sequencing labs? Exactly how many real software companies have you worked for in your life, and do you have anything to show for it? Or are you simply a forum troll who has an opinion about everything with no real experience to back it up?

As I have said in the past, the language one chooses to get a job done does not make or break a programmer. Languages can suck, but can be used for good projects. Different languages are good for different things, but apparently that's not the case anymore, as MS has invented Java (oh wait .NET) and therefore we should all bow down to the best programming language ever and throw away all existing software and rewrite it in Java (oh wait .NET). :rolleyes:
2007-06-04, 7:42 PM #60
Originally posted by Brian:
I still find this thread amusing. Are you guys seriously contending that you can program a game in C# on linux and it will also compile on windows and perform similarly on both platforms?
Yes. Seriously, it will. There are feature-complete bindings for OpenGL, OpenAL, SDL, ODE... pretty much every opensource game development library.

Novell's JIT may not be 100% as fast as Microsoft's but it doesn't really matter (strictly speaking). Games spend a lot of time waiting on the video hardware (especially when vsync is enabled), so this is even more true for games than any other kind of application.

Quote:
Different languages are good for different things, but apparently that's not the case anymore, as MS has invented Java (oh wait .NET) and therefore we should all bow down to the best programming language ever and throw away all existing software and rewrite it in Java (oh wait .NET). :rolleyes:
.NET isn't a programming language.

The CLR may have been based on Microsoft's Java JIT but the technologies they built on top of it are very different and far more robust than anything Sun ever did with Java. Also, as I've already mentioned in this thread, Microsoft has developed variants of C# for systems programming (Sing#) and integrated database querying (C-Lower-Case-Omega).

Also, I know you said you aren't discounting .NET just because it's Microsoft, but it really seems like you are.
2007-06-04, 7:52 PM #61
Originally posted by Brian:
Emon, it's very funny you should say that. How many years experience programming commercial, distributable applications do you have again? How many multi-million and multi-billion dollar pharmaceutical companies use software you are lead developer on to manage their sequencing labs? Exactly how many real software companies have you worked for in your life, and do you have anything to show for it? Or are you simply a forum troll who has an opinion about everything with no real experience to back it up?

Working in the industry for years doesn't mean you know what you're talking about. It's an appeal to authority fallacy. And no, I have little real world experience, yet somehow, I manage to know what I'm talking about. Maybe it's because I don't blindly dismiss technologies based on who they were made. I also don't dismiss things that I have never made an effort to learn about.

Originally posted by Brian:
and therefore we should all bow down to the best programming language ever and throw away all existing software and rewrite it in Java (oh wait .NET). :rolleyes:

No one suggested anything of the sort. I really shouldn't have to do this, but while I'm at it I might as well point out the logical fallacy in this argument as well. Strawman fallacy.
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-06-04, 8:12 PM #62
Jon’C.

I would like to ask you a favor, and I mean this in all honestly.

Put yourself in the following hypothetical situation. You’re a programmer, you know a handful of languages pretty darn well, are competent in several more, and know you can pick up anything else you need to in a reasonable period of time. You have never really had any problems writing the code you need to with your current resources. Now, without using any buzzwords or feature-waving, tell me why you, as this simple programmer, should be necessarily interested in C#? Also, from the same point of view, can you point out several significant (non buzz-wordy or feature-istic) ways in which C# is different from J++?
"Well, if I am not drunk, I am mad, but I trust I can behave like a gentleman in either
condition."... G. K. Chesterton

“questions are a burden to others; answers a prison for oneself”
2007-06-04, 8:17 PM #63
Are you saying language features are not important when comparing languages? :confused:

To be honest, West Wind, I'm really getting the feeling that you know nothing about C#. Which is okay, but not if you're going to be arguing against its use. I don't mean that to be offensive, it's just really seems like you glanced at it once or twice and that's it.
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-06-04, 8:23 PM #64
On the contrary, in my original message I implied that he should choose C# based on the number of people on this thread attempting to help him.

Personally, I have two things going on:

1. Work. I don't have a choice in language, that was decided 10 years ago.
2. Home projects. Currently working on a web site and I'm using perl. I'm using perl because I'm very familiar with it, it gets the job done, it's free, and mod_perl is very, very fast. I have no reason to try to use mono for this project, that will increase the development time significantly because I don't know C# and I don't like Java. So not only would it be a development project, but also a learning project, which I'm not interested in at this time.

Also, everyone says C# and .NET are portable and cross-platform. I'm not buying it. Okay, so some people and companies are working on it. They're going to be playing catch-up with MS until the end of time, because that's what they're doing - waiting till MS publishes a spec and whatnot and then programming to it. Do they have any say in the direction of the software? Regardless, everyone says it's not there yet, so it doesn't make sense at this point to pick it.
2007-06-04, 8:26 PM #65
Emon, I would just like to point out that you're the one who brought up "experienced, qualified and educated," not me. You can go on about fallacies all day long, just remember I'm responding to your argument. I never would have asked you about your experience had you not outright said that I don't have any. Also, you may try reading my posts once in a while instead of skimming, finding one misquote to latch on to, and then trying to make me out to be a linux zealot.
2007-06-04, 8:27 PM #66
Originally posted by Brian:
Do they have any say in the direction of the software?

If they wanted to, but that's not the goal of Mono. Someone could fork it if they wanted to.
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-06-04, 8:29 PM #67
Originally posted by Brian:
I never would have asked you about your experience had you not outright said that I don't have any.

I didn't mean to say that you didn't have any experience, only none that applies to the discussion at hand. And since you seem to think that .NET is the same thing as Java, it's clearly true.

Originally posted by Brian:
Also, you may try reading my posts once in a while instead of skimming, finding one misquote to latch on to, and then trying to make me out to be a linux zealot.

What? I took what arguments I thought to be invalid and replied to them.

Originally posted by Brian:
Also, everyone says C# and .NET are portable and cross-platform. I'm not buying it. Okay, so some people and companies are working on it.

That's kind of all we're saying. You suggested that C# absolutely locks one into Microsoft and Windows, which just isn't true.
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-06-04, 8:32 PM #68
Originally posted by Emon:
I didn't mean to say that you didn't have any experience, only none that applies to the discussion at hand. And since you seem to think that .NET is the same thing as Java, it's clearly true.


In defense of Brian, it's pretty clear he's aware Java and .NET are different. What he's doing is satirizing the end-all-be-all platform, which both eek toward.
"it is time to get a credit card to complete my financial independance" — Tibby, Aug. 2009
2007-06-04, 8:36 PM #69
Of course he's aware they are two different entities, he just really seems to be implying that they are almost identical technologies.
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-06-04, 8:45 PM #70
Believe it or not; yes. For the most part I consider features secondary when choosing a language. My primary consideration it’s its suitability for the job at hand, existing code, compatibility issues, and what languages other programmers on my team might be familiar with.

I also find, especially with newer languages, people tote around features and forget about everything else. So no, I don’t want C#’s feature list. I can look that up. I want to know, short and concise, why C#?

Also, your right, I don’t know allot about C#. I’ve watched it from a distance, and listened as friends gave it a try, but I just don’t have time to go out a learn a language I see no immediate need for. And it probably going to stay that way. Not because I have something against C# or Microsoft. But because where I’m working right now, there is exactly zero chance of me coming into a project where C# is even an option.

I also want to make this clear. I am not saying that C# has no place, or that no one should be using it. But what I am saying is that like almost all young languages, its roots are shallow and it’s future unclear. Given the chance I would rather recommend a young programmer peruse a more mature and deeply developed language. From where I stand, if you just want to write code that does something, Python is your choice language. If you actually want to learn to be a good programmer, C++ seems to me to be the strongest choice by far.

And guess what. I might be wrong, I might be very wrong. I’m no master hacker. But I’ve hade far more that my share of coding experience. I’ve also seen some unique things. I’ve watched a multi-million dollar startup company flop from the inside, and choice of language played more than a significant part in its failure.

I just want to ask this again: Why C#? I’ve heard all the buzzwords before, and almost all of them were used to describe J++.
"Well, if I am not drunk, I am mad, but I trust I can behave like a gentleman in either
condition."... G. K. Chesterton

“questions are a burden to others; answers a prison for oneself”
2007-06-04, 8:50 PM #71
Originally posted by West Wind:
Jon’C.

I would like to ask you a favor, and I mean this in all honestly.

Put yourself in the following hypothetical situation. You’re a programmer, you know a handful of languages pretty darn well, are competent in several more, and know you can pick up anything else you need to in a reasonable period of time. You have never really had any problems writing the code you need to with your current resources.
...the fact that you imply this is a hypothetical situation edges pretty close to an ad hominem but I'll let it go since I don't think you have the proficiency to gauge whether or not someone is knowledgable in this field. (...preprocessor macros? really?)

Quote:
Now, without using any buzzwords or feature-waving, tell me why you, as this simple programmer, should be necessarily interested in C#? Also, from the same point of view, can you point out several significant (non buzz-wordy or feature-istic) ways in which C# is different from J++?
I'm honestly not familiar with whatever extensions Microsoft made in J++. I'm also honestly not sure how you think I'm supposed to extoll the virtues of C# if I'm not allowed to bring up things like "features" so I don't think I'm going to bother. If you're legitimately interested in learning the differences between C#/.NET and Java there are a trillion articles about it scattered across the internet but since you're probably going to continue misrepresenting C# as a Java clone regardless of what anybody says I think I'm just going to cut out the middleman.
2007-06-04, 9:00 PM #72
Originally posted by West Wind:
I also find, especially with newer languages, people tote around features and forget about everything else. So no, I don’t want C#’s feature list. I can look that up. I want to know, short and concise, why C#?

C# is becoming a widely used language. Businesses are adopting it like mad. It has a quick deployment time and is very maintainable. C# is very capable of weeding out bad programmers. You don't have to do fancy pointer arithmetic to be considered a good programmer. Good programmers design their programs with the greatest efficiency. It doesn't matter if you use C, C++, or C#, if you write algorithms that are no better than O(n[sup]2[/sup]), you downright suck.

Quote:
I also want to make this clear. I am not saying that C# has no place, or that no one should be using it. But what I am saying is that like almost all young languages, its roots are shallow and it’s future unclear. Given the chance I would rather recommend a young programmer peruse a more mature and deeply developed language. From where I stand, if you just want to write code that does something, Python is your choice language. If you actually want to learn to be a good programmer, C++ seems to me to be the strongest choice by far.

I seriously think that C++ is on it's way out. C# is growing in popularity by leaps and bounds. C and C++ are old.
Quote:
And guess what. I might be wrong, I might be very wrong. I’m no master hacker. But I’ve hade far more that my share of coding experience. I’ve also seen some unique things. I’ve watched a multi-million dollar startup company flop from the inside, and choice of language played more than a significant part in its failure.

C# maybe young but it is very robust and well-established language. It is easily maintainable and has not that steep of a learning curve. Microsoft basically put A LOT of their business on the line. If C# and .NET utterly flopped, MS would be in biiiiig trouble. One of my coworkers went from no .NET/C# experience to well-versed in a year
Code to the left of him, code to the right of him, code in front of him compil'd and thundered. Programm'd at with shot and $SHELL. Boldly he typed and well. Into the jaws of C. Into the mouth of PERL. Debug'd the 0x258.
2007-06-04, 9:04 PM #73
[Edit] This is in responce to Jon'C, not JediGandalf [/edit]
Tell me what you've done with it. Compare the .Net library to those in other languages. Talk about how useful the documentation ACTUALLY is. Tell me what it’s particularly good at; tell me what it’s particularly bad at.

I could go online and ready 50 review saying that C# is the next best thing, and another 50 reviews saying that it’s trash. But since we seemed to have gotten into an argument over it, I’m giving you a chance to lay the cards down strait and let me see why you seem to like C# so much. Go ahead and be as technical as you want, just realize that I’m not likely to buy any arguments about how Fast or Portable or Dynamic it is, how superior it’s Garbage Collection is, or why it’s new level of type saving is so superior to everything else available. There is no perfect Language, so we both know it’s just a waste of time to argue how perfect a language is.

Tell me what makes C# so superior to USE.
"Well, if I am not drunk, I am mad, but I trust I can behave like a gentleman in either
condition."... G. K. Chesterton

“questions are a burden to others; answers a prison for oneself”
2007-06-04, 9:10 PM #74
Originally posted by JediGandalf:
C# is very capable of weeding out bad programmers. You don't have to do fancy pointer arithmetic to be considered a good programmer.
C# supports pointers. :neckbeard:
2007-06-04, 9:15 PM #75
Originally posted by West Wind:
Go ahead and be as technical as you want, just realize that I’m not likely to buy any arguments about how Fast or Portable or Dynamic it is, how superior it’s Garbage Collection is, or why it’s new level of type saving is so superior to everything else available.


Garbage collection is faster than manual allocation/deallocation. It's also a lot easier, because you don't have to worry about it. Memory leaks occur far less often. Memory leaks are defects, which lead to bugs, failure and eventually dissatisfied users. Which means spending more time (and money if a business) to fix the problem.

Strong, statically typed languages avoid potential defects by weeding out problems at compile time. Defects lead to bugs, bugs lead to the dark si- I mean, failure.

Managed code is also much harder to exploit. Everything runs in protected memory, and is thus more secure.

How are these not valid arguments in favor of C#?

You seem to be more interested in things like the .NET framework and documentation. Well, go look at the MSDN docs yourself. They're excellent. I sometimes find Sun's JavaDocs to be better, but most of the time Microsoft does a great job.

The .NET framework offers a lot of abstraction to common tasks, like say writing GUIs. Winforms makes things pretty easy. GUIs written with Winforms are easier to write, faster to write, and more maintainable than doing them with say, wxWidgets with C++, or god forbid, the Win32 API. WPF in .NET 3.0 takes that to even higher levels.

I like using C# because the .NET framework has most all of the common and tedious work done for me. It's a pain in the *** to hook into filesystem events with C++. In C# I can just have a FileSystemWatcher object automatically invoke methods for events like files added or removed from a specific directory, files renamed, using delegates (one of your "buzz words"). I was using something like this for a high level filesystem for a framework for a game engine and its tools suite last year. I never got far with it at all, but it would very easily let me update a list of resources in, say, a level editor when the user drags a new texture into his project.
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-06-04, 9:22 PM #76
I don't think Microsoft put their company on the line behind .NET. Is Office in .NET? Notepad? Any program shipped with windows? Can anyone name a best-selling game written in C#?

Looking on jobs in the seattle area on craigslist:

c#: 264
perl: 211
c++: 232
php: 171
Java: 372
ajax: 175
javascript: 292

Clearly, there is a demand for C# programmers. Clearly, there's also a large demand for the rest listed there.
2007-06-04, 9:22 PM #77
And I never realized pointer arithmetic was fancy...
2007-06-04, 9:23 PM #78
Hey Brian, use any tables lately?
ᵗʰᵉᵇˢᵍ๒ᵍᵐᵃᶥᶫ∙ᶜᵒᵐ
ᴸᶥᵛᵉ ᴼᵑ ᴬᵈᵃᵐ
2007-06-04, 9:25 PM #79
Originally posted by JediGandalf:
Stuff


Much better. I still don't completely agree, but that's all right.

I guess I personally have not seen the industry acceptance of C#, nor have I seen that much C# code floating around, which is one of the primary ways a judge a new language.

As for the point about Pointers and Algorithms, I consider both of those to be a given. Writing the algorithm is, in my experience, the easy part. Figuring out how to break it all down into functional units and modules that are both optimal for the langue, logical for the given problem, and still easy to write, test, and maintain, that is where things can get hard.

For instance, right now I’m working with a Proprietary language with a feature list as long as my arm, but at the same time it has second rate documentation, can only be called Object Oriented on a generous day, does not support any of the niceties (such as resizable arrays, or “For Each” loops, or well behaved pointers), and has the 3rd worst debugging messages I’ve ever seen. But it’s still the best language for the job right now. This means the true test is not trying to figure out the most efficient algorithm, but to find ways to organize the entire program to best suit the capabilities of the given language.

This is also what I want to know about C#. What’s it like to actually write significant amounts of code in C#, where does the language get sticky, what things do you get for free?
"Well, if I am not drunk, I am mad, but I trust I can behave like a gentleman in either
condition."... G. K. Chesterton

“questions are a burden to others; answers a prison for oneself”
2007-06-04, 9:29 PM #80
Originally posted by Emon:
How are these not valid arguments in favor of C#?


Because I can tell you about a language that can honestly claim all of these features, but forget to tell you that it's a mathematicaly inclined language, and writing non-mathematical code in it is pure hell.
"Well, if I am not drunk, I am mad, but I trust I can behave like a gentleman in either
condition."... G. K. Chesterton

“questions are a burden to others; answers a prison for oneself”
123

↑ Up to the top!