Don’t write using namespace std;.

You can, however, in a CPP file (not H file) or inside a function put individual using std::string; etc. (See SF.7.)

#include <iostream>
#include <string.h>
#include <stdio.h>

Why do you use both iostream and stdio.h in the same function? You should stick with the C++ version. Likewise, why do you need string.h? Even if you did need some special feature from there that is not easier using the C++ stuff, you should use #include <cstring> instead.

char v[20];
int sign, n, i;
float result, nr, aux, c;

Do not declare all the variables at the top! I just saw a presentation by Kevlen Hennelly where he quipped, “Are they scared of the code?” and “Is it so cold, they are huddling together like penguins!”

Declare the variables where they are first needed and you are ready to initialize them. Put them in the smallest scope possible.

The char array is ominous. Why not a string or somesuch? Why 20?

while (1)

I think maybe you don’t know about the bool type.

Your program is one huge function. First, separate I/O from the actual work. This is not just good organization, but is more realistic of real-world code. Imagine you want to move it to a GUI — your console calls are mingling with the code that does the real work!

So, write a function:

ValueType calculate (std::string_view input) { ⋯

and a function

void interaction()
{
    for (;;) {
        std::cout << "expression: ";
        std::string input;
        std::getline (std::cin, input);
        auto result= calculate (input);
        std::cout << "result might possibly be " << result;
    }
}

And you can have another function which does automated testing. You don’t have to type a bunch of samples manually each time you try it!

void test()
{
auto y= calculate ("1+2*3");
VERIFY (y, 7);
y= calculate ("0*42 + 17");
  ⋮
}

Notice I used ValueType? What data type are you using for the calculator values? Declare that at the top and use the alias when referring to this purpose.

using ValueType = float;

but I wonder why you intentionally limit things to single-precision? It doesn’t make sense to not use double here. And, you might want to use an extended or arbitrary precision type (e.g. Boost.Multiprecision) or do BCD math or whatnot. It should be as easy to change as changing this one line.

    while (i<n)//loops only once through the array

Don’t go through the string using index values. Use iterators. Most of the time you can just use a range-for loop, but here you often refer back to the previous character.

  const auto End= end(input);      
  for (auto it=begin(input); it != End;  ++it) {

        while (v[i] >= '0'&&v[i] <= '9')//builds the number

There is a library function isdigit.

You don’t seem to be able to read the decimal point or exponent.

What I do is separate the lexing and digesting steps: scan a “word” (token) that is a numeric value, but you just have the range of characters making it up. Then, pass that to another function to produce the value from the string. There are library functions for doing this, so you don’t have to write a parser for floating point literals yourself. (But if you wanted to, you still have it in a function that does only that.)

The body here is way too long, because each case is large itself.

How about the body of the loop being:

    auto nr= read_number (it);
    char op= read_op (it);
    process (nr, op);

That is, break it up into logical pieces. This is a very important lesson.

            if (!aux)
            {
                aux = nr * sign;
            }
            else if (c == 1)
            {
                aux *= nr*sign;
            }
            else
            {
                aux /= nr*sign;
            }

You have nr*sign repeated just about everywhere. I think maybe you should have applied the sign to the number read right away and then nr holds the right value, positive or negative. You don’t have to do this step everywhere; just once.

Some people will say to always put braces around the body even if it is only one line. I’m with Kevlen who says, “make it a goal to get it down to just one line instead” Puffing up the code, when it is simple code like this, just makes it harder to see and makes less fit on the screen.

A big concern is that your calculator does not seem to be based on an understanding of grammar, but is ad-hoc logic based on know the exact form of the input. I suppose aux might considered an operand precedence stack of depth one, but the code doesn’t reflect this understanding.

As an autodidact, you might not always know what is there to be known and what order is good to explore things in. Terms to search on to get a handle on this subject: parsing and pushdown automata, “context free grammar”, and “pumping lemmings” (when you grasp the joke, you are going down the paved path).

Keep it up! And best of luck to you.