C programmers

[neomagus00]

hey, are there any c programmers out there that want to help a fledgling figure out some funky behavior... in the next 2 hours? :p

specifically, i have this function:

[code]
void loadDict(char * fileName, int * numWords, char ** dict){
char * word;
FILE * filein = fopen(fileName, "r");
int i;

while(fgetline_113(&word, filein)) {
for (i = 0; i < *numWords; i++)
printf("dict[%d]: %s\n", i, dict[i]);
printf("\n");
dict[*numWords] = word;
(*numWords)++;
free(word);
}
}

fgetline_113 is a provided function that reads the next line from the file and stores it at the provided pointer; this is not the problem. What i'm expecting from this function is that it reads a list of about 7 words and inserts them into the array in order - this is a much simplified version of the actual lab. what i'm actually getting when i print it back out is the current word repeated numWords times, as though it's overwriting the words previously loaded into the dictionary.

dict is a pointer to a list of 50 char*s (malloc'd previously), and fgetline_113 mallocs memory for you and sticks the pointer in 'word', as mentioned... therefore, shouldn't i simply be able to say: element i of dict is assigned this pointer, then when i free it and re-malloc a new pointer, the old one - since it's a copy - should be untouched. instead what seems to be happening is it's copying the address just fine, but then that address is re-used by the next call to malloc... that is, it seems that my array is being filled with many copies of the same pointer...

any ideas??

[dkg999]

It's been a long time since I programed in C, however are you sure you are not loading the array correctly, but not incrementing to the next element in the arrary when you print?

[neomagus00]

yep - i figured it out... i was copying a pointer into the array, then immediately free-ing and reusing the pointer! remove the free() call, and it all works out... w00t!

[izafar]

Well, its been a while that I have coded in C and I hate pointers, I belive your problem lies in following statements:

while(fgetline_113(&word, filein)) -- you dont need to send &word, as word is already address type. try changing this stmt to
while(fgetline_113(word, filein))


you are printing from Dict before storing in it.

dict[*numWords] = word;
free(word);

you are making a shalow copy of word to dict. When the memory is actually cleaned you will lose it from dict also.

[petrym]

I just set up a recursive loop to delete everything, then there are no worries!

[Kris Siegel]

For your next project, I would suggest C++. vectors are nicer to work with :)

[TroyD]

I'm guessing that this a little above my Computer Programming in BASIC that I took back in high school.

BDT

[neomagus00]

For your next project, I would suggest C++. vectors are nicer to work with :)

i would if i could... the course is taught in strict ansi '89 C (dunno why, maybe it's cause we eventually write malloc() ? )

[bobman1235]

i would if i could... the course is taught in strict ansi '89 C (dunno why, maybe it's cause we eventually write malloc() ? )

It's a very useful thing. Knowing C++ is obviously great, but if you know the basic ANSI C very well everything else is just gravy. Fundamentals are key to being a good programmer.

Nearly everything I do has to be in ANSI C becauase i write firmware and low-level stuff that has to be as efficient as possible.

[Sami]

C still has its place. C++ has its benefits but you really need to do OO stuff to get it out. I have done C++/VS/MFC for about 8 years now and currently talking to a company about a position that would take me back to ANSI C world (CVI/Labview). Sure I will miss a lot of stuff from C++ but for this application C is the right tool.

[neomagus00]

well then, i guess it's nice to know i'm not learning a dead language :p

[Sami]

well then, i guess it's nice to know i'm not learning a dead language :p

You just have to remember that while C and C++ are related, they are very different. You'll see the same syntax in a lot of places but the fundamentals are different. Some say it is better to learn C++ without knowing C but that's not necessarily true as long as you understand what makes C++ different.

[ohskigod]

if you guys were having this conversation in a bar or club, you'd have to beat the chicks off with a stick....LOL :D

[Demiurge]

More like beat the chicks with the stick to get them to go home with them. :p

[neomagus00]

i dunno, i think heaps and pointers are pretty sexy conversation topics... :D

[Demiurge]

The internet was the best thing to happen to geeks and nerds, because now we all are, just to different extents. ;)

[Sami]

if you guys were having this conversation in a bar or club, you'd have to beat the chicks off with a stick....LOL :D

But why this conversation at a bar? I don't need to talk, just rely on my good looks... :D

[Sami]

well then, i guess it's nice to know i'm not learning a dead language :p

Just an update, I think I will be starting at my new job Monday morning. Offer is good, job interesting and has plenty of responsibility so I think I will take it. :D

[neomagus00]

cool, good luck and enjoy :p

[petrym]

#include <stdio.h>
int main(void)
{
    int count;

    for(count=1;count<=500;count++)
        printf("I will not throw paper airplanes in class.\n");

    return 0;
}

[Kris Siegel]

#include <iostream>

int main(){
  for (unsigned int i = 0; i < 500; ++i){
    std::cout << "I will not throw paper airplanes in class." << std::endl;
  }
}

Much nicer (C++) :D

Though, 500 endls is a bit overboard since endl also flushes the buffer. Probably would be better to use \n on all of them but the last one.

[neomagus00]

the c++ ive used doesn't require the std: prefix?

