Thread: Not enough variables.

You want a "map".
Google up some source code, because there isn't any standard implementation in C (as opposed to C++).

"new" isn't available in C. Only malloc is.
The problem with that is that it won't allow you to "name" your variables.
But if you just want to average the sum, sure it works.

Originally Posted by C_ntua

The best way to do this is use a pointer which will start with dynamically allocating one int. Then it will realloc() each time the user enters a new variable one more memory space. If you want it to have a name, more likely a "virtual name" then you can create a struct like:

Code:

struct virtualVariable {
   int value;
   char* name; //or char[MAX_CHARACTERS];
}

and again have a pointer to a *virtualVariable pointer that will realloc() structs. Each time you can also save the name for your virtual variable.

This is the map's purpose.

But why use a map?
You only need the values of the variables, not the names of the variables.
A dynamic array of int's, double's or whatever is all you need.

Unless you have a working implementation. C can be just as effective as Pearl or better.
Or better yet, if you use C++, then you have your quick map ready to use, since it's in the standard library.

You need two variables. One to keep the number of values entered, and the other to keep the accumulated sum of all every value entered, such as

Code:

int count = 0 , accum = 0 ;

do { 
	count++ ; 
	accum += users_latest_value ; 

} while (input is a number ) ; 

printf("The average is %d\n", accum / count) ;

Yes, as OnionKnight says, the problem can be solved with 3 variables: The number entered, a count of number of values entered, and a sum of the values so far. (plus possibly one more for loop counting if we use a "how many numbers" question at the beginning, rather than a "enter <X> to end" [where X typically is -1, 0 or some such] "sentry ending loop").

Unless you also need to do other things with the values entered, there is no need to save all the values entered.

As to the discussion about maps and Perl hashing. As Perl is written in C, I doubt that C would be slower than Perl, given an equal implementation. I have seen mentions of a hashmap that is supposed to be better than std::map - but it takes a pretty huge table before the difference makes any noticable difference (like hundreds of thousands of entries or more - as map is O(logn), so the number of compares to search a 1000 entries is 10 - not exactly an ardeous task in a modern computer).

--
Mats

Originally Posted by matsp

As to the discussion about maps and Perl hashing. As Perl is written in C, I doubt that C would be slower than Perl, given an equal implementation. I have seen mentions of a hashmap that is supposed to be better than std::map - but it takes a pretty huge table before the difference makes any noticable difference (like hundreds of thousands of entries or more - as map is O(logn), so the number of compares to search a 1000 entries is 10 - not exactly an ardeous task in a modern computer).

My impression is that Viper187's point is simply that C lacks a map construct that is provided by either the core language or the standard library, and that even if one was provided, Perl hashes provide some syntactic sugar that will still allow it to trump a C version in terms of "writability".

Originally Posted by matsp

...I have seen mentions of a hashmap that is supposed to be better than std::map - but it takes a pretty huge table before the difference makes any noticable difference (like hundreds of thousands of entries or more - as map is O(logn), so the number of compares to search a 1000 entries is 10 - not exactly an ardeous task in a modern computer).

Now that's a pretty big assumption, seeing as all compiler vendors are allowed to implement their std::map differently - so there is no "one" implementation of std::map, so I cannot think that is a valid statement or fact.
Is it faster than ALL std::map implementations or just one? If it's just one, then it's would probably just be bragging.