To OP
your pop( void** ) has a memory leak !!
its not done that way.
Do not malloc oldHead !!
It just needs to act as a pointer , which points to the head pointer or whatever .
Saw it so pointed it out :D

A question -- I'm assuming you are writing every part of the code posted? Is any of it provided by your prof, and you aren't allowed to change it?

I'm assuming all of the code listed is your code (possibly foolishly). Then...

First, screw the assignment interface requirements.

You can have a good, sane interface -- then expose the stupid assignment interface as well.

Here is an interface to write to:

int StackPop( Stack* stack, StackNode** node );int StackPush( Stack* stack, StackNode* node );StackNode* MakeNode();Stack* MakeStack();Stack* GetGlobalStack();void DestroyGlobalStack();

First rule: never ever call malloc for a StackNode outside of MakeNode(). MakeNode's job is to allocate a StackNode and set it up.

The same with Stacks -- the only function that allocates a stack is MakeStack().

GetGlobalStack() should return a pointer to the global stack -- ideally it should allocate the GlobalStack if it doesn't exist yet. Nobody else should even look at the global stack pointer. StackPush and StackPop should not call GetGlobalStack -- they should use the stack passed in to them.

The only time you should ever deal with void pointers is when playing with the StackNode->data member.

Get the above working.

Now, it is really easy to expose the interface your prof asks. Writing the professors "Pop" function is really easy, and you can check that the data makes sense along the way.

Thanks for all the help guys. I hope I can get this sorted out. Yes, the mem leak, I just stopped caring, and just wanted something to work =)

The code is all mine EXCEPT for the function protos. It HAS TO BE, NO QUESTION ASKED void**, etc.

Yes the prof is stuck in the 80s, but what can I say? =)

Quote:
In particular, if you can't figure out these kinds of things for yourself, you have no business trying to do them in C.

I'll choose to read this in the best way possible. yes I normally code in c++, but I'll be honest, I've never really had a need to use void* or even double pointers for that matter. So even though I am comfortable with pointers, I am just getting caught up with ** b/c of my inexperiance with it. So i'm trying to learn. BTW, I spent a good 5hrs trying to sort this al out on my own before I came here, so I think that qualifies as a good try imho. But not to turn this into a flame war...

Cheers

//edit
HELL YES! I got. Cheers all

Quote:Original post by Anonymous Poster

Quote:Original post by Zahlman
0) For something like this, there is very little justification I could accept for "I have to use C" - except possibly "I'm doing this for school and my prof is stuck in the 80s". Although a prof stuck in the 80s wouldn't speak of ZeroMemory() but instead memset().

1) In particular, if you can't figure out these kinds of things for yourself, you have no business trying to do them in C. It's not as if there's any significant amount of fat *available* to trim out of a standard C++ (using the standard library) implementation, and there are much better ways to learn how low-level algorithmic ideas.

</holierthanthou>

"If you can't figure out these things for yourself, you have no business blah blah...."

If you can't figure out these things for yourself you have no business learning them? Hello? He's obviously taking some kind of course here...

It is my considered opinion that very few people in the world have any business doing anything in plain C these days, at all. In a great majority of cases, the extra work done and mental burden taken on (versus using C++ and taking advantage of the full standard library) are ridiculous for no performance benefit whatsoever; in a great majority of the remaining cases, the performance benefit is barely measurable and the extra work is still ridiculous; in almost every remaining case after that, the performance benefit is not enough to matter while the burden would still be eased significantly by things like built-in-to-the-language RAII. C++ can be treated, to a large extent, like a preprocessor for C which is orders of magnitude more powerful than the built-in one, and that's still not harnessing the full power of the language. And if you're one of those oddballs using C99 explicitly for the few minor changes that actually let you do very specific optimizations that C++ won't trust you to do... then you'd probably have more luck writing it in FORTRAN.

Seriously, the only real excuses for using C that I can consider are "a C++ compiler does not exist for the target platform" or (which usually goes hand-in-hand) "the target platform requires the final executable to be smaller than what is realizable if I include <iostream>".

Lots of profs - colleges - programming curricula in general - have some *very* strange ideas about how to teach "a deep understanding of the machine". (At least, I hope that's what they're after. I shudder to think that they expect to teach people *how to program* like this! Absolutely disgusting.) It's better done via instruction in what they call "computer organization", which might (but needn't) get as high-level as an introduction to some form of assembly language (the one chosen doesn't matter).

Quote:
The code is all mine EXCEPT for the function protos. It HAS TO BE, NO QUESTION ASKED void**

See? Pure idiocy. Nothing is gained by throwing away the idea of *data types*. In fact, this idea is *fundamental* to programming. And there's no reason the function can't accept a StackNode** instead, because that's the only kind of pointer it will *ever* receive. Nothing else is valid. Notice that the dereferenced parameter is cast to StackNode* *unconditionally*.

Please, PM me contact information for your prof (and/or the department of computer science, if appropriate). I am volunteering - with discretion assured, and at no cost and assuming full legal responsibility - to tell him/her/them off.

Apparently Zohlman you forget. It matters not the language, it is the concept that counts. A good programmer does not care what language, he uses what language his boss (or Prof) says to use.

_Sigma, your prof (who I know) is not stuck in the 80's, C is widely used especially by low level hardware engineer's. Its OO brother C++ being widely used in game design. I teach a class on C++ myself, preferring OO over procedural programming.


Halsafar

Halsafar,
I dunno, at times he really comes across as feeling like he is. A text debugger w/10 lines of code? That seems silly to me.

GBD is a good console debugger.
If you understand the low level layer of something then you can very easily master the higher level. You've been babied on GUI Debuggers. Learn the console debugger and not only can you take this knowledge the most basic UNIX machines you will see how for example VS Debugger works with a better picture. Or for example 'ddd' the gui version of gdb.

Would you have been more pleased if he gave us a entire library to debug as our FIRST debugging lesson?

Good thing I knew all this last year.


Halsafar

Quote:Original post by Halsafar
Apparently Zohlman you forget. It matters not the language, it is the concept that counts. A good programmer does not care what language, he uses what language his boss (or Prof) says to use.

Complete and utter bullshit. Any half-competent programmer will be aware that each language brings it's own advantages and disadvantages to the table and will attempt to use the right tool for the right job. He will not code his MMO entirely in assembly. He will not hack togehter a cgi script in C and make a webpage hammer the server with HTTP requests to simply embed a real time clock into his site. He will use &#106avascript and let the client side take care of that, because it's the far superior solution. If horrible choices are made routinely and forced upon him, he may even consider updating his resume, fearing that he is on a sinking ship of incompetence among the project managers.

Certainly he should probably be able to hack together many monstrosities as bad technology choices are forced upon him, as a good programmer should be able to make do with what he's got. Being able to handle C programming should probably be on the list I'll even agree, as the concepts do carry over. But unless he's a two bit code monkey which has never left the mindless drone of endless reams of repetitive boilerplate, he will yearn for the greener pastures of actually being something half resembling productive.

I agree with the idea of "Right tool for right job.". In fact this is the theme of the class. If you where a half-knowledgable programmer you would understand that programming concepts (searching and sorting) and data structures (stack, queue, lists, tree's, hashmaps) are things you MUST learn, regardless of language. If you have a mind full of concepts and a toolbox full of languages you can program anything for anyone.




Halsafar

hey, i am in your class also
I completely understand why he is using Unix/C, and I don't think its about using the right tool for the job, he is just trying to teach very low level. If your not interested in the very low level workings of a computer go into engineering and more application based study.