|
On November 03 2012 11:07 phar wrote:Show nested quote +On November 03 2012 11:00 uberMatt wrote:!dontcastmalloc 'const' in c and c++ are fundamentally different, you might want to look up the difference before writing a c tutorial  Yes http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-mallocBut for the purposes of a teaching a first year some basic pointer stuff, it's probably ok to include ugly hack code in the parts they're not even going to be modifying.
Actually it's pretty problematic if you show beginners bad code. They might think it's the right way to do it.
|
On November 03 2012 21:22 spinesheath wrote:Show nested quote +On November 03 2012 11:07 phar wrote:On November 03 2012 11:00 uberMatt wrote:!dontcastmalloc 'const' in c and c++ are fundamentally different, you might want to look up the difference before writing a c tutorial Yes http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-mallocBut for the purposes of a teaching a first year some basic pointer stuff, it's probably ok to include ugly hack code in the parts they're not even going to be modifying. Actually it's pretty problematic if you show beginners bad code. They might think it's the right way to do it.
Always 10 times as much time spent on the pedagogy of pointers and type-casting (How its best taught, how to best assist students in not developing bad habits and unexpected behavior headaches) than on the learning. I enjoyed the challenges, for one. Frankly, an investigation into the superfluous steps and the extent to which they assist readability is helpful for any student regardless. Anyone even surprised this is how Cecil was taught it?
|
United States10328 Posts
On November 03 2012 20:28 ragnorr wrote:Show nested quote +On November 03 2012 18:17 ]343[ wrote:lol, initially for #3 I did + Show Spoiler +
void swapInt(int *a, int *b) {
int temp = *a;
a = b;
b = &temp;
}
but of course that didn't work for #4 (since it doesn't actually swap the contents of the pointers... though I don't think #3 made that clear.) Also wtf in-place n log n sorting algorithms are way harder than expected  [except heapsort I guess...] You aint exchanging the value the pointer points to. It should look like this + Show Spoiler +
void swapInt(int *a, int *b) {
int temp = *a;
*a = *b;
*b = temp;
}
yep, I realized that 
|
now if could write some C++ program practice ^_^ hehehe thanks for the practice anyway 5/5
|
On November 04 2012 02:09 Sawamura wrote:
now if could write some C++ program practice ^_^ hehehe thanks for the practice anyway 5/5
I could do that. I'm thinking of some object oriented C first though. You know, virtualizing some C++ features in C.
|
On November 03 2012 20:28 ragnorr wrote:Show nested quote +On November 03 2012 18:17 ]343[ wrote:lol, initially for #3 I did + Show Spoiler +
void swapInt(int *a, int *b) {
int temp = *a;
a = b;
b = &temp;
}
but of course that didn't work for #4 (since it doesn't actually swap the contents of the pointers... though I don't think #3 made that clear.) Also wtf in-place n log n sorting algorithms are way harder than expected [except heapsort I guess...] You aint exchanging the value the pointer points to. It should look like this + Show Spoiler +
void swapInt(int *a, int *b) {
int temp = *a;
*a = *b;
*b = temp;
}
Obv you guys should swap like:
void swapInt (int *a, int *b) {
*a += *b;
*b = *a - *b;
*a = *a - *b;
}
SAVE THAT STACK SPACE.
|
On November 04 2012 06:48 teamamerica wrote:Show nested quote +On November 03 2012 20:28 ragnorr wrote:On November 03 2012 18:17 ]343[ wrote:lol, initially for #3 I did + Show Spoiler +
void swapInt(int *a, int *b) {
int temp = *a;
a = b;
b = &temp;
}
but of course that didn't work for #4 (since it doesn't actually swap the contents of the pointers... though I don't think #3 made that clear.) Also wtf in-place n log n sorting algorithms are way harder than expected [except heapsort I guess...] You aint exchanging the value the pointer points to. It should look like this + Show Spoiler +
void swapInt(int *a, int *b) {
int temp = *a;
*a = *b;
*b = temp;
}
Obv you guys should swap like:
void swapInt (int *a, int *b) {
*a += *b;
*b = *a - *b;
*a = *a - *b;
}
SAVE THAT STACK SPACE.
Lol. That works, but you might as well use some bit ops instead. That however doesn't work with data types that don't support the minus operator like that.
|
Ya this or even XOR swap is useless but still a fun question to ask people lol. Also this will die with larger numbers but anyway.
You should use swap with a temp. variable in almost any situation I can think of and not try to get in the way of compilers today ^_^
|
On November 04 2012 04:15 CecilSunkure wrote:Show nested quote +On November 04 2012 02:09 Sawamura wrote:
now if could write some C++ program practice ^_^ hehehe thanks for the practice anyway 5/5 I could do that. I'm thinking of some object oriented C first though. You know, virtualizing some C++ features in C.
I was on my way to a much longer post, but I don't want to get in the way of what you're doing here with a lot of negativity, so I'll just ask. Who learns C today, absent a specific need to write embedded code, modify a UNIX or Linux kernel, or write a driver?
I'm speaking as someone who paid several years of bills as a C programmer, working on both embedded applications and desktop applications. This was, however, 17 years ago, before (as far as I have personally seen, which is why I'm asking) the entire world moved on to C++.
** I mean, I can see doing it out of nostalgia, or because I got a cheap deal on some single-chip-computer development board, but that's about it. Is this a topic of interest for typical, highly-motivated CS students these days? I'm not saying it's bad, I just don't get it.
|
On November 04 2012 07:25 Lysenko wrote:Show nested quote +On November 04 2012 04:15 CecilSunkure wrote:On November 04 2012 02:09 Sawamura wrote:
now if could write some C++ program practice ^_^ hehehe thanks for the practice anyway 5/5 I could do that. I'm thinking of some object oriented C first though. You know, virtualizing some C++ features in C. I was on my way to a much longer post, but I don't want to get in the way of what you're doing here with a lot of negativity, so I'll just ask. Who learns C today, absent a specific need to write embedded code, modify a UNIX or Linux kernel, or write a driver? I'm speaking as someone who paid several years of bills as a C programmer, working on both embedded applications and desktop applications. This was, however, 17 years ago, before (as far as I have personally seen, which is why I'm asking) the entire world moved on to C++. ** I mean, I can see doing it out of nostalgia, or because I got a cheap deal on some single-chip-computer development board, but that's about it. Is this a topic of interest for typical, highly-motivated CS students these days? I'm not saying it's bad, I just don't get it.
Everyone at my university learns C and then C++. I myself took it a bit further and started mimicking C++ features in C before I swapped to C++. It's just another way of learning.
Edit:
So for example if I were to have someone make a struct object and mimic C++ vtables and inheritance, they could learn a whole lot about how C++ works as well as solidify and understanding of memory management at a low level.
|
On November 04 2012 06:48 teamamerica wrote:Show nested quote +On November 03 2012 20:28 ragnorr wrote:On November 03 2012 18:17 ]343[ wrote:lol, initially for #3 I did + Show Spoiler +
void swapInt(int *a, int *b) {
int temp = *a;
a = b;
b = &temp;
}
but of course that didn't work for #4 (since it doesn't actually swap the contents of the pointers... though I don't think #3 made that clear.) Also wtf in-place n log n sorting algorithms are way harder than expected [except heapsort I guess...] You aint exchanging the value the pointer points to. It should look like this + Show Spoiler +
void swapInt(int *a, int *b) {
int temp = *a;
*a = *b;
*b = temp;
}
Obv you guys should swap like:
void swapInt (int *a, int *b) {
*a += *b;
*b = *a - *b;
*a = *a - *b;
}
SAVE THAT STACK SPACE.
I like this for saving stack space:
void swapInt (int *a, int *b) {
register int c;
c = *b;
*b = *a;
*a = c;
}
(Although, most modern compilers will use a register for c at most optimization levels even if you leave the keyword out, and others ignore the keyword and do what they want.)
Edit: This has the advantage that you can easily replace "int" with "unsigned int" and get good results. The addition/subtraction trick is clever, but whether you can get away with it with unsigned ints is probably implementation-dependent.
|
On November 04 2012 07:32 CecilSunkure wrote:
Everyone at my university learns C and then C++. I myself took it a bit further and started mimicking C++ features in C before I swapped to C++. It's just another way of learning.
That's cool. This is like full blast-from-the-past mode for me. 
Edit: I don't know that I agree with teaching C to people relatively new to software development so early. It's a language that's so detail-oriented and mistake-prone that the fiddly details inhibit people getting to the bigger concepts of what they're trying to do.
However, if you want to select out the people with the most potential for future success as cutting-edge software engineers, it might be a decent scheme to find them. More so than using Java as a first language, which many schools do.
|
|
|
On November 04 2012 07:32 Lysenko wrote:Show nested quote +On November 04 2012 06:48 teamamerica wrote:On November 03 2012 20:28 ragnorr wrote:On November 03 2012 18:17 ]343[ wrote:lol, initially for #3 I did + Show Spoiler +
void swapInt(int *a, int *b) {
int temp = *a;
a = b;
b = &temp;
}
but of course that didn't work for #4 (since it doesn't actually swap the contents of the pointers... though I don't think #3 made that clear.) Also wtf in-place n log n sorting algorithms are way harder than expected [except heapsort I guess...] You aint exchanging the value the pointer points to. It should look like this + Show Spoiler +
void swapInt(int *a, int *b) {
int temp = *a;
*a = *b;
*b = temp;
}
Obv you guys should swap like:
void swapInt (int *a, int *b) {
*a += *b;
*b = *a - *b;
*a = *a - *b;
}
SAVE THAT STACK SPACE.
I like this for saving stack space:
void swapInt (int *a, int *b) {
register int c;
c = *b;
*b = *a;
*a = c;
}
(Although, most modern compilers will use a register for c at most optimization levels even if you leave the keyword out, and others ignore the keyword and do what they want.) Edit: This has the advantage that you can easily replace "int" with "unsigned int" and get good results. The addition/subtraction trick is clever, but whether you can get away with it with unsigned ints is probably implementation-dependent.
Hmm I guess given your background in embedded (and older compilers) you've actually had a need to do this but it seems strange to me because
1) you're not calling 'c' often which is the reason I've read you apply register for
2) register is just a hint and doesn't guarantee anything
3) this might move a variable that's actually being called often out of a register
3) compilers are smarter and will handle this for you anyway
(all my c knowledge comes from bruce eckel thinking in c++, but I know that even in c, register doesn't promise anything).
|
On November 04 2012 07:50 teamamerica wrote:
Hmm I guess given your background in embedded (and older compilers) you've actually had a need to do this but it seems strange to me because
1) you're not calling 'c' often which is the reason I've read you apply register for
2) register is just a hint and doesn't guarantee anything
3) this might move a variable that's actually being called often out of a register
3) compilers are smarter and will handle this for you anyway
(all my c knowledge comes from bruce eckel thinking in c++, but I know that even in c, register doesn't promise anything).
Generally, I agree with each of your points. I consider what I posted as academic an exercise as using adds-and-subtracts, because neither one makes for maintainable code, and while stack space can be at a premium sometimes, one int is rarely a make or break issue (even when you have a hard limit of 32k or less of stack space, as you do in some embedded applications.)
In embedded applications, though, a few things work differently than you might expect. First, if you are working with extremely limited stack space or RAM, as is often the case, you'll probably rely on disabling optimizations for critical code so that you get very predictable results at the machine level, and use compiler extensions that can directly force a variable into a particular register. GNU C has these, for example. Compiler optimization is fantastic, but if you're trying to put exactly the right bit in the right place you can sometimes find your intentions completely optimized out of the code if you're not careful.
One strategy I've seen used in embedded applications is to reserve a couple of registers for use as short-term temporary variable space, then manually assign a variable like c (in this example) to one of them for the duration of the function. Of course, doing something like that means that you have to make rules for yourself like "don't assume that value will be valid across a function call."
Also, for this particular function, in an embedded application, I'd look to see whether the processor itself has an instruction for swapping two values in main memory, or maybe a swap to accumulator function (an accumulator being a register on some processors that's specifically designated as such short-term temporary storage, possibly with special instruction support compared to other registers.) If so, implementing that function in assembly code might make sense.
For just about all the other cases out there, particularly if you're letting the compiler optimize freely, I'd just go ahead and use the code I posted, probably with the "register" keyword omitted. I might also consider defining the function with the "inline" keyword, which should allow the code to be better optimized where it's convenient and less optimized where it's not, particularly if a global optimizer is in use.
Edit: Mostly, optimizations don't really matter that much unless you're focusing on a small bit of code that takes up most of your application's processing time. Usually, in embedded situations, you'd want to pick and choose optimizations, because some optimize for space, and some for speed, and often getting your generated machine code smaller is more important than making it faster, to fit on an EPROM for instance. That would be an example where using "inline" might be a huge mistake.
|
On November 04 2012 07:33 Lysenko wrote:Show nested quote +On November 04 2012 07:32 CecilSunkure wrote:
Everyone at my university learns C and then C++. I myself took it a bit further and started mimicking C++ features in C before I swapped to C++. It's just another way of learning. That's cool. This is like full blast-from-the-past mode for me. Edit: I don't know that I agree with teaching C to people relatively new to software development so early. It's a language that's so detail-oriented and mistake-prone that the fiddly details inhibit people getting to the bigger concepts of what they're trying to do. However, if you want to select out the people with the most potential for future success as cutting-edge software engineers, it might be a decent scheme to find them. More so than using Java as a first language, which many schools do.
I'm always hearing about how poor graduates are that learn at "java schools" from a lot of respectable people, including current Microsoft employees and other industry veterans. Everyone here that learns by hitting the ground running in C seems to do very well once they've graduated. Seeing my school's alumni success makes it only natural for myself to advocate the same learning style.
As for the detail oriented ways of C, I feel the little fiddly details are things need to be mastered before anything else. When we started learning there weren't "bigger concepts" at all. The fundamentals were the concepts, so nothing was missed.
|
On November 04 2012 08:14 CecilSunkure wrote:
As for the detail oriented ways of C, I feel the little fiddly details are things need to be mastered before anything else. When we started learning there weren't "bigger concepts" at all. The fundamentals were the concepts, so nothing was missed.
I've heard the same things too about the use of Java at some schools.
I think my point may not have been clear about the issues with C as a first language. The "fiddly details" in C are mainly either syntactic elements that make the code difficult to read and bugs difficult to locate, or completely manual memory management. Neither of these aid, for example, teaching skills like structured programming, algorithms, or data structures.
For those two specific reasons, using C shields the student from too little, using Java shields them from too much. The possible benefit to using C is that the more talented students will enjoy the extra details even if they're extraneous to what you're trying to teach.
Anyway, the success post-graduation of a CS program is far more determined by the students the school admits than by any curriculum choice.
Interestingly, MIT, Caltech, and Harvey Mudd College (where Day[9], qxc, and I went) have all switched to using Python for their introductory computer science classes.
Apologies for getting off-topic.
Edit: I suspect top schools are moving to Python because it in one stroke eliminates the problem of good students not turning in homework over a misplaced semicolon they can't locate.
|
I will learn C next semester, so I will check this out then! Thanks a lot!
|
after having to do tracing in my c programming class probably a year ago...
I really
really
...
REALLY HATE pointers lol
(now I just program random scripts in python...)
|
United States10328 Posts
On November 04 2012 07:10 teamamerica wrote:
Ya this or even XOR swap is useless but still a fun question to ask people lol. Also this will die with larger numbers but anyway.
You should use swap with a temp. variable in almost any situation I can think of and not try to get in the way of compilers today ^_^
Hmm, shouldn't XOR swap work in basically all cases? o.o
|
|
|
|
|
|
EPT
