Q: Pointers (C++)

#6

What other programming experience do you have? Have you programmed in Java or other languages, or are you learning on C++?

One thing that helped me understand how pointers work is a class I took in assembly.

Once you get to the level of assembly, it’s easy to see that everything on a computer is just bits - for example, when a program is compiled you’ve just got the data block and the code block. When you execute, you’ve typically got a stack and a heap. But it’s all just bits in a big block of memory.

One of the best things I got out of the class was the ability to translate C to assembly, and then to machine language. Then you can think of C++ just passing each C function a pointer to the struct to operate on implicitly - the this pointer.

Probably not the answer you’re looking for, but it you’re looking to become a programmer long-term, understanding how your high-level language actually gets run will help your efficiency and ability to fix nasty bugs.

#7

Hi Nurcc,

I am pretty much learning in C++, and from the sounds of it, learning assembly code would be quite helpful. Especially in terms of optimizing code for speed performance. I think I need to start out developing plugins and then begin learning assembly code. Thanks for the reply.

-Josh-

#8

Just want to give you a friendly piece of advice. I can’t help that it’s going to come out sounding like a put-down so I want to make it clear that I’m just advising you, not putting you down. Please take this as just advice from someone who has been through this.

Almost every piece of writing that you may come across about assembly language (tutorial, book, etc.) they will say pretty much the same thing: don’t get into Assembly thinking you’ll make faster code.

Using assembly does not gaurentee faster code. In fact, if you are new and don’t fully know what you’re doing you’ll end up writing bad assembly code that may run slower, be more buggy and prone to error, and in all cases: harder to debug and find errors.

Here’s my story:
I was just playing around with some beginner algorithms for writing a ray tracer. Was able to draw a few squares and circles on the screen, cool. Then I heard about SSE, SSE2, 3DNow! processor extensions. Normally compilers won’t know how/when to properly use them (mine didn’t, MS VC++ 6.0) There are some specialized compilers that will make use of those SIMD extensions but it’s not always great, the trick is to organize your data in such a way that they can be streamed (in other words fed) to the CPU and the SIMD instructions executed upon them for optimal performance.

So I tweaked my rountine by replacing them with assembly code, in this scenario I was able to use assembly instructions my C/C++ compiler did not know about (the SSE, SSE2 instructions). The result? Turns out my assembly code took longer than the regular “unoptimized” code the compiler generated. Why? Switching between the FPU and the ALU (in other words floating point math processor to integer math processor) causes a brief stall. It’s nano seconds, you wouldn’t notice it. But… in a loop that runs 1000 times, the delay adds up and becomes a performance bottleneck.*

I will agree that learning assembly does open up your eyes to how much goes on in the background and what your programs are doing. But it is forcing you to work at the hardware level, and you pretty much have to think like a machine. Don’t attempt this until you’ve grasped C/C++. Just take it as a learning experience, using assembly language isn’t always practical. You have more to gain in terms of improving performance of your programs simply by improving the algorithm and high level code. People spend years developing quality C/C++ compilers, you’re going to have a very hard time competing with that not to mention the compiling power of your computer.

I don’t mean to just discourage you from learning, assembly is very interesting and can be fun. But you’ll be spending much more time learning assembly as oppose to any other language (spoken or programmatic). That time is better spent actually utilizing what you’ve learned in C/C++. Or depending on what you’re doing, multi-threaded programming is even more valuable and can be done easier in C/C++.

In case you’re wondering, why did my assembly code run slower than the compiler code? Even when I used SIMD instructions (SSE, SSE2) that was suppose to boost performance? Here’s what my code sort of looked like:

for( int i = 0; i < numVertices; i++)
{
   // I inlined assembly instructions here
}

Remember what I said: switching between floating point math and integer math causes a speed penalty, not to mention the penalty in branching code. My FOR loop was based on an integer (i), the code in the body of that loop operated on floating point data. Moreover it was using the SIMD registers and execution units (some of which are just remapped to the FPU registers). The speed penalties added up and made this code slower. My compiler probably would have seen that problem coming and converted the i variable into a float in order to bypass one speed penalty. Even when I changed my C code to make i a float, the improvement was very negligible. Not worth the many hours I spent on it.

#9

Vert’s completely right about this; don’t plan to use assembly to speed up your code.

Your priorities should be:
Writing clean (i.e. readable) code
Writing extensible code
Writing fast code

