Program involving pointers/class/vectors

[bool maybe]

I wrote a program that works fine but to be honest I'm not quite sure why it works. I was kind of guessing as to how to do it but I would want to know why it works and even if I went the right way about implementing it.

The program reads in a list of people, their best friends (one per person), and determines their popularity which is determined by starting at zero and incrementing by one for every person that has them listed as a best friend.

#include <iostream>
#include <string>
#include <vector>
#include <iomanip>

using namespace std;

class Person
{
public:
	Person(string name = "N/A", short popularity = 0, Person* bff = NULL);

	string get_name();
	void set_name(string name);

	short get_popularity();
	void set_popularity(short pop);

	string get_bff();
	void set_bff(Person* bff);
private:
	string name;
	short popularity;
	Person* bff;
};

int main()
{
	

	cout << "Enter length: ";
	short n;
	cin >> n;

	vector<Person*> list;

	for(short i = 0; i < n; i++)
	{
		cout << "Enter name of individual: ";
		string name;
		cin >> name;
		list.push_back(new Person(name));
	}

	
	for(short i = 0; i < n; i++)
	{
		cout << "Enter name of " << list[i]->get_name() << "'s friend: ";
		string name;
		cin >> name;
		for(short j = 0; j < n; j++)
		{
			if(list[j]->get_name() == name)
			{
				list[j]->set_popularity((list[j]->get_popularity())+1);
				list[i]->set_bff(list[j]);
			}
		}
	}


	for(short i = 0; i < n; i++)
	{
		cout << "name: " << setw(8) << list[i]->get_name() << " popularity: " << list[i]->get_popularity() << " bff: " << setw(8) << list[i]->get_bff() << endl;
	}

	for(short i = 0; i < n; i++)
	{
		delete list[i];
	}

	cout << "Enter a character: ";
	string exit;
	getline(cin, exit);
	getline(cin, exit);


	return 0;
}

Person::Person(string name, short popularity, Person* bff):
name(name), popularity(popularity), bff(bff)
{
}

string Person::get_name()
{
	return name;
}

void Person::set_name(string name)
{
	Person::name = name;
}

short Person::get_popularity()
{
	return popularity;
}

void Person::set_popularity(short pop)
{
	popularity = pop;
}

string Person::get_bff()
{
	return bff->get_name();
}

void Person::set_bff(Person* bff)
{
	Person::bff = bff;
}

I don't understand line 55. It seems to me like I shouldn't use -> since I think link[j] is already a pointer so by using -> it would almost seem like I should have used link[j].set_popularity... instead of link[j]->set_popularity... but that doesn't work for some reason. Could someone describe to me why this code works and also if it looks decent or if there's some way it could be improved? Thank you.

[TheIdeasMan]

Hi bool maybe

list is a vector of pointers, so that's why you need the -> operator as well as the vector index.

HTH

Edit:

Naming a variable that is a vector, as list could be confusing because of the STL <list> container.

[Volatile Pulse]

bool maybe wrote:

I don't understand line 55. It seems to me like I shouldn't use -> since I think link[j] is already a pointer so by using -> it would almost seem like I should have used link[j].set_popularity... instead of link[j]->set_popularity... but that doesn't work for some reason. Could someone describe to me why this code works and also if it looks decent or if there's some way it could be improved? Thank you.

You have to use the -> operator when using a pointer of a class. Essentially, the -> operator does the same exact thing as this:
(*list[j]).set_popularity(((*list[j]).get_popularity())+1);

Which is the same as what you wrote:
list[j]->set_popularity((list[j]->get_popularity())+1);

As you can see, the -> dereferences the pointer first, and then calls the accessor function set_popularity(). It is more of a shortcut than anything, but remember the -> operator is for object pointers while the . operator is for object variables.

As for the rest of your code, I agree that naming something list, especially some type of container, should be avoided. Maybe rename it something more descriptive like personList, or better yet, what about personVector (it is a vector after all)?

