Function Template

[r895]

I am trying to write a function template to receive an array of any type of data. The function should return the average of the first 3 elements of the array and the return value will be the same as the type of data in the array.

I am new to function templates. When I run my code I get an error message that states: subscript is not of integral type. This error message is in the total area of the function.
If anyone can help me figure out my error I would appreciate it.
Thanks,
R.

Here is my code:

#include <iostream>

using namespace std;

template <class T>
T Data(T array[])
{
    T average;
    T total = 0.0;
    T cnt;
    T num;
    
    for(cnt = 0; cnt < num; cnt++)
        total += array[cnt];

    return average = total / 3;
}



int main()
{
    int Array[] = {2, 3, 4, 5, 6, 7};
    float Array2[] = {4.5, 6.7, 7.5, 9.5};

    cout << Data(Array) << endl;
    cout << Data(Array2) << endl;



    system("pause");
    return 0;
}

[Elkvis]

when you pass an array to a function it normally decays into a pointer. declare your function template like this to make it work with arrays:

template <typename T, int Length>
T Data(T (&array)[Length])

or better yet, use std::vector.

[r895]

Thank you Elkvis for your quick reply. I change the template like you showed by I still get the error: subscript is not of integral type at the total area of the function. If you have any further information I can use I would appreciate it.

Thanks,
R.

[Elkvis]

Show your current code.

[r895]

Here is my current code:

Thanks,
R.

#include <iostream>

using namespace std;

template <typename T, int Length>
T Data(T (&array)[Length])
{
    T average, total;
    
    for(T cnt = 0; cnt < Length; cnt++)
        total += array[cnt];

    return average = total / Length;
}



int main()
{
    int Array[] = {2, 3, 4, 5, 6, 7};
    float
        Array2[] = {4.5, 6.7, 7.5, 9.5};

    cout << Data(Array) << endl;
    cout << Data(Array2) << endl;

    system("pause");
    return 0;
}

[Elkvis]

on line 11 you could say

total += array[floor(cnt)];

or just change cnt to be an int. there's no reason why it needs to be anything else, regardless of what T is.

[r895]

Thanks Elkvis for your reply. For all your information I finally got the program to work!

Thanks,
R.

[Elysia]

or better yet, use std::vector.

...Or std::array, depending on your needs.

[brewbuck]

on line 11 you could say

total += array[floor(cnt)];

or just change cnt to be an int. there's no reason why it needs to be anything else, regardless of what T is.

The second suggestion is really the only correct one. As the variable is used to index an array, it should at the very least be unsigned as well, and the absolute best would be to use std::size_t.

[King Mir]

The second suggestion is really the only correct one. As the variable is used to index an array, it should at the very least be unsigned as well, and the absolute best would be to use std::size_t.

size_t is a mistake. It's a better policy to prefer int everywhere, so you avoid bugs with unsigned underflow.

[laserlight]

size_t is a mistake. It's a better policy to prefer int everywhere, so you avoid bugs with unsigned underflow.

It's a better policy to fix bugs than to try and pretend that you avoid them by using a signed integer type everywhere instead of an unsigned integer type where it makes sense.

[grumpy]

size_t is a mistake. It's a better policy to prefer int everywhere, so you avoid bugs with unsigned underflow.

With signed basic integral types, underflow or overflow result in undefined behaviour. With unsigned basic integral types, the effects of underflow or overflow are well defined (i.e. modulo arithmetic) but that behaviour is less than desirable if the variable is being used as an array index).

From that perspective, in terms of avoiding bugs, there is no advantage of signed or unsigned integral types as an array index. Both will give bugs on underflow if used as an array index.

I suspect your point is that using a for loop of the form

for (i = array_size - 1; i >= 0; --i)
{
   /*  access array[i] */
}

works if i is of a signed type, but never terminates if i is of an unsigned type (since it can never be negative). However, it is possible to safely iterate backward using

for (i = array_size; i > 0; --i)
{
     /*  access array[i-1]  */
}

(which works wither i is signed or unsigned) or

for (i = 0; i < array_size; ++i)
{
     /*  access array[n-1-i]  */
}

(which also works whether i is signed or unsigned (as long as n is the same)).

It is also possible to do this;

for (i = array_size-1; i < array_size; --i)    /*  assume array_size < maximum value that i can represent */
{
     /*  access array[i]  */
}

which only works for i of unsigned type, and gives undefined behaviour if i is of a signed type.

The trick is understanding the tools you're using - use a hammer as a hammer, not as a screwdriver. That is the way to avoid bugs.


Generally speaking, since array indices cannot be negative (unless working with a pointer to an element in the middle of an actual array), there is a logical benefit in using an index of unsigned type.


Of course, in C++, one can use iterators, or one can use the new-style for loop "for (auto &x: array)" and the whole problem of signed or unsigned indices goes away.

[Elysia]

I like to signed integers whenever possible since it makes it easier to detect bugs. Instead of getting an underflow, you can slap in an assert wherever to check that something isn't negative (which means you found a bug that must be corrected).
Trying to check if underflow has occurred by checking against the highest possible numbers an unsigned int can represent seems like a hack since it IS a valid number, while a negative one isn't.

[phantomotap]

Instead of getting an underflow, you can slap in an assert wherever to check that something isn't negative.

O_o

No. You can't.

For one thing, most everyone disables assertions for a release builds, and removing any code that validates domain/range is usually incorrect. Sure, you may not care if your texture in a game is mirrored, but this code example here is writing to a calculated index where without the validation constitutes a serious security bug.

As grumpy says, the overflow/underflow of signed integers is undefined. Treating signed integer overflow/underflow as undefined allows compiler to remove otherwise unnecessary code. However, allowing signed/unsigned overflow to "do whatever" is only part of the story. Compilers can and will use the fact to remove certain code.

void DoSomething
(
    int f
)
{
    for(int c(f); c >= 0; ++c)
    {
        // do something
    }
}

The code looks fine, but the bug is obvious to people who fear signed overflow/underflow.

(At least, obvious in this context.)

void DoSomething
(
    int f
)
{
    if(c >= 0)
    {
        while(true)
        {
            // do something
        }
    }
}

The code here is, yes, a valid interpretation of the previous example. Saying signed integer overflow/underflow may "do whatever" may be interpreted with such code as "A signed integer greater than or equal to zero will never become less than zero with addition.".

Many similar interpretations exist which change the meaning of other code you may think is safe including code that uses an assertion.

Soma

[Elysia]

No. You can't.

Errr...? Who says you can't, or for what reason? Whether it's a good or bad thing depends on the context, of course. It can be a serious bug or it can be a minor bug.

For one thing, most everyone disables assertions for a release builds, and removing any code that validates domain/range is usually incorrect. Sure, you may not care if your texture in a game is mirrored, but this code example here is writing to a calculated index where without the validation constitutes a serious security bug.

My point was that it's harder to detected unsigned underflow than to detect negative numbers.
It makes detecting "underflow" easier, which makes it easier to find bugs you should fix. It can also serve as a domain validator more easily so you can do your security checks for account balances, etc.
I'm not saying you should always guard with an assert. Whether or not you use an assert depends on the context. Regardless, it is better to slap an assert if you don't expect a number to be negative than to do nothing. Is an assert enough? That, as you say, depends on the context. Having mirrored textures might be cheaper than creating and maintaining real code that fixes this. Nevertheless, you might want to be able to spot and fix these in debug builds.