Function to count the length of the string

[parad0x]

Was sitting idle so wrote this. I used pointers instead of integers.

Code: (C++) [Select]

#include<iostream>

const int size = 5000;


int * strlen(char *, int );

int main(void){

char string[size];

cout << "Enter a string to find its length : ";

cin.getline(string, size);

int * len = strlen(string, size);

cout << "The string consists of " << (*len) << " characters." << endl;

delete len;

cin.get();

cin.get();

return 0;

}

int * strlen(char * array, int size){

int * len = new int;

*len = 0;

for (int i = 0; i < size; ++i){

if (array[i] == '\0')

break;

++(*len);

}

return len;

}

[Fur]

A common(ish) way is to do it like this:

Code: (C) [Select]

int strlen(char *stuff) {
    int len = 0;
    while (stuff) {
        *stuff++;
        len++;
    }
    return len;
}
Obviously it will only work with strings shorter than 2^31 due to the limitations of int.

Also, why are you freeing len just before the program exits? At least on Windows, a process' memory is freed when it terminates.

[bluechill]

Also, why are you freeing len just before the program exits? At least on Windows, a process' memory is freed when it terminates.

Because there is no guarantee it will be, plus it's also just good form.  Don't code for Windows specific, code to POSIX.

[parad0x]

Because there is no guarantee it will be, plus it's also just good form.  Don't code for Windows specific, code to POSIX.

That's why I freed the memory allocated.


You should always have a backup plan.

[Deque]

Your code could use some indentation. 

[Xires]

Because there is no guarantee it will be, plus it's also just good form.  Don't code for Windows specific, code to POSIX.

But Windows isn't necessarily POSIX-compliant, so...?

@parad0x; Why is 'len' a pointer?  On 32-bit systems, 'int' is 4 bytes & a pointer is also 4 bytes.  On 64-bit systems, 'int' is 4 bytes whilst a pointer is 8 bytes.  In this sense, making 'len' a pointer is a waste of space.  Also, you can define a starting value when using 'new'.

Code: (c++) [Select]

int *foo = new int(42);

Your loop can do your 'len' increment as well, though it really isn't necessary.

Code: (c++) [Select]

for (int i = 0; i < size; ++i, ++(*len))

As Fur attempted to point out, you can simply assign len the value of 'i' after you break out of the loop.  Granted, to do this, you'll need to declare 'i' before the loop.  Another issue is that 'break' will break the loop and your "++(*len)" isn't going to run, thus making the return a 0-based count.  The problem with this is that 'strlen()' returns the number of characters in the string, not the last index.  Finally, using 'int' as the return type is going to limit your number to half of the range that could be used.  Because it is impossible to have a negative number of characters, 'unsigned int' would be a more appropriate return type.  Of course, that still deviates from the standard 'strlen()', but it's a desirable modification for most.

For an additional challenge, I'd suggest trying to find a way to do it recursively.

@Fur; "while (stuff)" may be undesirable as it could cause an infinite loop, or worse.  Perhaps you mean the following:

Code: (c) [Select]

while (*stuff++) ++len;


[Fur]

@Fur; "while (stuff)" may be undesirable as it could cause an infinite loop, or worse.  Perhaps you mean the following:

Code: (c) [Select]

while (*stuff++) ++len;


Ah, no idea how I missed that. Thanks for the correction.

[parad0x]

  Another issue is that 'break' will break the loop and your "++(*len)" isn't going to run, thus making the return a 0-based count.  The problem with this is that 'strlen()' returns the number of characters in the string, not the last index.
For an additional challenge, I'd suggest trying to find a way to do it recursively.

As for your challenge, I accept it but I think you didn't get the point, the program gives the number of characters in a string, not the last index and I used that 'break' statement as if the char is a 'null', then we don't need to count it as null is automatically added to the end of the string( we all know that ).

[ArkPhaze]

What's wrong with the original strlen() function? http://www.cplusplus.com/reference/cstring/strlen

Having the value allocated on the heap, vs, the stack isn't going to give you really any added benefit. For C++ though, the string datatype has a length() function.

[Xires]

It's often useful to code your own version of a function that exists in the standard library.  If nothing else, it's most useful for understanding how it works, why it might work that way and there's always the programming exercise benefit.

[Kulverstukas]

It's often useful to code your own version of a function that exists in the standard library.  If nothing else, it's most useful for understanding how it works, why it might work that way and there's always the programming exercise benefit.

However once you reach that line where you can't be bothered to re-invent the wheel, you are better off using what is there already - libs are there to shorten the code and speed up the process.

[ArkPhaze]

It's often useful to code your own version of a function that exists in the standard library.  If nothing else, it's most useful for understanding how it works, why it might work that way and there's always the programming exercise benefit.

Why though? Unless you're aiming for performance gains, but in this case that function is worse than the original. If you absolutely needed a pointer to this value on the heap, it would be a different story, but without knowing the context in which this function *would* be used, this is not a case that demonstrates where it's useful to write your own implementation. Just my opinion though.

"If nothing else, it's most useful for understanding how it works, why it might work that way and there's always the programming exercise benefit." --- This is fun though, I agree with this.  I write stuff all the time just to see how I can get things to work.

I don't see the usefulness in this function, other than for learning purposes however.

However once you reach that line where you can't be bothered to re-invent the wheel, you are better off using what is there already - libs are there to shorten the code and speed up the process.

Exactly! A good programmer knows how the functions work and how to use them effectively. If it's a function that is lacking, THEN write your own. (+1)

Cheers

[chapp]

Also taking into consideration the overhead of allocating a new object every time you are calculating the length of a string, this function is a serious consumer.

[ArkPhaze]

Also taking into consideration the overhead of allocating a new object every time you are calculating the length of a string, this function is a serious consumer.

This was one of the reasons I mentioned liking the original function instead too. Perhaps once or twice, not much to be noticed, but in the cases where it is used in repetition, if you're looking at the performance of those iterations which is perhaps wrapped up in a more general function, you would notice the difference here vs the original because this is stack vs. heap allocation.