Jump to content

  • Log In with Google      Sign In   
  • Create Account


Need funcion to return char[]?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
21 replies to this topic

#1 Vanz   Members   -  Reputation: 204

Like
0Likes
Like

Posted 01 February 2013 - 12:08 PM

I have some old code I'm trying to work with and I need a function to return a name, so for example:

 

int cApp::ReturnInt(int &Temp)
{
Temp=5;
return 6;
}
 
... later code...
int A,B;
A=ReturnInt(B);

 

Returns A=5 and B=6 

 

Now I need to do this with a char[] name, like this somehow:

 

char[20] cApp::ReturnInt(char[30] &Temp)
{
strcpy_s(Temp, "123");        //Add 123 into Temp

return "456";
}
 
... later code...
char[20] A,B;
A=ReturnInt(B);

 

Which doesn't work of course, but I hope you get the gist of what I'm trying to do... I don't need it to return the name both ways (using return and &) just any way...

 

It's too hard for me to update all the code to string but if you have the time I'd also like to see how it's done with string...

 

Hope this makes sense...

 

Thanks,

 

Vanz



Sponsor:

#2 SiCrane   Moderators   -  Reputation: 9125

Like
7Likes
Like

Posted 01 February 2013 - 12:33 PM

With std::string it works pretty much like it does with an int.
std::string foo(std::string & temp) {
  temp = "123";
  return "456";
}

std::string A, B;
A = foo(B);


#3 Servant of the Lord   Crossbones+   -  Reputation: 14925

Like
1Likes
Like

Posted 01 February 2013 - 12:47 PM

As SiCrane is hinting at, with C++ always prefer std::string unless you have a real reason not to.


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.

[Fly with me on Twitter] [Google+] [My broken website]

All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.                                                                                                                                                       [Need free cloud storage? I personally like DropBox]

Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal


#4 Vanz   Members   -  Reputation: 204

Like
0Likes
Like

Posted 01 February 2013 - 01:07 PM

Thanks SiCrane, I think I can work with that...



#5 Vanz   Members   -  Reputation: 204

Like
0Likes
Like

Posted 01 February 2013 - 01:08 PM

As SiCrane is hinting at, with C++ always prefer std::string unless you have a real reason not to.

 

ya I do, like I said above I'm working with some really old code and it'll take too long to convert it all...



#6 ultramailman   Prime Members   -  Reputation: 1436

Like
3Likes
Like

Posted 01 February 2013 - 01:21 PM

You can't return arrays. Instead, you can return a pointer to char. You will have to pass in the return value too.
char * example(char Temp[], char * buf)
{
    //do work to temp, store result to buf
    return buf;
}


#7 Servant of the Lord   Crossbones+   -  Reputation: 14925

Like
2Likes
Like

Posted 01 February 2013 - 02:51 PM

As SiCrane is hinting at, with C++ always prefer std::string unless you have a real reason not to.

 
ya I do, like I said above I'm working with some really old code and it'll take too long to convert it all...

 

