Question:I ran into a point where it would be very helpful to send a function a portion of an array, instead of the entire thing. Now i can think of a couple work arounds like sending the whole array and a begin number, and range number, then computing off of that, or making a second array with only the portion needed and sending it.

I am hoping however that there is a simpler way.

int myfunc(array[]) {}
x = myfunc(array[from a to b]);

is essentially the idea though I am certain its not in syntax.


Reason: In my programming a calculator I am ending up with some what is fairly convoluted code to essentially make it take any equation entered, compute it and return its output. And I would like to save 8 lines of code and hopefully a few steps for the processor.

as in:
string equation = 3+(42*-3.46);
answer = value_of(equation);
where value_of() is an absurdly complex function hehe

Given you're using std::string you have many easy alternatives:
1. Use
basic_string substr(size_type pos = 0, size_type n = npos) const;
Returns a string composed of copies of the lesser of n and size() characters in this string starting at index pos.
Throws an out_of_range exception if pos > size().

2. Use this constructor which creates new string object using a substring of an existing strnig object: basic_string (const basic_string& str, size_type pos, size_type n= npos, const allocator& a=allocator());

If you're really concerned abt teh performance, you might wann use char* instead of std::string. In this case if you want to pass a sub string, the begin part can be taken care of by pointer arithmatic. The end part is tricky and it would be best (in terms of performance) if you pass another integer to indicate the end.
E.g.

void comlex_func( char* equetion, const int length ) ;

int main()
{
    char equation[] = "1+2+3*4" ;
    //say we want to pass "2+3" part to function.
    comlex_func( equation + 3, 3 ) ;

    return 0;
}

I think you need to re-assess how to do this very carefully. At the moment it will fail somewhere down the line.

void comlex_func( char* equetion, const int length ) ;

int main()
{
    char equation[] = "1+2+3*4" ;
    //say we want to pass "2+3" part to function.
    comlex_func( equation + 3, 3 ) ;

    return 0;
}

Just a warning...

void comlex_func( char* equetion, const int length ) ;

int main()
{
    char equation[] = "1+2+3*4" ;
    //say we want to pass "2+3" part to function.
    comlex_func( equation + 3, 3 ) ;

    return 0;
}

void comlex_func( char* equetion, const int length )
{
    printf("What I got is: ") ;
    for( int i = 0; i < length; i++ )
        printf( "%c", equetion[i] ) ;

    printf("Beware the null char is not at teh end of supplied length: %s", equetion ) ;
}

I think you need to re-assess how to do this very carefully. At the moment it will fail somewhere down the line.

Just wondering what problem do you see.. ?

>Just wondering what problem do you see.. ?

I don't see a problem thus far. You've gotta split the array into tokens. I was just saying without careful planning for every possible outcome it is likely to fail. His/her design at the mo looks very simplistic, almost as if she/he's doing as she goes.

Just a warning...

printf("Beware the null char is not at teh end of supplied length: %s", equetion ) ;
}

So? We aren't dealing with a string at this point. It's an array of characters. An array of character values does not need a null at the end. Only an array of characters representing a string.

Reason: In my programming a calculator I am ending up with some what is fairly convoluted code to essentially make it take any equation entered, compute it and return its output. And I would like to save 8 lines of code and hopefully a few steps for the processor.

This is a very bad reason to do anything. Assess what something easier means. Does it make the code harder to read? Do you have to resort to tricks to accomplish your goal? Will these tricks compromise maintainability (making it harder to change the code later)? Just trying to save a couple nano-seconds of processor time is not a good thing. Readability should not be compromised.

This article has been dead for over six months. Start a new discussion instead.