If it’s clean, odds are it’s also less buggy than if it’s not.
If it’s extensible, it’s easier to supplement, reuse, and optimize.
If you don’t do the first two, the latter will take you an eternity.

And get into the habit of documenting your code, and doing some design work before you write it, even if it’s not a formal design document. It doesn’t even have to be UML, or even a visual diagram (though I find that easier to work with), but think about what you would have to write down in order for someone else to implement your design, and use that as a reference for what to include. You’d be surprised at how much better that alone will make your code.

#10

Reading this stuff helped clear things up for ME, and I’ve been coding in C++ exclusively for over 3 years. Then again, I never WAS that great a programmer. :wink:

But seriously, the importance of documenting your code can’t be stressed enough. You have to write it as if you were explaining it to someone who has no idea what your code does. Someone like YOU 3 months after you write it. Hell if I had properly documented my project, I might have finished my Master’s…

#11

I hear you :slight_smile: It’s always a pleasure when a client project you wrote (and did not document) comes back to haunt you after several months -> fun fun fun :surprised

I use a very simple method to ensure that my code is ocumented/commented: When writing a function I simply write down the things (phase by phase) that the function is supposed to do then write the code.

Like:
// Init stuff

// Create n samples

// Get 2 random numbers - x & y

// Map them to -1 to 1 interval

// Check if they are on an unit disk

// If so compute z and store

// Update sample counter

=>

 	// Init stuff 
	float x, y;
 
  // Create n samples
 for(i = 0; i < MAX_SAMPLES; )
 {
		// Get 2 random numbers - x & y
		x = Rand();
		y = Rand();
 
		// Map them to -1 to 1 interval
		x = 2 * x - 1;
		y = 2 * y - 1;
 
		// Check if they are on an unit disk
		if(x * x + y * y < 1)
		{
			// If so compute z and store
			zs[i] = sqrt(1.0 - x * x - y * y);
			xs[i] = x;
			ys[i] = y;
 
			// Update sample counter
			++i;
		}
 }

pipari

#12

I seriously hope to never run across some code from you … [re: commenting is not about having commented, good code needs no comment and unnecessary (bs) comments make life even harder] …cheers :deal:

#13

Words like that will end your job tenure pretty quickly in some places. “Good code needs no comment” is one of the oldest, and DUMBEST, myths in programming.

Don’t believe me? Try to write a program 1,000 lines long. Let me sit for a week without looking at it. Now open it back up and see if you can still remember what it does.

Consider this: 1000 lines is enough for one script. A more realistic program will have over 50,000 lines easily! Still think you can write it without comments!?!

#14

Trust me, you won’t :stuck_out_tongue: Funny thing is that every guy (& subcontractor) I have worked with have said exactly the opposite :shrug: Granted, the example I posted was pretty simplistic.

Consider this: 1000 lines is enough for one script. A more realistic program will have over 50,000 lines easily! Still think you can write it without comments!?!

Better yet, try to fix some real world program that consists 50,000+ lines of uncommented code written by some other guy (who no longer works for the company) -> fun fun :surprised

Peace :thumbsup:

pipari

#15

I agree, everybody should respect the 3 golden rules:

  1. commenting code is for wussies
  2. name variables and functions randomly with disregard for common standards
  3. be creative, scalability and portability issues can always be resolved at the last minute anyway
#16

I tend to block everything out with comments just as a reminder to me to start with. I then loose any really basic ones like:

/* for loop goes here */

They are very useful reminders to begin with though. Even if it seems simple it’s always godo to have a template to start from.

Then make sure you keep then ones important to solving the problem like:

/* this is the format we are reading NAME STATE LOCATION /
/ build tree of closest points */

and the most important ones which will bite you later:

/* we are doing this because the compiler is broken… in a perfect world we’d really do this… */

I have to admit I should document far more than I do, but most of my stuff is in a constant state of flux (ie specific solutions for a particular shot) rather than one big project, keeping this stuff up to date is a nightmare. (even the code to a certain degree!)

Simon

#17

Another benefit is that writing comments indicating what you plan to do makes you think about it before you commit it to code.

And if you’re just starting out, you really should take the time to learn process. And when you interview, ask about process. If they don’t have a process, then either it’s a sweatshop, or they don’t do anything that isn’t trivial to implement.

#18

I agree, everybody should respect the 3 golden rules:

  1. commenting code is for wussies
  2. name variables and functions randomly with disregard for common standards
  3. be creative, scalability and portability issues can always be resolved at the last minute anyway

