PDA

View Full Version : different between c and c++?


thondal
01-16-2006, 06:49 AM
hi, was wondering what the different between c and c++ and if anyone could reccomend any good newbies.... no, worse, absolutly beginners books?




-thondal-

mummey
01-16-2006, 01:19 PM
C++ is a superset of C as a programming language. C is a great starter language becuase it is a nice balance between understandable syntax, and low-level robustness. C++ is C with OOP (Object-Oriented Programing) added plus some extra structures (STL) that make it more convenient.

In the words of Bjarne Stroustrop (creator of the C++ programming language)

"C allows you to shoot yourself in the foot. C++, on the other hand, allows you to blow your whole leg off!"

If you're looking for a recommendation on which language to learn first. Ideally I would learn them in this order.

1. C
2. C++
3. Java

Some Java programmers will tell you that Java is an easier language, and as a result you should learn that first. I disagree with this assertion because it was the same justification that was used for Visual Basic, and as a result, created MANY mediocre VB programmers, and even WORSE programs. When it comes down to it, someone can't really appreicate what Java gives the user, and take advantage of it, until they know C/C++ first and had to deal with not having it available.

That being said, not everyone has time to learn 3 languages, so if you had to pick one, pick C++. Its what everyone uses... :thumbsup:

Cheers,

-b

PS: If only I could make this post a sticky. ;)

