26 Aug, 2013, Davenge wrote in the 1st comment:
Votes: 0
Smaug C

So, I've written a piece of code to make it easier to spit out data in an array to a character so I don't have to use forloops everytime in the middle of my code.
It looks like this:

const char *array_to_string( const char *const array[] )
{
static char buf[MAX_STRING_LENGTH];
size_t x;

buf[0] = '\0';
for( x = 0; x < sizeof( array ) / sizeof( array[0] ); x++ )
strcat( buf, array[x] );

return buf;
}


What's happened is its only ever reading array as one entry large. So, it will spit out the first one then quit. I did a bug message to test sizeof( array ) / sizeof( array[0] ) and sure enough it was 1.

I think I know why this is happening, but anyone know of a way to make this work?

Thanks, Davenge
26 Aug, 2013, Aelius wrote in the 2nd comment:
Votes: 0
You can use memcpy():

char buf[MAX_STRING_LENGTH];
memcpy(buf, array, sizeof(array));
buf[sizeof(array)] = '\0';
26 Aug, 2013, Davenge wrote in the 3rd comment:
Votes: 0
I tried memcpy, that didn't seem to work. I probably didn't do it right, who knows. It spit out gobble-dee-gook.

I figured out the workaround I was looking for though, I just pass it the limit of the array and that works fine. I would have loved to have made it just take an array and figure that out on its own. But, this achieves what I want and is was better than how I was doing it!

Thanks Aelius for the input.
27 Aug, 2013, Kaz wrote in the 4th comment:
Votes: 0
Although it looks like you can, you can't pass arrays as function arguments; only pointers.

The reason the size is 1 is because the argument is really this:

const char *const *arr


So you're dividing the size of a char** by the size of a char* (which is usually the same in both cases).

You'll need to pass in the length as another argument.
27 Aug, 2013, Davenge wrote in the 5th comment:
Votes: 0
Did. That's what my previous post was :D
27 Aug, 2013, Davenge wrote in the 6th comment:
Votes: 0
And yes, that's what I was thinking Kaz. Though, there should be some way to figure it out.
27 Aug, 2013, quixadhal wrote in the 7th comment:
Votes: 0
If you're passing in an array of strings to a function like this…

char *func(const char **arr);

Try using sizeof(*arr) and see what that gives you?
27 Aug, 2013, Davenge wrote in the 8th comment:
Votes: 0
That's a thought, okay. I will give that a whirl tonight.
28 Aug, 2013, Tyche wrote in the 9th comment:
Votes: 0
sizeof() is calculated at compile time.
28 Aug, 2013, quixadhal wrote in the 10th comment:
Votes: 0
Tyche said:
sizeof() is calculated at compile time.


That's why we can never have nice things.
It's also one of the reasons I hate C programming nowadays, the lack of a native string type being the biggest one.
28 Aug, 2013, donky wrote in the 11th comment:
Votes: 0
All the confusion here, was caused by people not knowing how the language works. Let's not put this one on the C programming language.
28 Aug, 2013, quixadhal wrote in the 12th comment:
Votes: 0
Oh, it's ALL on the C programming language!

Using C for a text based game is like driving screws with a hammer. It works, but it sure is messy and good luck when you need to adjust anything.
28 Aug, 2013, KaVir wrote in the 13th comment:
Votes: 0
A bad workman always blames his tools.
29 Aug, 2013, Davion wrote in the 14th comment:
Votes: 0
Davenge said:
And yes, that's what I was thinking Kaz. Though, there should be some way to figure it out.


AFAIK, no ;). Like Tyche said, the sizeof operator determines the size at compile time. All your variables are sized during run-time. Have you consider adding your own datatype?

struct dynamic_array
{ void ** array;
int len;
};


Then instead of passing **char's around, you just use a datatype that keeps track of its current size. You could also do it the way c-strings do it and include a NUL terminator. Then get size could just loop till it finds the end, then return it.
29 Aug, 2013, quixadhal wrote in the 15th comment:
Votes: 0
Sorry KaVir…

I prefer

str += "Another line of output\r\n";


rather than…

if(str = realloc(str, strlen(str) + strlen("Another line of output\r\n") + 1))
strcat(str, "Another line of output\r\n");
else
abort("Cannot allocate memory!");
29 Aug, 2013, Tyche wrote in the 16th comment:
Votes: 0
But C can be used to build nice things, like…….. Perl and Ruby. ;-)

I recall John Viega of Lima mudlib fame created a nifty safe string library for C.
You can fetch it at http://www.zork.org/safestr
… however you need to go through the wayback machine as it's offline.
29 Aug, 2013, Runter wrote in the 17th comment:
Votes: 0
Well, good workmen don't use tools not fit for the job.

Anyways, nothing wrong with C. For some purposes C is fantastic. There is some overlap with mud development and certain common bottlenecks.

In general the reason I disregard needing to concern myself with bottlenecks in mud dev is 1) you can still write clutch modules in C even if you're using a high level language and 2) most of the time hunting bottlenecks is a red herring unless you have 10,000 players concurrent already.

Also, year after year the resource gains with C translate more and more into smaller amounts of $$$ saved on hosting, or hardware. Time for many of us = far more $$$. But some people do like to paint the mona lisa on an etch-a-sketch. Just depends on what is fun to you.
29 Aug, 2013, Kaz wrote in the 18th comment:
Votes: 0
Davenge said:
And yes, that's what I was thinking Kaz. Though, there should be some way to figure it out.


Alas, not in C. That was left to C++, which can have a reference to an array (only if statically allocated; dynamically allocated arrays are always pointers):

template <typename T, size_t N>
size_t length_of_statically_allocated_array(T (&arr)[N])
{
return N;
}

int main()
{
char foo[769];
printf("%d\n", length_of_statically_allocated_array(foo));
}
29 Aug, 2013, Rarva.Riendf wrote in the 19th comment:
Votes: 0
KaVir said:
A bad workman always blames his tools.


A good workman choose his tools depending on the job.
IF he cannot do otherwise, he can stil lwork, but it will be sub efficient.
And if he knows he will have to work a lot on the same subjet, he will invest in better tools.

A bad workman will blame whatever anyway.

I did migrate my old rom based mud to compile in C++, it did not take that much time.
Stlil compile in C for now, but I will not give a second thought about using any tool C++ provide that would ease my life from now on.
29 Aug, 2013, KaVir wrote in the 20th comment:
Votes: 0
I'm referring to the fact that quixadhal gave wrong information about C, then blamed the language when someone pointed out he was wrong.
0.0/23