The best guide I’ve seen is How to Write Unmaintainable Code

Another good resource is The Daily WTF, which has current, real-world examples. I’m sure most programmers who have worked in the real world have had to maintain ugly code (either their own, or others’). And most programmers have written their fair share, while learning. I still remember learning basic, and all the examples used single-letter variable names - it was a huge breakthrough when I found out you could use multi-letter variable names, and therefore have more than 26 variables… :slight_smile:

#19

I’ve got no probs with comments… but obviously there was some fatal misunderstanding here

most of those comments are just plain bs… sorry but it’s like that… like ‘init stuff’ and ‘update sample counter’ as the most blatant ones … no probs with eg ‘map them to -1 to 1 interval’ …

and mummey as an example … the for loop in ‘create n samples’ is perfectly good code so it has no need for a comment …

…unnecessary (bs) comments make life even harder…

so please try to look at the reply seriously and not as a hopeful chance to do some nice flamebait hopping… no harm intended … but it looks like anything thats not totally ‘new ones’ friendly gets dissed down in no time …so see you next time in the ‘help! beginner w/o access to google’-thread…or …errr…not

cheers :beer:

#20

Misunderstanding, yes. You missed the point I was trying to make. I tried to demonstrate a process that ensures that the code gets commented: 1) Write down the phases of the algorithm / function etc. as comments 2) then write the code. As I said it was just a simple example (a first piece of my non-work related code I could find) and many of those comments are unnecessary or bs as you so politely pointed out.

I have used this method for about six years now to ensure that my work related code gets commented. And as I said this method has proved to be quite good and the feedback I have gotten from my collegues and subcontractors has always been positive. Even the noobs understand what the code does -> they don’t bother me with their questions :stuck_out_tongue:

And yes, unnecessary comments can make your life harder but uncommented code can make your life even harder: I currently have in front of me about 60,000 lines of uncommented code (a process management tool) written by some other guy. I would prefer overcommented code over this any day :wink:

Peace :slight_smile:

pipari

#21

essentially the same boat … so have fun and a nice week end

cheers :beer:

#22

Yeah. Have a nice weekend too - And be careful with the bier :wink:

:beer:

pipari

#23

Please, you want to be learning and using STL. Learn auto_ptr<T> and vector<T> etc. I mean it pays to know enough pointer stuff to debug yourself out of a corner but I would urge against writing any large body of code without STL. Naked pointers and built in arrays only get you so far (in the real world). Really, data structures are a largely solved and boring problem. Get into iterators and <algorithms> and you’ll never look back - more importantly you’ll be turning out loads more useful and robust code than your friends who’ll be sweating their own balanced tree (or worse) implementation. You want to focus on the problem domain, which presumably will be graphics related, not the sordid business of text book data structures.

Too many programmer IMO think of C++ as a kind of glorified machine independent assembly language, especially in the graphics field. One of the best bits of advice I can give would be, before you invest hours and hours of your time optimizing what you think is a hot spot in your code measure it. Measurement should always preceed optimizaton. Write your code first of all to be clear and maintainable. Then measure it, then optimize.

#24

Hi,

I agree that code comments are not always necessary. I even think it is dumb and anti-programming if one comments every tiny bit. That is and won´t be programming in C++.
And just like one said, if your code really is good (means following your naming conventions + good and clean OO programming and similar) you will almost need no comments at all.

Saying this is a dumb myth is not very wise. I am programming for over 4 years in C++ and my brother is doing so for…darn, I don´t know how long, he started when he was 6 (not with C++ of course) and is now 28. He is programming for Volkswagen here in my hometown Wolfsburg (C++ and Java), and this is always what he told me. “When you fully understand the OO approach and you are writing it the way it is supposed to be, then you don´t need more than 2 comments.” Of course this shouldn´t be taken literally but the message is the same!

And you know what, when I write my classes I see myself using too many comments. When I rework my classes, I most of the time don´t need any comments. Similar for “runtime code” (that´s how I call it :slight_smile: ). I comment about every 20th line. This is more than I need. When working with others I need some more comments even if we use naming conventions.

Sure, programming without any comments…well, it´s a brave thought, but you won´t get too far with that. :slight_smile:

Darn, we are discussing comments here! He should rather concentrate on other things. Depending on what he wants to do with C++, understanding the OOP with C++ is far more important to write fast and efficient C++ code.

Learning assembly for C++ efficiency is, imo, a fallacy.

Katachi

#25

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.