zenicle
01-16-2006, 11:55 PM
i'd pretty much agree with mummey in some senses.... (and especially on the VB comment!)
although from my experiences trying to teach these languages to uni students then i will say one thing.
if you know nothing and want a quick fix then go with something "safe" and learn a little java first. It does things that protect you from *scary* subjects like pointers and proper memory allocation. BUT then you end up without a clue of whats going on beneath all this fluffy java stuff and this will affect you in the long run.
Either that or commit yourself to learning things properly; invest some money in a book and a lot of time/practice!!! In the end its worth it!
As for learning C before C++ i wouldnt say that its a requirement, it may be "nice" but just jump in and go for it!
If you want to get urself a book then i dont really have any specific recommendations for C++ as a beginner but Stroustrup (http://www.amazon.co.uk/exec/obidos/search-handle-url/index=books-uk&field-author=Stroustrup%2C%20Bjarne/202-3253671-5011828) would be my choice as a reference, along with google!

Not sure ive actually mentioned anything of value, but its my 2p worth!

HTH

Dan

SnT2k
01-18-2006, 02:33 PM
This may answer some of your questions regarding C++: http://www.parashift.com/c++-faq-lite/big-picture.html

One thing to remember is that C++ came from C, majority of programs written in C could be safely compiled as C++.
One of the difference between C and C++ is that C++ allows object-oriented and object-based paradigm. Another difference is C++ allows templates which make generic programming easier. And finally (though not the last, there are others), C++ allows an exception-based design where you could "throw" an exception if an error occurs.

Just a note, you may also want to look into C++ because it provides a lot of useful libraries (called the STL) integrated into the language.

I started programming in Perl before moving to C++... the transition was hard. However, learning C++ is really deserving, I managed to program in Java, Visual Basic 6/.net and C# without any hitch. (it's like... once you learn C++, you learn the rest of the computer languages... except assembly)

For some good books, I'd recommend the C++ Primer. Though its approach is very steep (especially for a beginner), its content is one of the best. It gives practical (by practical, I mean things that looks easy on the outside but actually needs a lot of thought to implement) exercises and applications.

If you don't want to buy a book, you might as well read "Thinking in C++": http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html

Garma
01-18-2006, 05:39 PM
1. C
2. C++
3. Java


I'd reverse this list. Unlike VBasic, Java is a very neat and consistent language which will get you acquainted with the concepts of object oriented programming fast. Also, it has a great API, that way avoiding all the trouble beginners face. It is perfectly suited for beginners.

If you grasp the basics, move to c++, but only for advanced programming like graphics! All else: Java or C#. C# is like VB, but a lot neater. Using C++ when you can use Sharp or Java is pretty stupid and costs your boss money imho.

If you ever want to get as close to the core as you can get without microprogramming the processor, you can try C. It's not OO and that's a big downside today. I've never programmed anything worthy to be made in C.

stew
01-19-2006, 08:39 AM
Learning C before C++ is a very dangerous thing to do. If you carry over your C habits to C++, you will be a very bad C++ programmer.

Don't let the fact that a C++ compiler compiles C without complaining fool you: Writing good C++ is something completetly different that writing good C. In C, you use function pointers, malloc/free() and C-style casts. In C++, you use templates, references, new/delete, inheritance with virtual base functions and C++ casts - the former are allowed to use, but you really shouldn't.

Many programmers I've seen would qualify as "C+" programmers - they write C code spiced with class and new/delete keywords, but don't know what reinterpret_cast<> or volatile mean and run away scared when they see templates.

Carina
01-19-2006, 08:41 AM
"C allows you to shoot yourself in the foot. C++, on the other hand, allows you to blow your whole leg off!"

I suppose to finish off the analogy, Java allows you to sever most of your limbs and you won't even notice.


1. C
2. C++
3. Java


I personally haven't used C to any particular extent. But on the whole i agree. As someone who learned Java as a first language, and having taught Java as a first language, I would seriously advise against it. In my opinion, if you're serious about learning to program, too much of what's going on is "hidden" in Java, resulting in the "student" having to relearn many of the fundamental concepts when they come to use C++.

Apart from this, to my mind, memory allocation is something that's very important to understand if you want to be a good programmer. In C and C++ learning about this comes naturally, you have to understand it to be able to get to the next level, whereas in Java they don't. I know a lot of people think Java is a great first language because it's not as "scary" as C or C++ and so on, hence it's GREAT to teach in the first year cause not many students are scared off and the universities can sit back for another year cashing in on their tuition fees (cynical? me?).

If you only ever want to program in Java, to write good and efficient programs you'll still probably need to learn a second language to understand how absolutely AWFUL programs can be and still "work", whereas if you start out with C or C++ you'll immediately be much more aware of the implications of what you're doing, and hopefully avoid developing bad habits that will be hard to break.

Edit: Why is everyone obsessed with how Java is lovely because it's object oriented. With all due respect, object orientation isn't rocket science. I'm not saying it's trivial to design good object oriented programs, but understanding the basic concepts of OO and using them shouldn't really be all that difficult if you have a nice solid foundation in procedural programming. I find it much more frightening when people are obsessing about OO and still can't get a simple procedural program working properly.

Stu_Hacking
01-19-2006, 09:55 AM
I agree that you should learn C before C++ - just from the perspective of getting the basic of programming before moving into object orientated programming.

I wouldn't say one is better than the other because everything has it's own use - C is fast, C++ gives the code a better foundation is terms of evolution and maintenance.

though I just thought I would suggest objective-C (http://www.objc.info/) as another option (an alternative to C++ if you want :) )

mummey
01-19-2006, 12:14 PM
To sum up what Carina and others said:

1. If you want to serious about programming, and think you'll use it more than once in your life, don't learn Java first! You'll end up having to re-learn how everything in a programming language works and how it relates to the computer.

2. OO is great and all..., but you don't really learn how to take advantage of it until after a couple of years of programming. Worry about the basics and not about what 'special features' the language has but you'll never take advantage of for a while.

3. C is great because its simple and its fast. It allows you to learn all the pros and cons of computer programming without getting too complicated (ala OO and Java). I recommend you start there and get the basics down before switching to another language.

zenicle
01-19-2006, 02:07 PM
Just something else to throw into this whole thing.....

The bottom line is dont forget these are all just tools at your disposal, the most important thing is your imagination... without that you can kiss your OO theories/memory allocation goodbye!
All languages have flaws, everything from simula 67 to java, without exception! Everyone has a preference and everyone has an opinion. Try a few things out, bear in mind peoples comments about features/pitfalls of each language, and use the tool you're most comfortable with or best suited to the task.

Failing that just enjoy it, create something cool

Fides
01-19-2006, 04:44 PM
I would recommend Java. It has a number of excellent OpenGL libraries, is fast, and reasonably cross platform. It also has some very cool and helpful IDE's that can make programming an absolute joy. If you learn Java, and then decide to switch to C++, all you have to do is learn memory management. On the other hand, if you start out with C++, all your memory management skills are lost, as they don't apply. Other things to consider are that Java is considerably more cross platform than C/C++. There is also a *huge* library for just about anything you can imagine. I personally think Java is more elegant than C++, and in turn allows me more creative freedom because I don't have to think about the mundane so much.

All that being said, I think it's much more important to learn graphics principles than any particular language. As for books, I would recommend these, although you can leave out the raytracing and rendering books if your not interested in that:

Rendering/Mathematics:Essential Mathematics for Games and Interactive Applications (http://www.amazon.com/gp/product/155860863X/qid=1137690839/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-5842163-1324831?n=507846&s=books&v=glance)
Physically Based Rendering (http://www.amazon.com/gp/product/012553180X/qid=1137690966/sr=8-1/ref=pd_bbs_1/002-5842163-1324831?n=507846&s=books&v=glance)
Real Time Rendering (http://www.amazon.com/gp/product/1568811829/qid=1137691013/sr=2-1/ref=pd_bbs_b_2_1/002-5842163-1324831?s=books&v=glance&n=283155)
Introduction to Ray Tracing (http://www.amazon.com/gp/product/0122861604/qid=1137691339/sr=1-1/ref=sr_1_1/002-5842163-1324831?s=books&v=glance&n=283155)
GPU Gems 1 and 2 (http://www.amazon.com/gp/product/0321335597/qid=1137692911/sr=2-1/ref=pd_bbs_b_2_1/002-5842163-1324831?s=books&v=glance&n=283155)
C/C++/Java:Practical C (http://www.amazon.com/gp/product/1565923065/qid=1137691100/sr=2-1/ref=pd_bbs_b_2_1/002-5842163-1324831?s=books&v=glance&n=283155)
Practical C++ (http://www.amazon.com/gp/product/0596004192/qid=1137691138/sr=2-1/ref=pd_bbs_b_2_1/002-5842163-1324831?s=books&v=glance&n=283155)
The Java Tutorial( free online ) (http://java.sun.com/docs/books/tutorial/)
Learning Java (http://www.amazon.com/gp/product/0596008732/qid=1137691276/sr=2-1/ref=pd_bbs_b_2_1/002-5842163-1324831?s=books&v=glance&n=283155)
Head First Design Patterns (http://www.amazon.com/gp/product/0596007124/qid=1137691237/sr=2-2/ref=pd_bbs_b_2_2/002-5842163-1324831?s=books&v=glance&n=283155)
Websites:OpenGL (http://www.opengl.org/)
JOGL (https://jogl.dev.java.net/)
ACM Portal (http://portal.acm.org/portal.cfm?coll=ACM&dl=ACM&CFID=66097961&CFTOKEN=53423967) - Has a number of subscription options, for both programming and graphics. I pay $35.00 for the siggraph portal, which gives me access to thousands of graphics papers. But they also have programming courses and papers as well.
Mathworld (http://mathworld.wolfram.com/)

stew
01-19-2006, 04:54 PM
You know, all our language recommendations are futile when we don't know what the task is :) Some programs let you write programs fast, others let you write fast programs.

rendermaniac
01-20-2006, 03:57 PM
The bits that are different in C than C++ are generally the memory management and standard libraries aren't they? And isn't it just better to do these the C++ way? ie using std::cin std::cout and new and delete rather than scanf() printf() malloc() free() etc.

Simon

stew
01-20-2006, 04:17 PM
Just exchanging malloc() with new and printf() with cout doesn't make good C++ code. If you ask a search engine for C++ style, there are the concepts of const correctness, references vs pointers, why to avoid arrays, and of course the whole OO plehora: Use of patterns, virtual functions, inheritance, overloading etc.

Thalaxis
01-20-2006, 06:25 PM
I'd reverse this list. Unlike VBasic, Java is a very neat and consistent language which will get you acquainted with the concepts of object oriented programming fast. Also, it has a great API, that way avoiding all the trouble beginners face. It is perfectly suited for beginners.


Actually, that's precisely why I would suggest starting with C++ rather than Java :D


If you grasp the basics, move to c++, but only for advanced programming like graphics! All else: Java or C#. C# is like VB, but a lot neater. Using C++ when you can use Sharp or Java is pretty stupid and costs your boss money imho.


I agree completely.

Unlike Mummey however, I would never suggest starting with C... because it pays BIG time to learn object-oriented programming and design when you start writing more complex software, which is anything with more than 100 lines or so.

If you can figure out C++, you can handle C... the reverse isn't true and if you do what most "C++ programmer" do and just add C++ syntactic sugar around C code, you'll never be able to write anything particularly complex and actually get it to work correctly.

kabojnk
01-21-2006, 02:05 PM
I'd reverse this list. Unlike VBasic, Java is a very neat and consistent language which will get you acquainted with the concepts of object oriented programming fast. Also, it has a great API, that way avoiding all the trouble beginners face. It is perfectly suited for beginners.

If you grasp the basics, move to c++, but only for advanced programming like graphics! All else: Java or C#. C# is like VB, but a lot neater. Using C++ when you can use Sharp or Java is pretty stupid and costs your boss money imho.

If you ever want to get as close to the core as you can get without microprogramming the processor, you can try C. It's not OO and that's a big downside today. I've never programmed anything worthy to be made in C.

I agree. That's why here in the U.S. the computer science standards for a lot of states is for people to learn higher level programming languages first. At my school, it was VBA, Visual Basic, Java, C and then C++.

But I think that the emphasis on order is overrated.

Anyway, C++ and C both have their advantages and disadvantages. C is good for operating systems, while application components are great with C++. Hence, games are generally best done with C++.

However, I disagree with Garma's comments about Java being consistent. It certainly undergoes a lot more changes than C++; nevertheless, it's very didactic and its automatic memory allocation makes it easy for beginners. Still, I have major problems with its garbage collector being far less than sub-par. And Swing, well, it's ugly. Not the best GUI out there. It's no wonder why a lot of Java programmers don't utilize that toolkit. But, while Java has been somewhat of a completely useless language this past decade, it is proving itself quite invaluable in mobile technology.

I could also get back to the topic at hand about the differences between C and C++, but everyone else seems to have that base covered. Just think of C++ as C wearing a different yet more suave business suit.

And, I can't agree more with everyone's comments about Visual Basic and its contribution to the downfall of software development. :)

I wish I could say the same for C#, but as much as I hate it it's proving itself way too damn useful to openly bash, except on principle. :)

Garma
01-21-2006, 02:23 PM
well as a matter of fact, I started with C++ once. It's like being thrown in the deep when you've never seen water. There's just too much to learn in C++ if you've never seen a programming language. Chances are that the basics of OO programming will get lost in the jungle c++ is. You cannot expect a newbie to understand everything at once.

besides, C++ allows a shitload of shortcuts. Shortcuts are nice, but not if you don't know how it should be done properly.

To learn good OO programming: Java or C#.

Thalaxis
01-21-2006, 07:12 PM
But, while Java has been somewhat of a completely useless language this past decade, it is proving itself quite invaluable in mobile technology.


So you're saying that one of the most popular platforms for large-scale web applications is useless, eh?

You ought to check out monster.com and see how many companies are actively looking for Java developers these days. That's the real reason that universities are using Java to teach computer science; they're putting less emphasis on teaching the students what they need to know, and instead focussing on what will get them through the HR filters.


To learn good OO programming: Java or C#.


Or Ruby. :)

Carina
01-22-2006, 10:29 AM
So you're saying that one of the most popular platforms for large-scale web applications is useless, eh?

You ought to check out monster.com and see how many companies are actively looking for Java developers these days. That's the real reason that universities are using Java to teach computer science; they're putting less emphasis on teaching the students what they need to know, and instead focussing on what will get them through the HR filters.


This is certainly true to a certain extent, but if we're approaching this from a graphics point of view, Java is certainly not the language that is most "in demand". Since this is a graphics board, I would assume us to be approaching the subject from what's a useful tool if you're intending on getting into the graphics programming industry.

kabojnk
01-22-2006, 11:38 AM
So you're saying that one of the most popular platforms for large-scale web applications is useless, eh?

I'm not saying that it's completely useless, but in effect Java never reached its full potential until after 2000 when mobile technology was on the rise. I see it as a wrong place, wrong time problem. The only thing I've seen Java much good for is for analysis, where all it's really done is replace COBOL as the standards for business solutions. Therefore, I see it as a solution that works behind the scenes more than anything. You will see Java being the infrastructure for mobile devices, due to its portability and ease.

But when it comes to making games, or specialty solutions, Java simply just won't cut it--and it never has. One of the first companies I worked for, I worked for a national photo lab service in their digital imaging section, doing things from scanning film, to processing, to printing everything out on various types of commercial photo printers. In our pipeline, almost everything was done with proprietary software written by some staff members from within the company. Though we did use Photoshop to touch up photos that had significant problems, we did all of the initial scanning, color correction, and batch printing with that proprietary software--and it was all written in C++. Just imagining how Java would have dealt with interfacing between those devices, processing those photos, etc. would have been a nightmare--not to mention how sluggish the final product would be, not to mention its GUI.

So, in environments where data needs to be manipulated in special ways (i.e. anything that requires graphical representations, especially of complex models, or anything that requires sound processing, or anything that really might appeal to our senses), Java won't really fit the bill as the most efficient solution for businesses. In contrast, businesses who don't normally work in such an environment might still try to employ something like Java to get such a solution, but the smart ones would have outsourced their work anyhow.

So yeah, my point is: analysis, java = good... basic data management, java = good... mobile technology, java = good... web solutions, java = yahoo! games... audio-visual solutions, java = bad...

Shaderhacker
01-22-2006, 04:01 PM
Alot of what you guys don't seem to be emphasizing is that learning takes time. Becoming a professional takes time.. and when you learn - you should learn a lot about what you are trying to do from step 1.

Having said that, I learned Java in order to get me a better understanding of OO principles (it's what the school offered). I eventually learned C++ on my own. Our college happened to stop teaching Java and switched to C++ (when I was a senior) just for marketing reasons (as you guys stated), and guess what? The students were more lost than before - which indicated that they didn't get the principles down first.

The point is: very few people will be able to just pick up C++ and become proficient at all it has to offer in a short time span to be proficient for a job position. Hell, I still don't know all there is to know about C++. So, my recommendation would be to learn all about OO first and even the programming paradigm in general before tackling the more advanced programming languages like C++. No matter how long it takes, it will be worth it, as you'll not only understand OO when you do start to learn C++, but it'll be faster to pick up the syntax for any language/script you want.

-M

Carina
01-22-2006, 05:19 PM
Having said that, I learned Java in order to get me a better understanding of OO principles (it's what the school offered). I eventually learned C++ on my own. Our college happened to stop teaching Java and switched to C++ (when I was a senior) just for marketing reasons (as you guys stated), and guess what? The students were more lost than before - which indicated that they didn't get the principles down first.

Well, I can see why people would be more lost than before, or rather why it would seem that way. It's not as easy to "fudge" your way with C++ as it is with Java. Because Java is very "fool proof" plenty of people that start out with Java are under the impression that they can program, only to realise when they get to other languages that woops.. maybe they can't. So I would say that people seeming more lost is logical. I personally don't think that half the people that do computer science degrees (for example) should be doing so in the first place. Basically, I don't think that something being harder to learn means it is going to be more useful to know.


The point is: very few people will be able to just pick up C++ and become proficient at all it has to offer in a short time span to be proficient for a job position. Hell, I still don't know all there is to know about C++. So, my recommendation would be to learn all about OO first and even the programming paradigm in general before tackling the more advanced programming languages like C++. No matter how long it takes, it will be worth it, as you'll not only understand OO when you do start to learn C++, but it'll be faster to pick up the syntax for any language/script you want.


Again, I don't see what this emphasis on OO is.. or in learning programming concepts by using a "less complicated" language. I think if you're interested in programming for graphics, it's a very good idea to pick the language or languages you're most likely to use in your career as a starting point, as your starting language is often the language you'll feel most comfortable with further on. Additionally as stated in other threads in this forum, learning by example is great, and if you're looking for graphics programming examples there are infinitely more examples using C or C++ than other languages...

mummey
01-22-2006, 05:32 PM
Having said that, I learned Java in order to get me a better understanding of OO principles (it's what the school offered). I eventually learned C++ on my own. Our college happened to stop teaching Java and switched to C++ (when I was a senior) just for marketing reasons (as you guys stated), and guess what? The students were more lost than before - which indicated that they didn't get the principles down first.


You're basically proving me right. Its tougher to switch from Java to C/C++ than the other way around. Because of the "protections" Java gives users, those new to programming are less likely to realize when they're doing something stupid since Java protects them.

Also, why _should_ people be in a hurry to learn OO? Do you really think intro programming students are going to be able to understand _why_ they structure their programs into objects in their first programming class? They are too busy worrying about things like syntax and logic errors to think about things like that. But the instructors, (and people like you), are telling them they are learning OO so they think at the end of the course that they can write programs in proper OO, when in reality all they can do is write some bastardized Java code.

When it comes down to it, you don't learn to appreciate OO until you've written programs with 10k+ lines in it. In this situation OO is near critical to help keep your program design organized.

zenicle
01-22-2006, 05:44 PM
I was always taught to use the best "tool" for the job.
There is no universal tutorial on learning to program. if you wanna learn C++ straight off then go for it. life aint easy, deal with it. Use forums, read tutorials. anythings possible if you put your mind to it

kabojnk
01-22-2006, 05:56 PM
There are still several pitfalls with learning Java first. Like Carina mentioned, it's idiot-proof (well, she said fool-proof). So if you learn bad habits with Java, it's going to transfer to C++ and make things a complete pain. If there was one langauge I'd recommend for people as a transition from <insert crap programming language> to C++, it would be C. C teaches you to be competent with memory management, and it teaches you to manually do a lot of things--a lot of inline things are good to know if you're breaking into the field of graphics programming especially.

And many students starting out with Java still won't understand when objects are necessary, and when they are not. It's not just about being able to have objects for the hell of it. If it were like that, C would be completely obsolete. Nobody needs a friggin' object for something that has a single function that spits text out to a screen. One of the most annoying things to see in Java and C++ is unnecessary encapsulation of code that will never be used again, especially within the program itself. I think learning C after Java will give students the new restrictions to make them better exploit other solutions with far more effective tools that C has to offer. And, then when they move to C++ they can choose to use objects in a far more responsible manner. Best analogy I can think of is when a kid is done riding a tricycle, you give them a bicycle with training wheels, which can be removed after the kid has had enough experience to know how to ride the bike properly.

That's why there's a logical jump from Java to C, but not from Java to C++. And I'm not saying this goes for everyone, because everyone knows there are people who can understand programming concepts and protocol a lot faster than others. But for the majority of people who pass through Java, they don't really have much of a clue beyond Visual Basic or experience with various markup languages.

Shaderhacker
01-22-2006, 10:15 PM
I think if you're interested in programming for graphics, it's a very good idea to pick the language or languages you're most likely to use in your career as a starting point, as your starting language is often the language you'll feel most comfortable with further on.

It depends. I don't recommend picking up a book on C++ and trying to learn graphics programming with it. There are too many other things that are more important than the tool you use to solve a graphics-related problem. Having worked with several software developers at quite a few large companies and having interviewed with several others, I've found that concept is key. Any developer that is proficient at a concept can solve most problems given any language. There are several problems in the graphics pipelines that don't require C++, but require lots and lots scriptwriting. If I were to do it all over again, my chances getting into the industry would be greater if I were an expert at Python and MEL than knowing C++.

Python and MEL scripters outweigh C++ programmers by a large margin simply because a lot of production artists plus r&d use scripting programming languages. Therefore, it's logical that knowing those will open up more positions for someone than the ones dedicated to C++. NOTE: This advice is only if you are in a rush to get your foot in the door. The learning curve to be proficient with C++ *well* is a lot steeper.

Additionally as stated in other threads in this forum, learning by example is great, and if you're looking for graphics programming examples there are infinitely more examples using C or C++ than other languages...

Show me some good Renderman or Mental Ray examples where a beginning programmer will be able to grasp not only the graphics principles but C/C++ as well.

-M

Shaderhacker
01-22-2006, 10:21 PM
Also, why _should_ people be in a hurry to learn OO? Do you really think intro programming students are going to be able to understand _why_ they structure their programs into objects in their first programming class? They are too busy worrying about things like syntax and logic errors to think about things like that. But the instructors, (and people like you), are telling them they are learning OO so they think at the end of the course that they can write programs in proper OO, when in reality all they can do is write some bastardized Java code.

I never said they should be in a hurry to learn OO. I said that they need to understand concepts first. C++ is centered around OOP. Syntax is a part of every language or tool. Syntax will always be an issue for the programmer in order to get something working properly.

For example, knowing the concept of templates goes behind the scope of being able to just declare them.

I've grown weary of talking to people who know how to code but don't really understand the concepts around a problem. Have you ever just did an example in a book, got it to work and then just said "What did I just do"? This is the very thing I don't want with my students (if I were to teach).


-M

kabojnk
01-23-2006, 12:03 AM
Show me some good Renderman or Mental Ray examples where a beginning programmer will be able to grasp not only the graphics principles but C/C++ as well.

-M

Show me any Mental Ray documentation where anyone, aside from futuristic robots, can grasp what's being written. The trick usually IS to let one of the resident geniuses that foregos all social function just to figure it out and post tutorials and examples. Then you steal the code and pick it apart. And the other trick is, when you come across something in the code you don't understand, you look it up. That way you learn both context and practicality all in one step, and only at the expense of some guy who had a lot more time on his hands than you. It may be nice to learn things in theory, but it can be pretty effective to learn things through analytical approaches--or perhaps best with a combination of both methods.

Anyway, I just wanted to complain about how MR's documentation is so thorough that it could make Stephen Hawking crap his pants.

Shaderhacker
01-23-2006, 12:47 AM
Show me any Mental Ray documentation where anyone, aside from futuristic robots, can grasp what's being written.

I can come close.. ;) I'll have a first-start tutorial that I'm working on put out later this year (if all goes well)...

-M

kabojnk
01-23-2006, 12:51 AM
I can come close.. ;) I'll have a first-start tutorial that I'm working on put out later this year (if all goes well)...

-M

If you put that out, I will promote it more than I promote breathing air to live. It's about time somebody put out some decent documentation on MR.

Thalaxis
01-23-2006, 02:06 AM
Again, I don't see what this emphasis on OO is..


Non-trivial software systems get complex very quickly. Object and aspect oriented programming are methods for making the code more managable. There are a lot of design patterns that non-OO developers never learn, methods for code-reuse that non-OO developers never learn, and even methods for improving maintainability that non-OO developers never learn.

People who never learn OO (or AO) programming usually end up writing hackjob programst hat no one can understand, including themselves. It's very rare for such folks to understand why Knuth said "premature optimization is the root of all evil."


or in learning programming concepts by using a "less complicated" language. I think if you're interested in programming for graphics, it's a very good idea to pick the language or languages you're most likely to use in your career as a starting point, as your starting language is often the language you'll feel most comfortable with further on.


Any rational developer will agree with that.

Thalaxis
01-23-2006, 02:17 AM
I never said they should be in a hurry to learn OO. I said that they need to understand concepts first. C++ is centered around OOP. Syntax is a part of every language or tool. Syntax will always be an issue for the programmer in order to get something working properly.

Even in C++, syntax is the easy part :)

Shaderhacker
01-23-2006, 02:20 AM
Even in C++, syntax is the easy part :)

Yeap! ;)

-M

kabojnk
01-23-2006, 04:16 AM
Non-trivial software systems get complex very quickly. Object and aspect oriented programming are methods for making the code more managable. There are a lot of design patterns that non-OO developers never learn, methods for code-reuse that non-OO developers never learn, and even methods for improving maintainability that non-OO developers never learn.

People who never learn OO (or AO) programming usually end up writing hackjob programst hat no one can understand, including themselves. It's very rare for such folks to understand why Knuth said "premature optimization is the root of all evil."


I don't think that not knowing (or not using) OO and AO are as disasterous as you think. Keep in mind that UNIX operating systems are written in C, and they're very well organized and modular. It's not hard to organize code with procedural programming, and really it generally comes down to personal preference of style. People can see that with the forks between GTK+ and QT on UNIX systems. One goes for a C-driven GUI, while the other deals in C++. Both have their weaknesses and their strengths, but they're both still fairly successful in graphics programming. If you live in a Windows environment, perhaps AO and OO is more prevalent, but I don't so I don't have much to say about Windows' programming solutions but I don't quite think its because they're better, I think the final products just have better commercial backing due to the scope of Microsoft's target audience compared to the *nix userbase.

Still, people should learn OO just to be able to be well-versed in programming, and that it ought not to be just Java. As for AOP, the only real thing I've seen the technique used in is with the Java extension. I don't really have much of an opinion about it due to personal lack of use, but it's an interesting concept to be sure.

Thalaxis
01-23-2006, 04:30 AM
I don't think that not knowing (or not using) OO and AO are as disasterous as you think.


I know otherwise. I've had to deal with far too much of it already.


Keep in mind that UNIX operating systems are written in C, and they're very well organized and modular.


Some of them... but not most of them.


It's not hard to organize code with procedural programming, and really it generally comes down to personal preference of style. People can see that with the forks between GTK+ and QT on UNIX systems. One goes for a C-driven GUI, while the other deals in C++. Both have their weaknesses and their strengths, but they're both still fairly successful in graphics programming.


What it comes down to is the difference between the slack-jawed hacker who learned the syntax, and the developer who learned to design a system.


If you live in a Windows environment, perhaps AO and OO is more prevalent, but I don't so I don't have much to say about Windows' programming solutions but I don't quite think its because they're better, I think the final products just have better commercial backing due to the scope of Microsoft's target audience compared to the *nix userbase.


Not even close. AO and OO have nothing to do with Windows vs UNIX or any other platform; in general, the best non-trivial programs out there are built using object-oriented principles, and the rest aren't.


Still, people should learn OO just to be able to be well-versed in programming, and that it ought not to be just Java. As for AOP, the only real thing I've seen the technique used in is with the Java extension. I don't really have much of an opinion about it due to personal lack of use, but it's an interesting concept to be sure.

People should learn OO so that they can produce good programs.

AOP is becoming popular in user-facing code; it's not something you'd want to use across an entire application in most situations, but it has a lot of advantages in event handling and that sort of thing. A lot of AJAX libraries use AOP techniques, for example.

As useful as it can be when used as a complement to a well-designed system, it will in most cases be fatal with poorly-designed software.

Shaderhacker
01-23-2006, 04:30 AM
It's not hard to organize code with procedural programming, and really it generally comes down to personal preference of style. People can see that with the forks between GTK+ and QT on UNIX systems. One goes for a C-driven GUI, while the other deals in C++. Both have their weaknesses and their strengths, but they're both still fairly successful in graphics programming. If you live in a Windows environment, perhaps AO and OO is more prevalent..


Can you point me to a major film/CG studio that uses a C-based graphics pipeline (besides the MR shaders which can also be done in C++)?

The only company I can think of was PDI/Dreamworks - and even they were converting their renderer to C++ shortly before I left. Also most film/CG studios out there use Unix-based computers. They still use g++ as a standard compiler with any editor (i.e. nedit, xemacs, vi, etc..) and Totalview as a debugger (which really has nothing to do with Windows).

-M

Shaderhacker
01-23-2006, 04:32 AM
People should learn OO so that they can produce good programs.

Nice. I can tell you've programmed long enough to understand this. :thumbsup:

-M

Thalaxis
01-23-2006, 11:56 AM
Nice. I can tell you've programmed long enough to understand this. :thumbsup:


Yep... my insistence on teaching OO early comes from having to deal with large amounts of extremely poorly designed spaghetti code written by fools who think they can program. Every time, it's been a result of bad design decisions... but in many cases, obvious ones, the sort that even a beginner with an understanding of object-oriented basics would have laughed at.

Carina
01-23-2006, 12:18 PM
Maybe I should make it clear that I don't have anything against OO programming. I just don't think there is any point in starting out with a certain programming language simply because it's object oriented, or that emphasis on object orientation needs to be there until their procedural programming skills reach a level where it is logical to introduce object orientation as a solution to a problem.

stew
01-23-2006, 01:12 PM
A "which language to learn" discussion is about as good as a "which 3d program to buy" discussion: It depends on what you want to do. When someone wants to write an "arrange these objects in a spiral" plugin for Maya, recommending to learn C++ is about as stupid as pointing someone who wants to write a hobby raytracer to MEL. And if you're even half serious about becoming a good programmer, you should know more than one language anyway.

Just like in other disciplines, it's not too much about the tool but what you do with it. Who cares if you use C++ or VB when you're sorting a 10k array with bubblesort?

Carina
01-23-2006, 02:15 PM
A "which language to learn" discussion is about as good as a "which 3d program to buy" discussion: It depends on what you want to do. When someone wants to write an "arrange these objects in a spiral" plugin for Maya, recommending to learn C++ is about as stupid as pointing someone who wants to write a hobby raytracer to MEL. And if you're even half serious about becoming a good programmer, you should know more than one language anyway.

Advising someone who wants to write a plugin for Maya to learn C++ is a BAD idea??!?


Just like in other disciplines, it's not too much about the tool but what you do with it. Who cares if you use C++ or VB when you're sorting a 10k array with bubblesort?


It's all about tools of the trade, and you can't say that this trade doesn't lean heavily towards C++.

kabojnk
01-23-2006, 02:19 PM
I know otherwise. I've had to deal with far too much of it already.

<...>

Some of them... but not most of them.

<...>

What it comes down to is the difference between the slack-jawed hacker who learned the syntax, and the developer who learned to design a system.

<...>

Not even close. AO and OO have nothing to do with Windows vs UNIX or any other platform; in general, the best non-trivial programs out there are built using object-oriented principles, and the rest aren't.

<...>

People should learn OO so that they can produce good programs.

AOP is becoming popular in user-facing code; it's not something you'd want to use across an entire application in most situations, but it has a lot of advantages in event handling and that sort of thing. A lot of AJAX libraries use AOP techniques, for example.

As useful as it can be when used as a complement to a well-designed system, it will in most cases be fatal with poorly-designed software.


I think we're both in agreement about the "best tool for the best job" concept, in a very roundabout way. But it sounds like you hate procedural programmers as much as I hate OO jackasses who write poor code because they weren't properly introduced to the subset. I've been the victim end-user of poorly written C++ and Java numerous times, especially at work, for these "non-trivial" solutions you talk about. It takes OOD, yes, but these people come straight out of college from these crash courses in MFC or what have you and write crappy programs. I know you're not in support of this, but if you think people should learn OO as early on as they can, they should also learn how to program correctly. Be that in C++ or C, as long as they learn correctly I have no qualms.

Also, I had no idea AJAX was so closely related to AOP. It's quite interesting, since AJAX is something I've been wanting to tackle as of late. It'll be more fun playing around with it when I get the time to.

And @Shaderhacker, I should have clarified that what I was saying wasn't about major production pipelines. It was more oriented towards standard graphical interfaces and how C and C++ solutions pretty much have people split down the middle, showing that one system can do what the other does (or vice-versa) when it comes down to the final effect.

I don't think there are any major studios that use C, to be honest. Not unless you're into PSX console game development.

stew
01-23-2006, 02:39 PM
Advising someone who wants to write a plugin for Maya to learn C++ is a BAD idea??!?
For such a case, I'd use MEL over anything else!
It's all about tools of the trade, and you can't say that this trade doesn't lean heavily towards C++.
If you want to become an application developer, yes (even though I see lots of glue code in Maya being MEL scripts). If you want to become a character TD, MEL or whatever your app's native scripting language is would be a better choice. If you want to enter the gaming industry, Lua is also widely used from what I hear. If you want to start managing a render farm, knowing Perl, Python or Tcl would be highly useful.

Speaking from my industry experience, we used Python and Tcl in shipping applications for a few features. We could have done the same features in C++, but what for? It would have taken us much longer to develop them then.

Thalaxis
01-23-2006, 02:43 PM
I think we're both in agreement about the "best tool for the best job" concept, in a very roundabout way. But it sounds like you hate procedural programmers as much as I hate OO jackasses who write poor code because they weren't properly introduced to the subset.


I think those people that we hate are pretty much the same person... it's not procedural programmers I hate, it's ones that write bad code... I've seen decent procedural code from OO developers, but I've never seen good code from a "procedural" programmer. Most of the OO jackasses you refer to don't actually know what OOP is, so it's not like they're any better than the idiots who write 100% procedural code simply because they don't have the faintest idea as to what they're doing.

Then there are those fortran folks who can't get it through their heads that they don't have to write 100% procedural code anymore, but don't have the capacity and/or willingness to learn anything new. They're the worst, because they actually think that they ARE writing good code.


I've been the victim end-user of poorly written C++ and Java numerous times, especially at work, for these "non-trivial" solutions you talk about. It takes OOD, yes, but these people come straight out of college from these crash courses in MFC or what have you and write crappy programs. I know you're not in support of this, but if you think people should learn OO as early on as they can, they should also learn how to program correctly. Be that in C++ or C, as long as they learn correctly I have no qualms.


IMO they should go together. Trying to keep learning to program and learning OOP separate is a pointless waste of time. It's largely an educational failure, obviously -- there's no way for a student learning programming to know any better in most cases.


Also, I had no idea AJAX was so closely related to AOP. It's quite interesting, since AJAX is something I've been wanting to tackle as of late. It'll be more fun playing around with it when I get the time to.


I think it's largely coincidence, but several of the Ajax libraries floating around do a combination of adding object-orientation to Javascript, and adding AOP based event models. Aspect-oriented event models make some things a lot easier to deal with, and the OOP stuff is motivated by an interest in making their libraries more robust, reusable, and extensible.

I'd recommend checking out Prototype and Dojo, btw. My company standardized on Dojo, though I'm pretty sure we're going to massively underutilize it since I'm the only OO developer here, and I'm not enough of an ass-kisser to be in charge.

Prototype has the advantage of being very tightly integrated into Ruby on Rails, and as such it's very object-oriented, and also allows you to emit Javascript code from Ruby helper classes, which is VERY nice, because Ruby's so much easier to code in and debug than Javascript.

Carina,
I do agree that OOP isn't a good reason to choose a language. (That's why I was opposed to using Java as a starter language; as much as I like it, I don't think that starting with such a forgiving language is a good idea if you plan to be a serious developer).

At the same time, I don't think it's worthwhile for someone who does NOT want to be a serious developer to start with C++. Someone whose only interest in programming is to customize Maya should probably just go straight to MEL and not worry about learning C++, because odds are they're not interested in learning it well enough to use it anyway, so they wouldn't get much out of it.

They should still get the crash course on code quality conventions...

kabojnk
01-23-2006, 02:44 PM
Speaking from my industry experience, we used Python and Tcl in shipping applications for a few features. We could have done the same features in C++, but what for? It would have taken us much longer to develop them then.

I have to agree with that statement. I also especially love Python and TCL when it comes to implementing a scripting language within a bigger C/C++ program. I think they're both invaluable languages that serve a great purpose for addendum features, or simple, quick applications to be used within a system.

Carina
01-23-2006, 02:44 PM
For such a case, I'd use MEL over anything else!

If you want to become an application developer, yes (even though I see lots of glue code in Maya being MEL scripts). If you want to become a character TD, MEL or whatever your app's native scripting language is would be a better choice. If you want to enter the gaming industry, Lua is also widely used from what I hear. If you want to start managing a render farm, knowing Perl, Python or Tcl would be highly useful.

You can't really write plugins in MEL, you'd have to use the C++ API. I.e. for plugins C++ would be what you would want to use. And Maya is far from the only highend application that uses a C++ API for plugin creation. Scripting is all nice and well, but it only gets you so far.

stew
01-23-2006, 02:59 PM
Scripting is all nice and well, but it only gets you so far.
Which is why you use scripting to go that far, and C++ for the remaining part. For a lot of cases, the results you get from C++ or a scripting language are identical, except that you can develop the scripted version in a fraction of the time.
http://forums.cgsociety.org/showthread.php?t=151419

Shaderhacker
01-23-2006, 03:01 PM
You can't really write plugins in MEL, you'd have to use the C++ API. I.e. for plugins C++ would be what you would want to use. And Maya is far from the only highend application that uses a C++ API for plugin creation. Scripting is all nice and well, but it only gets you so far.

Yes, but I think what the consensus here is (and I agree with Stew and Thalaxis) most solutions to your graphical problems can be done in MEL if all you want to learn is a quick way to manipulate Maya.

Again, this all depends on what you want to learn in Maya. A lot of tools are written in MEL..in fact, the majority of them in a lot of studios are in MEL. That's why I said that anyone who learns MEL or another scripting language WELL will be immediately marketable and their chances increase on getting a job in the industry as opposed to knowing only C++.

I would take a MEL scripter over a person that knows just C++ any day. He would be able to write the majority of the tasks for the pipeline. The number of MEL-script only tasks just outnumber the C++-only tasks by a large amount.

-M

Shaderhacker
01-23-2006, 03:02 PM
except that you can develop the scripted version in a fraction of the time.
http://forums.cgsociety.org/showthread.php?t=151419

Exactly. :thumbsup:

-M

Carina
01-23-2006, 03:09 PM
For a lot of cases, the results you get from C++ or a scripting language are identical

I hope you didn't mean for that to be taken literally.

I would take a MEL scripter over a person that knows just C++ any day. He would be able to write the majority of the tasks for the pipeline. The number of MEL-script only tasks just outnumber the C++-only tasks by a large amount.


I can't see that anyone who knows how to develop plugins using the API would have any problems writing MEL scripts...

Anyway, I know we're getting way off topic here.. the statement that essentially stated "learning C++ to develop maya plugins is pointless" was just too ludicrous to let slip.

kabojnk
01-23-2006, 03:12 PM
For learning C, I'd recommend O'Reilly's "C in a Nutshell."

For C++, I'd recommend O'Reilly's "C++ in a Nutshell."

stew
01-23-2006, 03:23 PM
Anyway, I know we're getting way off topic here.. the statement that essentially stated "learning C++ to develop maya plugins is pointless" was just too ludicrous to let slip.
Please don't generalize my statements, OK? :)
someone wants to write an "arrange these objects in a spiral" plugin for Maya

Carina
01-23-2006, 03:25 PM
Please don't generalize my statements, OK? :)

You specifically said PLUGIN, or I wouldn't have commented in the first place.

stew
01-23-2006, 03:35 PM
Plugin (http://en.wikipedia.org/wiki/Plugin) as in "piece of software that adds functionality to another program". If Maya has a stricter nomenclature, I apologize for the confusion.

kabojnk
01-23-2006, 03:40 PM
Still, in essence, those are scripts and plugins are products usually created with an API. That's how most people understand it, anyway.


http://en.wikipedia.org/wiki/Plugin:

"These days, plugins are typically implemented as shared libraries (http://en.wikipedia.org/wiki/Shared_library) that need to be installed in a standard place where the application will find them."


But it's all semantics really.

mummey
01-23-2006, 04:21 PM
Yep... my insistence on teaching OO early comes from having to deal with large amounts of extremely poorly designed spaghetti code written by fools who think they can program. Every time, it's been a result of bad design decisions... but in many cases, obvious ones, the sort that even a beginner with an understanding of object-oriented basics would have laughed at.

I would then argue they should have learned design before they even touched OO then. It is VERY easy to get OO wrong and actually make the problem worse if you do not know design.

mummey
01-23-2006, 04:23 PM
Yes, but I think what the consensus here is (and I agree with Stew and Thalaxis) most solutions to your graphical problems can be done in MEL if all you want to learn is a quick way to manipulate Maya.

Again, this all depends on what you want to learn in Maya. A lot of tools are written in MEL..in fact, the majority of them in a lot of studios are in MEL. That's why I said that anyone who learns MEL or another scripting language WELL will be immediately marketable and their chances increase on getting a job in the industry as opposed to knowing only C++.

I would take a MEL scripter over a person that knows just C++ any day. He would be able to write the majority of the tasks for the pipeline. The number of MEL-script only tasks just outnumber the C++-only tasks by a large amount.

-M

Many scripting languages are based on C/C++ syntax, they just aren't necessarily OO. You don't need to know OO to use C++ (unlike Java). Its just there if you want to use it.

mummey
01-23-2006, 04:24 PM
Even in C++, syntax is the easy part :)

Yet some instructors will be teaching OO when students are still trying to figure out what the syntax does. This is one of my arguments against Java as a first language.

Shaderhacker
01-23-2006, 04:31 PM
I can't see that anyone who knows how to develop plugins using the API would have any problems writing MEL scripts...

Yeap, because most of the time, it is assumed that they have already written MEL before. If you come into a studio thinking you have an advantage with only having written C++ maya plugins as opposed to someeone who has written great MEL software, you are being misguided. The majority of the tasks that require C++ will probably have already been written (unless you work at a start-up) and those other tasks that require it will be few and far between.

All I'm saying is that it's better to start with the most needed skill (MEL scripting) FIRST...then move on to Maya's API and C++.

-M

Shaderhacker
01-23-2006, 04:35 PM
Many scripting languages are based on C/C++ syntax, they just aren't necessarily OO.

That's true.

You don't need to know OO to use C++ (unlike Java). Its just there if you want to use it.

True - You don't need to know OO to use C++. But then again, you won't really understand commands that are classes unless you do (i.e. cout <<).

-M

mummey
01-23-2006, 04:41 PM
All I'm saying is that it's better to start with the most needed skill (MEL scripting) FIRST...then move on to Maya's API and C++.

-M

For an artist that may have thoughts of "moving up to TD", absolutely. ;)

MEL is much different in structure from the Maya C++ API. If however you are serious about wanting to become a programmer. I would start with a programming language first.

Thalaxis
01-23-2006, 06:30 PM
I would then argue they should have learned design before they even touched OO then. It is VERY easy to get OO wrong and actually make the problem worse if you do not know design.

OO and design should go together. It really needs to be rammed into newbies' heads that design before code isn't optional.

Unfortunately, most "programmers" and project manager don't understand why, so they ignore the design phase and just start writing code.

pekko
01-23-2006, 06:58 PM
I picked up C++, because i wanted to write windows applications in easy way (mfc) and have them working fast, for graphics purposes. I have had some experience in procedural programming. OO was really difficult for me in the beginning, because fot those example programs were so short that it seemed like waste of time to use OO for those. When i actually began to write something bigger....i couldnt do it manageable without OO consepts.

For me it seems that learning some procedural language a bit in the beginning would be good idea, but when the basics are crasped..one should move quickly to OO language, because for me it seems stupid to write anything big without it.

Sonk
01-24-2006, 07:29 PM
Can anyone point me to a good site that teach C++?(want to write some plugins for a app).

Thalaxis
01-24-2006, 07:45 PM
A site with some great resources is www.gamedev.net.

It's (obviously) games-oriented, but there's a boatload of stuff there on the math of 3D, physics, and rendering (realtime, of course), as well as on programming in a pretty wide variety of languages. It also has a section specifically for people getting started in programming.

Tlock
01-31-2006, 04:48 PM
Isn't OpenGL written in C and that is why using OpenGL with C++ is more complicated, as a result the key advantage DirectX has over OpenGL (not saying OpenGL is better or worse then DirectX, each has pros and cons).

Not to mention isn't OO more common in the Windows world rather than in the Linux and Unix world. I am surprise that ppl haven't mentioned ASM when refering to graphics programming.

Shaderhacker
02-01-2006, 01:59 AM
I am surprise that ppl haven't mentioned ASM when refering to graphics programming.

Why would I write an assembly vertex/pixel shader when the compilers (ogl and hlsl) does it for me?

Assembly is pretty much dead in the film world. I would assume that it's almost dead in the gaming world too.

-M

Thalaxis
02-01-2006, 02:04 AM
Assembly is pretty much dead in the film world. I would assume that it's almost dead in the gaming world too.


Outside of embedded computing and compiler development assembly is pretty much limited to highly customized code where no one cares about portability or getting a sizeable software system written and validated in a reasonable timeframe.

zenicle
02-01-2006, 03:01 AM
Why would I write an assembly vertex/pixel shader when the compilers (ogl and hlsl) does it for me?


well i guess that depends on how much you trust your compiler to optimize your code!
there are some very poor compilers out there (lol - i should know i've written quite a few!)
it comes down to a few things:


cost - in time/effort
how optimized you consider the compiler output to be and whether you could do better?!
required portability of end result
i guess for the film industry optimization (like ASM) may not be the biggest of concerns. but there are definately still many many areas where its still used!!!

kabojnk
02-01-2006, 03:49 AM
I don't see ASM doing much now. It used to be a big thing back in the demoscene, but now it's mostly obsolete. There are still a few places where ASM can be useful, but other than that it's not as important. The power of the basic PC these days often outweighs the need to have every piece of code optimized, especially with how complex games can now become . It's no longer an issue of Programming for the SNES or PSX, it's coding very complex systems for newer generation consoles and PCs, and the hardware can handle languages like C and C++ just fine. The APIs like DirectX themselves do a decent job at optimizing routines anyhow.

zenicle
02-01-2006, 09:35 AM
The power of the basic PC these days often outweighs the need to have every piece of code optimized

Exactly... programmers have become lazy/unmotivated. Now if your software is running slowly you just bump up minimum requirements - throw more hardware at it.
Its all become about who can produce what, and in the fastest time with the cheapest costs.

and the hardware can handle languages like C and C++ just fine.

What is this supposed to mean??
Anyone can write bad C/C++ code. which in turn can produce badly compiled & optimized code (GIGO!).
Yes, most of the time the compilers get it right. But not always, being a good programmer is often more than just making something compile and run.
I know most people dont care about that level of optimization, im just saying if they did (and some do!) then the industry may be in a better position. Producing better games and better software all round.

stew
02-01-2006, 09:51 AM
"Premature optimization is the root of all evil" (http://www.brainyquote.com/quotes/quotes/d/donaldknut181625.html) (Donald Knuth). ;)

The order needs to be correct. First you make sure your code does what it's supposed to do without bugs, including border cases (what does your normal calculation do when it gets a triangle with three identical vertices?). Then you determine if it has a performance problem and if so, where - using a profiler and benchmarks, not assumptions. The bottleneck of your code is very often not where you think it is. When you start optimizing, try to do high-level optimizations, not micro-optimizations. A perfectly optimized bubblesort will still be slower than a mediocre quicksort.

mummey
02-01-2006, 01:54 PM
Why would I write an assembly vertex/pixel shader when the compilers (ogl and hlsl) does it for me?

1. Backwards compatibility
2. Cross-Vendor - as someone who has used Cg for a while, you quickly realize that the compiler assumes the compiled code will be an nvidia card, no matter what language you compiled it to (ARB, GLSL, HLSL).
3. It does _exactly_ what you tell it to do, without attempting any 'optimizations' of your code during compile time.

kabojnk
02-02-2006, 12:37 AM
New Thread: "Difference Between C/C++ and ASM?" ;)

Shaderhacker
02-02-2006, 04:45 AM
well i guess that depends on how much you trust your compiler to optimize your code!

I seriously doubt that most compilers would lose seconds in execution because of inefficiencies. And writing one to get that extra boost is even more of a waste of time (for me and what I do anyway). I guess a compiler writer would benefit working at some hardware company..but at film studios, we have better things to do.. ;)

-M

Shaderhacker
02-02-2006, 04:52 AM
1. Backwards compatibility
2. Cross-Vendor - as someone who has used Cg for a while, you quickly realize that the compiler assumes the compiled code will be an nvidia card, no matter what language you compiled it to (ARB, GLSL, HLSL).
3. It does _exactly_ what you tell it to do, without attempting any 'optimizations' of your code during compile time.

I could write a vertex/pixel shader for both platforms (HLSL & ARB), compile them and still have enough time to go get coffee and bagels before someone even finishes coding up an assembly vertex/pixel shader equivalent. Time is very important in development. IMO, I'd much rather let the compiler do what it's designed to do and don't worry about the details of it's compiled form unless there is a problem. That's what compiler writers are for. You also lose modularity and you have to duplicate code multiple times. I'm sure I'd get tired of writing the asm version of a normalization for all the vectors I have to normalize in a given shader.

-M

UrbanFuturistic
02-02-2006, 10:51 AM
you have to duplicate code multiple times.You do? Damn, I've been doing it wrong all this time!

mummey
02-02-2006, 02:44 PM
I could write a vertex/pixel shader for both platforms (HLSL & ARB), compile them and still have enough time to go get coffee and bagels before someone even finishes coding up an assembly vertex/pixel shader equivalent.

Really!?! I could prove you wrong plus...

My ARB assembly code will run in more places. :D

(Note: I have experience in Cg, GLSL, and ARB vertex and fragment programs. I use ARB assembly because its supported by more cards, is cross-platform, and allows me to make the most out of the hardware.)

Irradiated
02-02-2006, 03:08 PM
[...] When you start optimizing, try to do high-level optimizations, not micro-optimizations. A perfectly optimized bubblesort will still be slower than a mediocre quicksort.

Yes; and efficient algorithms live much longer than any particular implementation, no matter how optimised.

Shaderhacker
02-02-2006, 05:00 PM
You do? Damn, I've been doing it wrong all this time!

Well, if you write a shader that's global to every object in the scene then I guess you do only have to write it once. But that's not very elegant seeing as though different objects *should* have different shading properties. But I guess we're talking about games here... ;)

-M

Shaderhacker
02-02-2006, 05:05 PM
Really!?! I could prove you wrong plus...

My ARB assembly code will run in more places. :D

Run in more places like what? You only have 2 platforms you can compile too correct? ARB and HLSL.

Also, you'll end up having to write several passes (since code is limited to length) if you want to support the lower end video cards that don't have support for infinite-length code.


(Note: I have experience in Cg, GLSL, and ARB vertex and fragment programs. I use ARB assembly because its supported by more cards, is cross-platform, and allows me to make the most out of the hardware.)

That's fine. And one can compile using the ARB compiler. My point is, I'd rather (and a lot of other developers) use Cg and compile than to write ARB assembly by hand. 99% of the time the compiled code will work and be almost (if not faster) as fast as custom made assembly.

-M

mummey
02-02-2006, 05:10 PM
Run in more places like what? You only have 2 platforms you can compile too correct? ARB and HLSL.

Also, you'll end up having to write several passes (since code is limited to length) if you want to support the lower end video cards that don't have support for infinite-length code.



That's fine. And one can compile using the ARB compiler. My point is, I'd rather (and a lot of other developers) use Cg and compile than to write ARB assembly by hand. 99% of the time the compiled code will work and be almost (if not faster) as fast as custom made assembly.

-M

You don't work much with Ati cards do you? The Cg compilor assumes that the output will be used on an nvidia card. Quite often the output from Cg will be sluggish or refuse to run on Ati cards at all as a result.

Have you ever even written any ARB assembly? The commands aren't that difficult.

Shaderhacker
02-02-2006, 06:34 PM
You don't work much with Ati cards do you? The Cg compilor assumes that the output will be used on an nvidia card. Quite often the output from Cg will be sluggish or refuse to run on Ati cards at all as a result.

No I haven't. I don't do this for a living but on my spare time (and I only have an Nvidia card). The only assumption that would need to be changed that I could think of is the declaration of the compile. I would assume that all the multiplies/adds, etc.. are the same for each platform (GL or D3d) and really can't imagine why the ATI board would refuse to run unless you are trying to compile math ops that most ATi boards don't support due to PS.3.0 (which would be an ATI problem - not a compile problem).


Have you ever even written any ARB assembly? The commands aren't that difficult.

Yes, I've written a straight ARB assembly vertex/pixel shader before (in fact, I rewrote the parallax mapping mod for Quake 4). Yes, it's quite easy.. but it's still redundant and tedious. I'd much rather stick to writing out C-like source code and compiling it.

-M

mummey
02-02-2006, 06:58 PM
A couple of parameters that can vary greatly between graphics cards:

Maximum program length
Maximum # of texture access's.

It becomes very interesting when you have to write a fragment shader that requires 4 passes.

zenicle
02-02-2006, 07:25 PM
I seriously doubt that most compilers would lose seconds in execution because of inefficiencies. And writing one to get that extra boost is even more of a waste of time (for me and what I do anyway). I guess a compiler writer would benefit working at some hardware company..but at film studios, we have better things to do.. ;)


Exactly my point before... you work in a world where it doesn't matter/you're oblibious to it.
Doesnt mean to say it doesnt happen - whatever industry you work in. It all goes back to what people have said about reasons for doing it in the first place. If you dont see the point of doing it, it doesnt mean everyone else is wrong!

btw i never said you should write your own compiler! - that would really be pointless unless you think you can do better! ;)

Shaderhacker
02-02-2006, 08:26 PM
Exactly my point before... you work in a world where it doesn't matter/you're oblibious to it.
Doesnt mean to say it doesnt happen - whatever industry you work in. It all goes back to what people have said about reasons for doing it in the first place. If you dont see the point of doing it, it doesnt mean everyone else is wrong!

btw i never said you should write your own compiler! - that would really be pointless unless you think you can do better! ;)

I don't think you get my point, however. We are in this business to produce content (at least in the VFX/Film world). Engineering compilers is for another market.

-M

zenicle
02-02-2006, 08:31 PM
I don't think you get my point, however. We are in this business to produce content (at least in the VFX/Film world). Engineering compilers is for another market.


Making a compiler never came into question?!
I *thought* we were talking about using ASM to gain optimizations?!
I do get your point, you dont see the point of using ASM for the *small* benefits it could gain you?

Shaderhacker
02-03-2006, 05:38 PM
..you dont see the point of using ASM for the *small* benefits it could gain you?

No in film. In games? Perhaps.

-M

playmesumch00ns
02-03-2006, 05:45 PM
Completely agree with shaderhacker. There's usually no time to optimize code at all: you have to write it fast first time! If you do get time to optimize things it'll be on an algorithmic level.

What's far more important is code maintainability and reusability. If someone does low-level optimisation of a core piece of code in ASM, what happens when someone else has to debug/extend that code at a later date? A well-planned and documented class interface is a much better place to spend your time.

Thalaxis
02-04-2006, 01:29 AM
Completely agree with shaderhacker. There's usually no time to optimize code at all: you have to write it fast first time! If you do get time to optimize things it'll be on an algorithmic level.


Same here... as someone already pointed out, you usually end up with bottlenecks you didn't expect... and re-read that quite by Knuth that another poster put up.


What's far more important is code maintainability and reusability. If someone does low-level optimisation of a core piece of code in ASM, what happens when someone else has to debug/extend that code at a later date? A well-planned and documented class interface is a much better place to spend your time.

Agree there also. That's the origin of the Knuth quote above. Almost every time I've seen "highly optimized" code, it's been unreadable, didn't buy us anything more than the compiler would have given us, and took a long time to validate, since it was a large pile of mostly unreadable code -- without any comments. In other words, it was a waste of time and the code was nearly worthless.

9 times out of 10, you'll actually get higher performance code if you start out with cleanly organized and well-documented code, put it through a profiler, and address the egregious bottlenecks that the profiler directs you to, than if you waste time trying to hand-optimize everything in assembler or some such silliness.

navichana
02-08-2006, 09:04 AM
Can I do VC++ then Java?
What is the difference between C++ and Visual C++?

Can I do languages in this order..
C
C++
VC++

Looking forward for reply.........
Navi

rakmaya
02-08-2006, 11:30 AM
Really!?! I could prove you wrong plus...

My ARB assembly code will run in more places. :D

(Note: I have experience in Cg, GLSL, and ARB vertex and fragment programs. I use ARB assembly because its supported by more cards, is cross-platform, and allows me to make the most out of the hardware.)


Oh.. Really? If you can write the shader in assembly faster than someone who is professional who writes shader in HLSL, then I would like to see it happen.

Even if the requirement is to have the final output in assembly, you will still fail. HLSL compiler can be used to produce assembly code from the HLSL code. This is how many studios does it for XBOX before MS updated the xdk with the HLSL compiler. Even then there is no pixel shader compiler for HLSL code in that platform, People deploy similar techinques to move faster. And we have been doing it for many platforms and clearly see the difference of non-compiler support.

I would like to see this proved wrong. How about this, a competition between Shaderhacker and You. I will create the question. Whenever both are free. If proved wrong, you could write a book about it and make millions out. Anyway you win right? Or are you not confident ? Just kidding :D .... no need for this. Just I am curious as to what your method is that makes it faster than writing a code in HLSL.

Niklas Collin
02-08-2006, 01:37 PM
OK, this is a long thread and didn't read it completely but I'll say how I've learned programming with what languages and what do I think is good in it.

I basically learnt to program with C++ in the uni I am. All I can say is that I'm extremely happy in the way they brought things up. The first year with C++ didn't have OO until the very end of that course and until that we did the things the old way. No, we didn't use printf or other C syntaxes but we didn't get too deep into OO either. It was there and we first studied the basics.

Next year the only thing we basically learned from programming was OO. We had the basics well in our minds so it was really a logical step. We still used C++ since it was familiar for us and thus made the OO leap much easier.

At the end of the second year we also had some java programming (different course though) but it wasn't the main subject on the course. Basically everyone thought that if you've been through the C++ courses then you should be able to learn java without too much problems on your own. Very true and didn't take too much sweating on my part to learn it.

On third year (where I am now) we had more Java and also C# and .NET. Also C++ with MFC and Winapi. Software testing and utilities for that and so on... Right now I've started a course about mobile programming.

Now did I like the way it was taught to us? Yes. C++ is a great language to start IF you manage to hold your horses and learn to do things without OO first (well, you're using em with strings, cout etc. but still). This way the step into OO is really easy since the language is the same. It's like you'd find this great new tool from your toolbox that you didn't know that even existed. :)

I personally prefer Java and C# over C++ but I respect it still. It has it's uses, especially when making time critical software (like graphics software). C on the other hand is in my eyes getting a bit outdated. It has it's uses when creating software for integrated systems but when doing modern software for modern operating systems it is way too old and the lack of OO is too big an issue.

Oh and I spotted that someone said that Swing is "too ugly to use". I wonder where this comes from since you can activate Swing to use exactly the same look as the OS you are running the software in... Sure the default look is horrible but you should study the matter more before you bash it. ;)

Niklas Collin
02-08-2006, 01:51 PM
Can I do VC++ then Java?
What is the difference between C++ and Visual C++?

Can I do languages in this order..
C
C++
VC++

Looking forward for reply.........
Navi

First of all, Visual C++ isn't a programming language, C++ is. Visual C++ is just a program made to make C++ programming easier (an IDE that is). So you can drop the VC++ from your list as a language...

Now what you can do with VC++ that you can't do with Java. Actually I'd say that there isn't anything that couldn't do with Java, just when you are running Java bytecode through Java Virtual Machine the performance will lack when compared to C++ programs. You can however compile your Java program into binary (suprisingly few people know this!) and the performance difference is considerably less. Sometimes actually Java binary wins in speed.

What you CAN'T really do with Java is to program a software using Winapi or other windowing apis made for C++ etc. But that isn't Java's fault. And you could use .NET with Java if you'd want to... Just makes no sense since you have Swing and thus you can make multi-platform program with same work.

And can you languges in order C -> C++ (left the VC++ out for obvious reasons...)? The answer is "yes". But it doesn't necessary give you any advantage to learn C. If you're heading for integrated platforms then go for C. If you're determined to create Windows/Linux/OsX/whatever software, go straight for C++ but STAY AWAY FROM OBJECT-ORIENTATED PROGRAMMING!! Until you've got the basics well into your head then study OO and study it well. In my opinion (and experience) this is a great way to do it.

Just my two cents...

kabojnk
02-08-2006, 04:12 PM
As a small addendum, while VC++'s intents are to make it easier to program C++ in general, it consequently makes it exponentially easier to make more complex C++ programs using things like MFC or DirectX. I still recommended learning the basics of C++, either with or without VC++, first. If you can make you very first programs without VC++ (very simple ones), you can gain a thorough and different understanding on how the process goes from coding to compiling to linking and to witnessing your final result.

There are also other IDEs out there for free, but if you're wanting to develop more complex Windows applications in the future, VC++ is probably the best option for you. Same goes for anything that Visual Studio can do.

The main thing about VC++ is that, while it makes programming easier, the interface can be intimidating. If you can get past that and find what you need (through tutorials or books), you'll be fine.

stew
02-08-2006, 04:25 PM
The main thing about VC++ is that, while it makes programming easier, the interface can be intimidating.
To some degree, that is true for every compiled language, be it using an IDE or a command line compiler and Makefiles. Languages that provide an interpreter make the very first steps a lot easier, since you can focus on learning the language and not the tools. For those interested in 3d, I still think that various apps' scripting languages (Python, MEL, MaxScript, etc) are a good choice for tipping your toes into programming, and your first programs will have much more visual appeal than when starting on a blank sheet with a blank C compiler or Tcl shell.

mummey
02-08-2006, 06:41 PM
If you can write the shader in assembly faster than someone who is professional who writes shader in HLSL, then I would like to see it happen.

Even if the requirement is to have the final output in assembly, you will still fail. HLSL compiler can be used to produce assembly code from the HLSL code. This is how many studios does it for XBOX before MS updated the xdk with the HLSL compiler. Even then there is no pixel shader compiler for HLSL code in that platform, People deploy similar techinques to move faster. And we have been doing it for many platforms and clearly see the difference of non-compiler support.

I would like to see this proved wrong. How about this, a competition between Shaderhacker and You. I will create the question. Whenever both are free. If proved wrong, you could write a book about it and make millions out. Anyway you win right? Or are you not confident ? Just kidding :D .... no need for this. Just I am curious as to what your method is that makes it faster than writing a code in HLSL.

1. Why did you feel the need to post this? ShaderHacker and I have agreed to disagree because of different needs. He is a TD who needs to complete work quickly on very few machines so he can make deadlines. I, on the other hand, make software that needs to run on a variety of graphics cards and be able to squeeze every ounce of performance I can get out of each one of them. For me its less important writing the code quickly than it is to write the code so that as many machines as possible can run it and run it as fast as they can.

2. Now that I've said all that. What makes you think I DON'T write shader programs for a living?
3. HLSL is DirectX, I was comparing Cg and ARB shader code. (Both end up used with OpenGL, not DirectX).
4. Even if you would want to compare HLSL and ARB shader code. I doubt that HLSL would run natively on all the same graphics cards as the ARB code. In this case, HEL (Hardware Emulation Layer) is enabled in DirectX. When HEL tries to process HLSL, it becomes slow as hell.

Am I being unclear on any of this? :hmm:

CGTalk Moderation
02-08-2006, 06:41 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.