Not enough variables.

I want to right a program that will take any set of numbers and average them. I need a lot of variables to do that and I want to know if I can have the program declare variables as the user enters in numbers all having different names. Can you show me how?

C-Compiler

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

You can ask the user to enter the total number of integers he wants to take the average of..store that in a variable....then you can dynamically allocate an integer array of that size using the "new()" function.....
then you will have an array of integers to work with...take sum of all elements and divide.

"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.

What is the point for that? When you compile the program and a user executes it the variables don't have any purpose. They don't have "names", they are just memory locations. In other words, what purpose could it serve for the user to name variables of the program?

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.

Quote:

---

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.

Quote:

---

Originally Posted by cpjust

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.

---

Probably because his question seemed to lean towards that route. I'm questioning whether it's what he really wants though.

From some other posts he's made, it seems like he's fairly new to programming; I think what he really wants is just a dynamic array. If this is the case, do some research on dynamic arrays, and realloc

One of the things I miss most about Perl is hashes with named elements. A Perl hash beats setting up a map type function with arrays and structs any day.

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) ;

---

Yeah I can't see the need for anything else than constant memory either. This seems like a classical XY problem where a person has a problem X and though of a solution Y and asks about Y instead of X. Just sum them up as you read them, then divide by the amount read.

As for mappings, unless you have some specific naming scheme the indexes of an array can serve as the mapping to values.

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

Quote:

---

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".

Quote:

---

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.

Quote:

---

Originally Posted by Elysia

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?

---

We are talking about a difference in complexity (assuming a good hash function), not some constant factor difference due to implementation.

Quote:

---

Originally Posted by matsp

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.
--
Mats

---

What am I, the invisible man now??? ;)