i still like the 'dangerous' lifestyle of C... i mean, honestly, who doesn't want to worry about buffer overflow and dangling pointers?

well, i suppose C++ has the same thing, but...

[bobman1235]

the c++ ive used doesn't require the std: prefix?

i still like the 'dangerous' lifestyle of C... i mean, honestly, who doesn't want to worry about buffer overflow and dangling pointers?

well, i suppose C++ has the same thing, but...

There's some kind of directive you have to give somewhere so you don't have to use the std:: prefix. "using std" or something like that.

And people who actually care about low-level performance don't touch C++. :)

[neomagus00]

yeah, it's "#include using namespace std;", i forgot about that bit... but why does C++ lose the low-level performance? isn't it just a superset of C?

[bobman1235]

You just have less control over a lot of things, and there's a lot more overhead. In order to make things easier for the programmer, the compiler has to do all the work, and who really knows what it's doing?

[Kris Siegel]

the c++ ive used doesn't require the std: prefix?

std is a namespace which contains all of the STL functions. It's a way to make sure nothing has the same name.

i still like the 'dangerous' lifestyle of C... i mean, honestly, who doesn't want to worry about buffer overflow and dangling pointers?

well, i suppose C++ has the same thing, but...

C++ has pointers and the buffer can also be overflowed. However, you can use C++'s auto_ptr instead of a regular pointer which automatically destroys itself (frees the memory) if the programmer forgets or it goes out of scope. It has regular pointers as well.

There's some kind of directive you have to give somewhere so you don't have to use the std:: prefix. "using std" or something like that.

using namespace std;

And people who actually care about low-level performance don't touch C++. :)

C++ can do anything C can do. It's fairly low level with some high-level functionality. Programmers usually choose C when developing drivers and kernels because it has a much smaller library to port/develop on.

You just have less control over a lot of things, and there's a lot more overhead. In order to make things easier for the programmer, the compiler has to do all the work, and who really knows what it's doing?

You don't have less control. If you choose, you can use all of the C functions you want, though the STL functions a very efficient and fast so I'm not sure why you wouldn't want to use them.

Also, it's not the compiler doing the work per say. Yeah it has to deal with classes and namespaces which the C compiler didn't, but the majority of the easy functions (if you want to call them that but templated, nested vectors and queues can get complicated) are contained in the STL libraries.

[Sami]

Kris got it right, C++ can do the stuff C can. The "inefficiency", overhead, comes only when you start using the advances C++ has over C (OO vs. procedural). But using C++ without OO is just using C with C++ syntax. Sure you can use C++ libraries that are OO but if your program isn't designed to be OO then it kinda loses its point.

[bobman1235]

Kris got it right, C++ can do the stuff C can. The "inefficiency", overhead, comes only when you start using the advances C++ has over C (OO vs. procedural). But using C++ without OO is just using C with C++ syntax. Sure you can use C++ libraries that are OO but if your program isn't designed to be OO then it kinda loses its point.

Exactly. Saying C++ can do everything C can do is just a silly thing to say. I wasn't referring to writing C code and compiling it with a C++ compiler, I was referring to doing an object oriented approach using C++ over a more basic approach with C. Object oriented stuff is going to have more overhead, because you're hiding the guts of the work in all the C++ libraries, which means more nested function calls, which means less efficiency.

[Sami]

Exactly. Saying C++ can do everything C can do is just a silly thing to say. I wasn't referring to writing C code and compiling it with a C++ compiler, I was referring to doing an object oriented approach using C++ over a more basic approach with C. Object oriented stuff is going to have more overhead, because you're hiding the guts of the work in all the C++ libraries, which means more nested function calls, which means less efficiency.

That's exactly where the saying different tools for different jobs applies here. C does well for low level stuff, C++ is great for complex and large systems. I used to work in embedded software side before and after doing Windows software, it is now also moving into C++ and OO as the softwares are getting larger due to more memory and processor power. Nokia's Symbian OS is a good example of this.

[kingsqueak]

well then, i guess it's nice to know i'm not learning a dead language :p

Heh, dead...no way.

Biggest mistake I ever made was learning to 'program' using Perl and other interpreted languages. I skipped over fundamentals that I have an impossible time trying to discipline myself to learn in C now.

You learn plain old ANSI C well now and you can use anything else later on with impunity.

Wait til later on when you see the atrocities that 'programmers' that never grasped the fundamentals commit. I'm talking about things like enterprise apps where they buy bigger and bigger hardware to run a Java app thinking it's too big and powerful for smaller hardware...but when audited you find two OPENs for a single CLOSE on a database connect. I'm serious too, this crap is very very common.

I audited a particular 'app' that was processing logs for audit reports not long ago. The original was taking 3 hours to run and they had setup massive swap partitions for it to work. Took me an hour to see they overlooked a fundamental issue of how to do their sorting. By simply using hash tables I got it to run in a few _minutes_ and it would run on a PC if we wanted it to, let alone a $50k Sun machine.

I'm no programmer, I'll stick to sysadmin thanks very much, but most of my job security comes from lousy programmers killing a system.

Learn your ANSI C well and you'll have work until yer dead.