It'll take too long on the front end, but over the lifetime of the project, you'll probably waste more time fighting the chars.
If you have deadlines though, then there may not be enough time to meet the deadlines and refactor the project. Still, if you could schedule a time (three days or whatever you estimate it'll take) in the near future to refactor that aspect of the project, I think you'll feel alot better about it - and the code will certainly benefit from it.

But that's just my opinion!

Even if you can't use std::strings everywhere, you could still use them as a container-type for char arrays.

std::string cApp::ReturnString(char[30] &Temp)
{
	std::string copy(temp, 30);
	//...
	return copy;
}
 
... later code...
std::string B;
std::string A = DoSomething(B[0], B.size());

(Assuming DoSomething() already exists as part of the old code-base and can't be changed. Otherwise, it'd be much better off just taking a std::string)
 
But everything new you write would be much better off as std::string.
If you absolutely have-to-have-to-have-to, you could do something like this:

struct CharArrayStruct30
{
    char data[30]; //Horrible. *shudders*
};

 
But even this would be a step up:

struct RawStringStruct
{
    char *data;
    size_t size;
};

 
But std::strings constructors and functions are compatible with C-style raw strings, so you can migrate your codebase away slowly if you like.


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.

[Fly with me on Twitter] [Google+] [My broken website]

All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.                                                                                                                                                       [Need free cloud storage? I personally like DropBox]

Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal


#8 Vanz   Members   -  Reputation: 204

Like
0Likes
Like

Posted 01 February 2013 - 03:05 PM

cool... thanks....



#9 Serapth   Crossbones+   -  Reputation: 5005

Like
1Likes
Like

Posted 01 February 2013 - 05:04 PM

I mentioned this in another thread, and this is a common tripping point, but an array isn't really a variable, its just a trick to look like one.  At the end of the day, an array is just syntactic sugar over a continuous block of memory.  



#10 Waterlimon   Crossbones+   -  Reputation: 2102

Like
0Likes
Like

Posted 01 February 2013 - 05:21 PM

You could make a template class to do something like

Array<char,30> chars;
chars.array[3]='a';

Which should work as a return value/patameter, and you dont need a new struct for different array sizes.

Unless you can just use string of course.
The lack of awesome free resource gathering building sandbox games capable of running an user made 8 bit computer in the world disturbs me.

#11 SiCrane   Moderators   -  Reputation: 9125

Like
1Likes
Like

Posted 01 February 2013 - 05:33 PM

If you have a C++11 compiler, there's already a class that does that: std::array. If not, you can also use boost::array, which it is based on.

#12 King Mir   Members   -  Reputation: 1782

Like
0Likes
Like

Posted 02 February 2013 - 06:26 PM

I mentioned this in another thread, and this is a common tripping point, but an array isn't really a variable, its just a trick to look like one.  At the end of the day, an array is just syntactic sugar over a continuous block of memory.  

That's incorrect. An array is a type that's distinct from the concept of a continuous block of memory. In particular, dynamic arrays returned by new or malloc (and other functions) represent continuous blocks of memory, but are not of array type. Arrays are just a somewhat inconsistant feature of C/C++. It's not sugar.

 

But it's true that arrays behave differently from other variable types.



#13 ultramailman   Prime Members   -  Reputation: 1436

Like
0Likes
Like

Posted 02 February 2013 - 07:24 PM


I mentioned this in another thread, and this is a common tripping point, but an array isn't really a variable, its just a trick to look like one.  At the end of the day, an array is just syntactic sugar over a continuous block of memory.

That's incorrect. An array is a type that's distinct from the concept of a continuous block of memory. In particular, dynamic arrays returned by new or malloc (and other functions) represent continuous blocks of memory, but are not of array type. Arrays are just a somewhat inconsistant feature of C/C++. It's not sugar.
 
But it's true that arrays behave differently from other variable types.


What do you suppose an array is then, if not a continuous block of memory?

#14 King Mir   Members   -  Reputation: 1782

Like
1Likes
Like

Posted 02 February 2013 - 09:53 PM

 

I mentioned this in another thread, and this is a common tripping point, but an array isn't really a variable, its just a trick to look like one.  At the end of the day, an array is just syntactic sugar over a continuous block of memory.

That's incorrect. An array is a type that's distinct from the concept of a continuous block of memory. In particular, dynamic arrays returned by new or malloc (and other functions) represent continuous blocks of memory, but are not of array type. Arrays are just a somewhat inconsistant feature of C/C++. It's not sugar.
 
But it's true that arrays behave differently from other variable types.

 

What do you suppose an array is then, if not a continuous block of memory?

It's a type.

 

An array represents a monotonous aggregate of types in continious memory, but it is a type in its own right, and destinct from several other ways the same concept could be expressed.



#15 ultramailman   Prime Members   -  Reputation: 1436

Like
1Likes
Like

Posted 02 February 2013 - 10:30 PM




I mentioned this in another thread, and this is a common tripping point, but an array isn't really a variable, its just a trick to look like one.  At the end of the day, an array is just syntactic sugar over a continuous block of memory.

That's incorrect. An array is a type that's distinct from the concept of a continuous block of memory. In particular, dynamic arrays returned by new or malloc (and other functions) represent continuous blocks of memory, but are not of array type. Arrays are just a somewhat inconsistant feature of C/C++. It's not sugar.
 
But it's true that arrays behave differently from other variable types.


What do you suppose an array is then, if not a continuous block of memory?


It's a type.
 
An array represents a monotonous aggregate of types in continious memory, but it is a type in its own right, and destinct from several other ways the same concept could be expressed.


Oh thanks. Upon closer inspection, I realized your first post already said an array is a type. I guess I was paying more attention to the "...distinct from the concept of..." part.

I would say an array is a type, an array variable is a variable, and is also a contiguous block of memory.

#16 Trienco   Crossbones+   -  Reputation: 1945

Like
0Likes
Like

Posted 03 February 2013 - 01:57 AM

One of the few situations where a programmer will see an actual difference is references.

 

void func( int(&a)[10] ) { ... }

 

This will take an actual array, it must contain ints and it must be size 10. The last part is what often makes it useless in practice compared to "(int* a, size_t num)".


f@dzhttp://festini.device-zero.de

#17 SiCrane   Moderators   -  Reputation: 9125

Like
0Likes
Like

Posted 03 February 2013 - 08:01 AM

In technical jargon C++ arrays are not first class types. In other words there are many instances where arrays are treated differently than other types. One of the differences is that while you can declare a function to take an array as a function parameter, the compiler will automatically transform all array function parameters to pointers. This means it's impossible to pass a regular array by value. It's also illegal to return an array from a function. Unlike most other types, a variable with array type is not a legal lvalue. Pre-C++11 there was no way to initialize an array in a member initialization list. cv-qualifiers in an array declaration can't be applied to the array type, only the members of the array and so on. Arrays are types, but special cases.

#18 jHaskell   Members   -  Reputation: 817

Like
1Likes
Like

Posted 04 February 2013 - 05:30 PM

I mentioned this in another thread, and this is a common tripping point, but an array isn't really a variable, its just a trick to look like one.  At the end of the day, an array is just syntactic sugar over a continuous block of memory.  

That's incorrect. An array is a type that's distinct from the concept of a continuous block of memory. In particular, dynamic arrays returned by new or malloc (and other functions) represent continuous blocks of memory, but are not of array type. Arrays are just a somewhat inconsistant feature of C/C++. It's not sugar.

 

But it's true that arrays behave differently from other variable types.

 

Exactly what distinction exists about arrays that does not amount to syntactic sugar?  I can use array subscript notation to navigate through newed/malloced memory, and I can use pointer arith to navigate static/stack based arrays.  As far as I'm aware, all of the inconsistencies of array notation in C\C++ are a result of the fact that, under the covers, arrays are just pointers to a block of data, however that data is allocated, and array subscript notation is just another form of dereferencing that pointer.



#19 SiCrane   Moderators   -  Reputation: 9125

Like
0Likes
Like

Posted 04 February 2013 - 07:15 PM

under the covers, arrays are just pointers to a block of data

There's a subtle difference between a variable being a block of memory and a variable being a pointer to a block of memory, which is best illustrated by looking at the assembly generated when you access the two. Consider this code:
void foo(int);
int main(int, char **) {
  int a[5];
  foo(a[1]); 
}
The relevant bits of the assembly of the function call look like this under MSVC x64:
	mov	ecx, DWORD PTR a$[rsp+4]
	call	?foo@@YAXH@Z				; foo
Change the array to a pointer and the generated assembly changes:
	mov	rax, QWORD PTR a$[rsp]
	mov	ecx, DWORD PTR [rax+4]
	call	?foo@@YAXH@Z				; foo
With the variable declared as an array, you can get the address of the array member by adding to the stack pointer. With the variable declared as a pointer, you need to load the value of the pointer and then get the address of the member. Under the hood, arrays and pointers behave somewhat differently. Of course C does your best to confuse you about the difference between pointers and arrays by doing things like implicit decay and argument type transformation, which C++ unfortunately inherits.

#20 jHaskell   Members   -  Reputation: 817

Like
0Likes
Like

Posted 05 February 2013 - 02:05 PM

Thanks for the example SiCrane.  That's definitely more than syntactic sugar.  I'm curious to know though if that is per the C spec, or a compiler optimization.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS