C or C++?

[chalsall]

Originally Posted by Dubslow

But what's a macro? What makes it different from a standard function?

A macro expands into inline code at compile time. Rather than a function which involves stack usage at run time.

[Dubslow]

Originally Posted by chalsall

A macro expands into inline code at compile time. Rather than a function which involves stack usage at run time.

Okay, is that a pre-processor type thing then?

Also, re: gdb:

Where are we?
If you want to know where you are in the program's execution (and how, to some extent, you got there), you can view the contents of the stack using the backtrace command as follows:
(gdb) bt
#0  ComputeFactorial (number=0) at broken.cpp:7
#1  0x08048907 in ComputeSeriesValue (x=3, n=2) at broken.cpp:21
#2  0x08048a31 in main () at broken.cpp:43

What does the hex represent? Memory address?

[chalsall]

Originally Posted by Dubslow

Okay, is that a pre-processor type thing then?

Yes.

Originally Posted by Dubslow

What does the hex represent? Memory address?

Yes. Of the stack frame for each function call which led you to where you are.

[jyb]

Originally Posted by Dubslow

I'd like to see how far I can get with printf's and my brain. With the C I've written so far, this has generally sufficed.

Indeed, but you'll discover that as your programs get more complex this will almost certainly not suffice for all bugs. And if you put forth the effort to learn to use a debugger now, while you're dealing with a relatively simple program, you'll be very happy when you have a more complicated one. Once you've gotten the basics down (essentially just learning to set breakpoints, print the value of variables, and step into, over and out of functions), I think you'll find that you can track down issues *much* more quickly in a debugger than with printfs.

Originally Posted by Dubslow

I guess then that there aren't any major structural flaws?

Well no, I didn't say that. There are actually some structural problems with your ReadLine function, but I figured you would mostly find and fix those yourself while you were finding your bugs. I think that's especially likely to be true if you use a debugger to find your bugs, because then you will actually see your code in action and watch how it's jumping around.

[jyb]

Originally Posted by Christenson

....why store the line at all, assuming the input and output streams are actually distinct....or his console is in "noecho" mode.

Sure. I didn't point that out in part because that wasn't something he was asking about originally; i.e. he asked about doing line-based I/O and so I figured it was worth helping him do that right and learn as much as he could about it. But mostly it's because I'm confident that it's something he will eventually see for himself. Right now Dubslow is obviously still learning about dynamic allocation, string handling and I/O in C. Let him get his head around those and learn them well and he will be able to step back and think carefully about whether they're the best tool for a particular job.

[jyb]

To expand on what Christenson and chalsall have said about macros, there are what are called function-like macros, which can take arguments. They mostly do simple text replacement (like your old definition of MAXSTRLEN), but they can bind the arguments and do the Right Thing with them. As an example, consider the following simple macro and some code that uses it:

#define SQR(x) x * x          // WARNING: don't use as is (more below)

void PrintSquare(int n)
{
    int s;

    s = SQR(n);
    printf("The square of %d is %d\n", n, s);
}

As you can see, the SQR macro is used like a function call. But in reality all that's happening is the preprocessor is doing a simple replacement, and turning the code into

void PrintSquare(int n)
{
    int s;

    s = n * n;
    printf("The square of %d is %d\n", n, s);
}

So one might well ask "why bother?" even in a simple case like this. Well, there are two reasons that come to mind why this macro can be nice. Can you figure out what they might be?

On the other hand, macros can be dangerous if you don't know how to use or write them correctly. For example, the macro above has three big problems with how it works (vs. how the equivalent function would work). Can you figure out what any of them are? Hint: think about some more complicated ways that one might use such a macro in code.

[ldesnogu]

Originally Posted by chalsall

Yes. Of the stack frame for each function call which led you to where you are.

Isn't it rather the address of PC rather than the stack frame address?

[chalsall]

Originally Posted by ldesnogu

Isn't it rather the address of PC rather than the stack frame address?

Whoops. You are correct.

[Dubslow]

@Christenson: That's what I get for modifying this from Java (this cypher problem was part of our weekly MP). Command line TextIO is a bit harder in Java (something about scanners) so instead we've been making use of the TextIO class that's out there on the interwebz, which means that to read input we were all basically pointed towards TextIO.getln();, which is more or less the same specification that jyb gave for ReadLine (excepting the null string terminator, of course). Now that you mention it (and now that I go back and reread your post) it does make more sense just to read one character at a time, encode and print. However, jyb is right in that at this point, it's just getting a handle on the concepts.

I did find a page about how to use gdb, which is where my question that chalsall answered came from; however, I understand neither the original answer or its correction. The only thing I don't know how to do is step out of a function (you mean skipping the rest of the code in the function, as opposed to just 'next' out of the last line?). However, I think a quick google ought to be able to shed at least a little bit of light on these things. (I did just try a 'man backtrace', but that pointed me to the functions in C, not what a backtrace is.)

Note also that I haven't actually put any more work into this since... Friday? I was out (of my room, not of dorm) being social last night (a rare thing for me).

[Dubslow]

Argh. This might have to take precedence, but I'll try and put some work into C over the week.

Hi there,
Here's the almost-finished 'Photoscoop' application that we hope to embed into every advanced camera phone next year.
The idea is that we'll give away a free version now with just some basic features then users can pay to use more features
(e.g. working with movie files).

By the way, run the playlists in the debugger so that you can find and fix the infinite loop!

I've already built the basic structure of the application - menus/ loading/saving etc but I need you to actually implement the photo effects.
I've ABSTRACTED out the details of how Java represents images in screen: Your effects methods just work with 2D integer arrays.

There are some missing features and possibly a bug or two in my GUI part - but dont worry I'll get these done before tomorrow's investor meeting & demo.
At some point I'll add a mask functionality so that your effects only get applied to part of the image.However as the effects code only
sees 2D arrays, I can add this in later and we wont need to change any of your code.
Also I cut some corners in programming style - I used static methods whenever possible; there's no class that represents an image document yet.

One of the 'cool' features that the bloggers wanted was redeye reduction and chroma key (see wikipedia) built into this application.

By the way, pay attention to the javadoc comments- /** blah blah */
that are immediately before each method:
They contain useful notes about what the method should do.

Best,
Your dot-com startup partner.
ps. sorry I can't help today - I'll be at a meeting with the bank to setup payroll and checking.
pps. The other programmer quit (he got too confused about column and row indices when rotating images)
pppps Suggest you draw it on a piece of paper. [0][0] is the top left

----
* What you will learn (Learning Objectives)

The purpose of this programming assignment is for you to learn how to use the following -

JAVA CORE KNOW-HOW:
# Debugging - run unit tests in the debugger to find the infinite loop
# Using bit operators (shift, bitwise-and) to extract red,green,blue values from an rgb value.
# Use 2D arrays to manipulate RGB images.
# Use static methods (including arguments and return values).
# Use loops and expressions.
# Use hexadecimal literals.

And be able to develop and exercise the following skills -

PROGRAMMING SKILLS & DOMAIN KNOWLEDGE:
# Process picture data
# Extend a complete Graphical User Interface application
# Use the RGB color model.
# Debug existing code.
# Add new functionality to existing codebase that includes several files.
# Work with a larger codebase where some sections are not relevant to the problem in hand.
# Use procedural abstraction and code-reuse to hide implementation details

RELEVANT BOOK SECTIONS: (http://math.hws.edu/javanotes)
ch2.2.2 Types and Literals
ch4.2 Static methods (Programming in the large)
ch4.3 Parameters
ch4.2 Return values
ch12.1.2 Working With Pixels

Honor students: Complete the stenography class to find and display the secret picture hidden in some of the given image files.

[Dubslow]

Okay, re: gdb and backtrace and the stack and what not: Did a little bit of Wikipediaing, and this is what I understand:

(gdb) bt
#0  ComputeFactorial (number=0) at broken.cpp:7
#1  0x08048907 in ComputeSeriesValue (x=3, n=2) at broken.cpp:21
#2  0x08048a31 in main () at broken.cpp:43

This is a view of the call stack, which is a Last-In-First-Out-style list of the return address for each subroutine/function call. So we are (the program is) currently in ComputerFactorial, which was called by address "0x08048907", located in the function ComputeSeriesValue, which was in turn called by address "0x08048a31" located in the function main. By PC, do you mean Program Counter (or perhaps process control)? The former makes more sense, I think, as keeping track of where we are in the program.

Edit: Found one bug, that I didn't update size.

if( ((input[i]=getchar()) != '\n') &&  (input[i] != EOF) ) {
                        input = (char*)realloc( input, (size *= 2)*sizeof(char) );      // Follow bsquared's usual practice.
                        if( input == NULL ) {
                                printf("Error, out of memory!\n");
                                return NULL;
                        }
                        i++;    // We're at i==size, continue reading at i==(size+1)
                } // skip to end while, continue reading in input up above

And that fixed my current test case. Brb. Addendum: That also fixed the other string where :) --> :O.