Something else I noticed is that at the top of your program (where you declare your class) your class member's don't have a unique name (typically they're identified by using a lowercase m first or m_) and when you call your constructor, the parameter names share the name as your members. This can cause issues when you're assigning the values from the function to your member class. Ways around this is change the names of your member variables (recommended), change the name of the parameters, (somewhat recommended), or both (highly recommended).

Something to consider is that instead of seperating your member functions from the class definition, just write them in the definition (they're incredibly short, mostly one liners). This will save a lot of unnessecary lines in your code and make it so the person doesn't feel like they're reading the same thing over and over again.

Last thing I noticed is that you ask the user to enter the number of people they want to enter. Then you create your vector. Instead of just pushing back your people in the loop, you should set the size of the vector upon construction. This will prevent the vector from constantly having to find memory to allocate for each person added.

[TheIdeasMan]

You have to use the -> operator when using a pointer of a class. Essentially, the -> operator does the same exact thing as this:
(*list[j]).set_popularity(((*list[j]).get_popularity())+1);
Which is the same as what you wrote:
list[j]->set_popularity((list[j]->get_popularity())+1);

@Volatile Pulse

What you have said is right. However my view is that pointers to members is used so much, that is why the -> operator was invented. I find the second example easier to read because I have in my mind that j is a pointer. I would prefer to use the -> , rather than dereference and use the dot operator. It could get awkward if there are nested objects.

This is all my personal opinion, others may have different ideas.

@OP

Just a small matter of style, I try to avoid using single character variable names, for a couple of reasons:

1: i's & j's can be easily mixed up and make it hard to spot errors.

I once saw someone doing code with matrices - there were i's & j's everywhere. We couldn't spot the problem, so I suggested that she do a find/replace changing i to Row and j to Col. Almost straight away we could see the problem, there was a [Row] [Row] where it should have been [Row] [Col].

2: Meaning is clearer if you use a word - can anyone figure what this means?

for(int d= 255;d<259;d++)
     for(int m=55;m<59;m++)
          for(int s=0;s<3;s++)
               for(int st=0;st<10;st++)
                      cout << d << ":" << m << ":" << s << ":" << st <<endl;

It's easy to figure out the output, but what does it mean? See if you can guess.

Sometimes it makes more sense to use a single character, like when I wrote something to do with factorials. It was easy and clear enough to say factorial(N). I always comment variables.

It might be tempting to do it for array indexes say, even here I try to avoid it.

Hope this helps.

[Zephilinox]

not a clue, only that I hate it when people don't put spaces around operators, makes things so compact and hard to read.

3:3:3:9 [255-258 : 55-58 : 0-2 : 0-9]

some tricky shit is going on der, most stuff ends at 255/256, and odd that you would stop at 58 instead of 59, also why 0, 1 and 2? I'd expect 0 and 1, 0-9 is the only thing that makes sense to me on its own, but not when combined with the rest.

[Volatile Pulse]

Zephilinox wrote:

only that I hate it when people don't put spaces around operators

+1

That drives me crazy!. I find for loops (and a lot of other things with operators) much harder to read without spaces.

TheIdeasMan wrote:

i's & j's can be easily mixed up and make it hard to spot errors.

I completely agree with you. But the way the OP's code is laid out, there isn't much of a choice (I use i, j, k, l, m, n, o, p, etc. religiously in my programs that have nested for loops). I believe It has a lot to do with preference. Granted, there does come a time when you need to step back and ask what's really necessary, but as long as you're adding in proper comments (which is what I believe all the OP really needed to change in their program) then you shouldn't have any issues.

I completely agree that every variable should have a unique and very descriptive name, but for loops are my exceptions to that rule. Take this code for example:

// Pretend numOfPlayers is const;
Player gamePlayers[numOfPlayers];
// Fill In players info
// ...
// Fill the Board for the players
for (int playerNum = 0; playerNum < numOfPlayers; playerNum ++)
   for (int row = 0; row < maxRows; row ++)
      for (int col = 0; col < maxCols; col ++)
         gamePlayers[playerNum].gameBoard[row][col].gamePiece = NullGamePiece;

Now that one isn't so bad, I didn't think of a very long nested for loop, but the idea is that using descriptive for variables is nice, but it can make the code extremely long. I would simply use i, x, y here and just add a comment at the for loop describing what each loop does.

[bool maybe]

Thank you everyone for the comments.

Yeah, I realize that naming a vector "list" is probably as good of an idea as naming a variable "x" (which unless you're talking about xyz coordinates can be pretty ambiguous) however I decided to use "list" because I only had one vector and for such a small program I though it would probably be okay. I wouldn't make a habit of doing this for larger programs with more vectors.

@VP

I see what you mean by the member variable and parameter names. I was actually meaning to change it but I was so far in my coding that I figured I would just go along with it. I also agree with you on the push_back(variable) function.

I think the choice of my variable names in for loops (i's and j's) is fine.

I'm still feeling quite iffy about the -> operator. I'll read through the explanation provided earlier some more and read some more about it online and hopefully that will clear things up.

Thank you everyone for participating.

[TheIdeasMan]

Zephilinox wrote:

some tricky shit is going on der, most stuff ends at 255/256, and odd that you would stop at 58 instead of 59, also why 0, 1 and 2? I'd expect 0 and 1, 0-9 is the only thing that makes sense to me on its own, but not when combined with the rest.

My idea was to post an example and see how much it confused everyone - and that is what happened. I used 255 for the degrees and should have used "." as the separator in the hope that someone might have thought it was an IP address or something.

Here is the exact same thing with decent variable names:

int Deg =0;  //Degree Counter
int Min = 0; //Minute Counter
int Sec = 0; //Seconds Counter
int Tenths = 0;  //Tenths of seconds counter

for(int Deg= 255;Deg<259;Deg++)
     for(int Min=55;Min<59;Min++)
          for(int Sec=0;Sec<3;Sec++)
               for(int Tenths=0;Tenths<10;Tenths++)
                      cout << Deg << ":" << Min<< ":" << Sec << ":" << Tenths <<endl;

See how obvious that is - even without the comments it is fairly clear. Again I always comment & initialise variables at declaration.

Someone might have guessed my original example if I had used the ranges 0-360, 0-60, 0-60 & 0-10, however that would have produced 360*60*60*10 lines of output.

Volatile Pulse wrote:

Now that one isn't so bad, I didn't think of a very long nested for loop, but the idea is that using descriptive for variables is nice, but it can make the code extremely long. I would simply use i, x, y here and just add a comment at the for loop describing what each loop does.

The coding std that I try to stick to says that variable names shouldn't be longer than 10 chars, most of the time I can do 6 or 7 which is reasonable. I find this way strikes a balance between meaningful & not too long code.

I would nearly always use Row, Col for 2D arrays just like your example, for the reasons I mentioned earlier.

I once saw someone doing code with matrices - there were i's & j's everywhere.

That example was a large 2D array with a 5 by 5 array being used to do matrix operations on each 5 by 5 chunk of the larger array. It is easy to imagine how that can go astray.

I guess it does boil down to personal preference, and particularly the good use of comments.

Volatile Pulse wrote:

Instead of just pushing back your people in the loop, you should set the size of the vector upon construction. This will prevent the vector from constantly having to find memory to allocate for each person added.

In my understanding, vectors have a default capacity (worthwhile to find out what that is on your system, (same for me)). I have a vague idea that is is a reasonable size, so one can push_back happily for a quite awhile without any performance issues. The other thing is push_back places things at the end of the vector, so if you were to create a vector with 20 initialised values (0 say), then push_back something, you will still have 20 zero's at the start. I find it easy to create an empty vector, then push things into it. You can of course put things in via the array index, but I like the push_back better.

A further thing is to decide which is better for your situation, <vector>'s or <list>'s. A vector is just like an array that can be resized. Resizing is very inefficient, it copies the whole thing somewhere else in memory. There are strategies for resizing such as doubling the size each time so as not to resize very often ( I learnt this the other week from Peter87). I still think that, if the vector is going to grow a lot, you are better off with a <list>. Being able to use an array index on the vector is often very convenient.

A <list> is a double linked list, so adding something anywhere is achieved by manipulating the item pointers (internally), so this is very efficient. There is some overhead when using small object like an int, because the list has to store 2 pointers for each object, so anything bigger than 3 ints would be ok (not hard to come across in real world)

So, I like to use vectors if they are not going to change in size much, and a list if they are, and a <map> (efficient for find & sort) if there are going to be a large number of them. A worst case scenario might be a vector of vectors - that would be at least 2N * 2M efficiency if both had to be resized - really bad.

As an example, I am having a go at the Sum of Product problem on Online Judge. It involves operations on sets of permutations. I made a permutation a <vector> , and I decided I wanted to keep some of them to aid my analysis of the problem. So I made a <list> of the permutation <vector>'s

Any way that's enough of rambling on and on in some one else's thread, hope it is useful.

[Volatile Pulse]

@TheIdeasMan
I'm not so sure you're right about vectors having a default capacity (at least that's not the case with g++ 4.7.1). I ran a simple test to double check:

#include <iostream>
#include <vector>

int main() {
   std::vector<int> myVector;
   std::cout << myVector.capacity();
   return 0;
}

I believe it's possible, but I don't see the reason behind having a default capacity.

@bool maybe
That is another alternative if you'd still prefer to use the push back option, you can set the vectors capacity to whatever size the user wants. This will allocate n places in memory for those people and then you can push_back new people (which will effectively resize the vector) and not have to worry about the issue of the vector constantly having to reallocate.

Another alternative is to use the new Person[n] and eliminate the need for a vector or anything else. The only difference between doing it this way and a typical array is that the array size doesn't need to be constant (you would need to manually resize the array if you needed it bigger) but you would still have to delete[] personArray somewhere once you're done so you don't have a memory leak.

@TheIdeasMan
The list is the better way to go, but it also doesn't have the feel of an array (which is why I love vectors) so I tend to avoid them unless the size of the list is going to grow very large. The idea you got from Peter87 about doubling the vector size is a great idea, but I also feel that it could cause problems later on. I'd suggest using the capacity option if you were going to do that.

A reason being is that when you resize, the vector automatically uses those spaces. If you just increase the capacity, the vector will "reserve" those spaces, but if the program gets low on memory (which is more likely in your case) those memory blocks are still available to the rest of the program (I could be wrong on that).

[TheIdeasMan]

@Volatile Pulse

http://www.cplusplus.com/reference/stl/vector/capacity/

// comparing size, capacity and max_size

#include <iostream>
#include <vector>
using namespace std;

int main ()
{
  vector<int> myvector;

  // set some content in the vector:
  for (int i=0; i<100; i++) myvector.push_back(i);

  cout << "size: " << (int) myvector.size() << "\n";
  cout << "capacity: " << (int) myvector.capacity() << "\n";
  cout << "max_size: " << (int) myvector.max_size() << "\n";
  return 0;
}

size: 100
capacity: 141
max_size: 1073741823

I am not sure what strategy is used to automatically adjust the capacity, you can always use vector::reserve to set it manually. Note that capacity returns the capacity, it doesn't set it.

Now going back to which is better, vector, list or map or set. It depends on the situation I think of it like this:

1: vector - isn't go to change in size much and is relatively small. E.g. permutation max size 20 say.
2: list - could be quite long, but probably only if you not going to do any operations on it (like find, sort etc), you just want to store everything. E.g. List of permutations
3: map or set- you have lots of objects (even only 100) and you want to find or sort them. E.g. 100 3D points. Points can have numbers and /or names

Of course you can find and sort vectors & lists, I am saying map or set is more efficient.

Maps and sets work with logarithmic efficiency as they are implemented as self balancing (AVL) binary trees.

http://en.wikipedia.org/wiki/Associative_containers_%28C%2B%2B%29

This might all seem a bit academic, but it becomes really important if you have to deal with a reasonable amount of data.

[Volatile Pulse]

@TheIdeasMan
It doesn't say anything about the default capacity being set, and for me, it doesn't have a default. Running the code, I get:

size: 100
capacity: 128
max_size: 1073741823

Commenting out the for loop, I get 0's for size and capacity, max_size stays unchanged (obviously).

And it really boils down to preference and need. I lean towards vectors more often then not, but I've found myself resorting to lists (a lot less frequently albeit) and maps from time to time.

[helios]

Terrible example:

for(int d= 255;d<259;d++)
     for(int m=55;m<59;m++)
          for(int s=0;s<3;s++)
               for(int st=0;st<10;st++)
                      cout << d << ":" << m << ":" << s << ":" << st <<endl;

Could anyone really have doubted that d, m, and s stand for degrees, minutes, and seconds? The meaning of st is more nebulous, though, since there's typically no smaller sexagesimal unit than seconds. I fail to see how "st" is short for "tenths".
The real problem with this snippet is not the choice of variable names, but the use of magic numbers with no discernible purpose.

[TheIdeasMan]

helios wrote:

Could anyone really have doubted that d, m, and s stand for degrees, minutes, and seconds?

Well, yes - someone might have easily thought they were IP addresses.

However, first I want to say that it is obvious to me that you have great knowledge & experience probably vastly more than me, so I don't mean disrespect, it is just that I am putting my views forward.

Zephilinox wrote:

not a clue, only that I hate it when people don't put spaces around operators, makes things so compact and hard to read.

3:3:3:9 [255-258 : 55-58 : 0-2 : 0-9]

some tricky shit is going on der, most stuff ends at 255/256, and odd that you would stop at 58 instead of 59, also why 0, 1 and 2? I'd expect 0 and 1, 0-9 is the only thing that makes sense to me on its own, but not when combined with the rest.

Now I can tell that Zephilinox is a switched on person and knows his stuff (Has given some great advice on this forum) and he said

not a clue

- Not a reflection on him in anyway, it is about the naming of the variables - which why I posted the example.

helios wrote:

I fail to see how "st" is short for "tenths".

It stands for "Seconds Tenths". So here the answer was given, and the poor variable name still causes confusion. Say someone knew that d,m,s was Degrees, Minutes Seconds but then are wondering what st meant. My whole point about using words rather than single chars.

I used that code to test some conversion functions I had - radians to degrees minutes seconds. I wanted to see that the rounding worked when seconds is 59.5 as 60 seconds is not allowed.

but the use of magic numbers with no discernible purpose.

I changed the values in the loops to make it harder for anyone to guess, that's OK because ones understanding shouldn't depend on what value a loop or other variable might have. As I said earlier, the loops don't to their full range, because that would output nearly 13 million lines, I only need to test small ranges.

Again, apologies to the OP for hijacking the thread, I have taken it for a few laps round the racetrack, am now cruising the streets, on the way to the pub. (:-D) Hopefully you didn't have any other questions of your own !!!! Hope it is useful to someone.

[helios]

ones understanding shouldn't depend on what value a loop or other variable might have

If you're trying to understand what the code actually does with the information, your understanding does depend on understanding why variables take the values that they take. For example,

const unsigned pi=0x290ED57A;

You know that the variable holds pi, but there's no way you'll understand why I mapped pi to that specific integer if I don't tell you. Likewise if I say "2*pi", it's evident that I'm multiplying that integer by 2, but can you tell me what it means within the context of this mapping?

[TheIdeasMan]

If you're trying to understand what the code actually does with the information, your understanding does depend on understanding why variables take the values that they take.

Perhaps I should have said "shouldn't solely depend on what value"

I think it is too much to expect someone to realise that m means minutes:

for (m=0;m<10;m++)

This might give a clue, but it is still too much - m could be anything:
for (m=0;m<60;m++)

Of course I could comment the variable at declaration, or before the loop, OK, but what about later on in the code - thinking "what was m again".

You know that the variable holds pi, but there's no way you'll understand why I mapped pi to that specific integer if I don't tell you. Likewise if I say "2*pi", it's evident that I'm multiplying that integer by 2, but can you tell me what it means within the context of this mapping?

Are we saying the same thing here? That code by itself doesn't mean much as to what or why. My whole point from the start.

So you could comment why that particular value was used - then I would know. You could come up with a more descriptive name for the variable. You could do both.

I guess my motivation for all this is that I see beginners writing code with single char or very short variable names throughout, and no or very few comments - and it just makes it harder to understand.

The big thing is whoever wrote the code knows what it means, but that doesn't help anyone else. In the real world, a maintenance programmer looking at code that was written by someone who left 2 years ago, hasn't got time to figure out what variables mean. It would be much easier if the original coder used a decent name to start with.

I have had direct experience with this. I worked for a short time in an IT department of a company that had $1Billion of sales per annum. The database we had, had to have unique field names across the whole database and they were limited to 40 chars in length. Looking at fieldnames, they seemed to be all the same except for the last 3 chars. The DB had 500 tables some with 300 fields. There was 500,000 lines of code and no documentation whatsoever. The only 2 guys who understood the whole thing were the two that wrote it. My small idea was to name fields with the table name, a delimiter, then a better fieldname. It was shouted down, because that's what Microsoft does, and they hated MS. My view was there are good & bad things about all software. Apart from the enormity of the system, looking at the code, I found it really hard to understand. It was good for the 2 guys who wrote it, they had almost guaranteed maintenance work, however if they had been killed in a plane crash say (It does happen) the company would have been in deep trouble, because no one else could understand the system.

Anyway, I have been to one pub with the OP's thread, am on to the next club. Haven't heard any complaints !!

[helios]

Your point was that single character identifiers are bad. My point is that sometimes they're acceptable, and that sometimes they're irrelevant because they're overshadowed by far bigger problems.

Why do I say that these identifiers are acceptable sometimes?
Looking at your original code:
for(int d= 255;d<259;d++)
This by itself is meaningless. All I can conclude is that d is an iteration index.

for(int d= 255;d<259;d++)
     for(int m=55;m<59;m++)
          for(int s=0;s<3;s++)
               for(int st=0;st<10;st++)
                      cout << d << ":" << m << ":" << s << ":" << st <<endl;

This, however, isn't. The colons provide very strong cues about the meaning of the variables. There aren't that many things that are written in *:*:* format and shortened to DMS. More context about the surroundings of the loop would have given even more evidence.
Of course, this is a very delicate balance. If you had named the variables 'superman', 'batman', and 'aquaman', or chosen '%' as the delimiter, it would have been much more difficult. Although in that case, I'd be compelled to ask why you're deliberately trying to confuse the user.
The problem is not really the length itself of the identifiers, but their meaninglessness. Shorter identifiers just happen to be meaningless more often.

[Zephilinox]

To be clear...

255-259 produces the numbers 255, 256, 257, 258, that rules out IP addresses since they stop at 255 and start at 0. (well, each byte does, in IPV4 anyway)

55-59 produces the numbers 55, 56, 57, 58, that rules out minutes because they stop at 59 and don't start at 55.

0-3 produces the numbers 0, 1, 2 that rules out seconds because they don't stop at 3.

if you had said 0-360 (because 360 degrees = 0 degrees), 0-60, 0-60, it would have been easy to figure out, the last one could have easily been guessed as a fraction, although I don't see why you would need it?

[TheIdeasMan]

@Zephilinox

TheIdeasMan wrote:

I changed the values in the loops to make it harder for anyone to guess,

I used that code to test some conversion functions I had - radians to degrees minutes seconds. I wanted to see that the rounding worked when seconds is 59.5 as 60 seconds is not allowed.
As I said earlier, the loops don't to their full range, because that would output nearly 13 million lines, I only need to test small ranges.

Zephilinox wrote:

that rules out IP addresses since they stop at 255 and start at 0

Yes it does, you are right.

that rules out minutes because they stop at 59 and don't start at 55.

0, 1, 2 that rules out seconds because they don't stop at 3.

No it doesn't, as per what I wrote above.

although I don't see why you would need it?

As per above.

helios wrote:

My point is that sometimes they're acceptable

Shorter identifiers just happen to be meaningless more often.

Yes, that's right - I agree. I have done factorial(N) before perfectly acceptable with comments.

I am saying it's not good to do it all the time, and there are lot's of situations where it can cause problems.

Any way, I think we have given this a thoroughly good bashing, any one wish to join me at the next club? ..................... :D

[Zephilinox]

it doesn't discount it, m < 10 is a lot different from m < 60, you're arguing short identifies like d, m, s, st are unrecognizable but only because you didn't write their for loops properly, the way someone who was actually coding it would have.

d m s and st are better than i j k l, which mean absolutely nothing in that context, for example in lua you would do this

for k, v in pairs(table) do

k is short for key, v is short for value

for (int i = 0; i < x; i++)

i is short for index

for (int r = 0; r < 10; r++)
...
for (int c = 0; c < 10; c++)
array[r][c] // or array[r*c] 

r is short for row, c is short for column.

[TheIdeasMan]

Zephilinox wrote:

it doesn't discount it, m < 10 is a lot different from m < 60, you're arguing short identifies like d, m, s, st are unrecognizable but only because you didn't write their for loops properly, the way someone who was actually coding it would have.

I am saying that someone shouldn't have to have m<60, just so someone else can understand.

I am saying that this code is perfectly clear to anyone, without them having to think / guess / work out anything, context or otherwise.

int Deg =0;  //Degree Counter
int Min = 0; //Minute Counter
int Sec = 0; //Seconds Counter
int Tenths = 0;  //Tenths of seconds counter

for(int Deg = 359;Deg < 360;Deg++)
     for(int Min = 55;Min < 60;Min++)
          for(int Sec = 55;Sec < 60;Sec++)
               for(int Tenths=0;Tenths<10;Tenths++)
                      //my conversion function call here 

you didn't write their for loops properly, the way someone who was actually coding it would have.

To be clear - I wrote the above code to test my conversion function radians to degrees minutes seconds. Output precision is to 1 second

The ranges aren't "complete" because I wanted to test what happened with rounding when seconds or minutes >= 59.5 as 60 is not allowed, I wanted to see that the minutes and degrees were rounded up correctly in this situation. Again if the ranges were "complete", the output would be 12.96 million lines. I should be entitled to test any range of values that I like

Sure the variables k,v,r,c in your examples are probably fine with comments, but key, value, row, col are pretty easy & obvious too aren't they?

And what of your views from the point of view of the maintenance programmer?

Anyway i am out to dinner (at a real pub !!!!!) :D