Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-8081-

Returning an array in C++

Name: Anonymous 2009-10-26 20:39

PLEASE /prog/ help me out here. I've read and tested at least 5 "answers" to my question that I've found on google, but I can't get any of them to work. You guys are better than them though, right?

I wanted to call an array by reference in a function. Then, I learned that that was impossible. I tried returning the array, but you can't do that either.

Apparently, I need to do some shit with pointers to return the array. How the fuck do I do this?

Name: Anonymous 2009-10-26 20:41

read sicp

Name: Anonymous 2009-10-26 20:48

malloc()

Name: Anonymous 2009-10-26 20:51

>>2-3

hilariousreactionimage.cpp

Name: Anonymous 2009-10-26 21:03

>>4
get back to /g/.
malloc() is what you want if you need to return an array from a function.
goddamn sepplers

Name: Anonymous 2009-10-26 21:12

Apparently, I need to do some shit with pointers to return the array. How the fuck do I do this?

First you must ask and answer yourself, "what is an array?"

Then, and only then, will all be revealed.

Name: Anonymous 2009-10-26 21:12

>>5

My bad, I thought it was some LISP thing.
Can you explain how I would use it to return my array? Sorry, I'm not an EXPERT PROGRAMMER, just a newbie who's trying to get ahead of the rest of his class.

Name: Anonymous 2009-10-26 21:16

>>5
they could just use new, but of course that doesn't spare them from learning some minimal pointer arithmetic

Name: Anonymous 2009-10-26 21:17

>>7
imagine you want an array of 20 integers. you would do this:
int *int_ptr = malloc(20 * sizeof(int));
malloc allocates memory and returns a pointer to it. so the above would allocate 20 ints worth of memory.
you then treat the memory as if it was a normal array or pointer, except that it is not bound by scope.
free(int_ptr); when you're finished with it.

Name: Anonymous 2009-10-26 21:34

Hey, morons, this is C++. Use new, not malloc.

>>1
In general, you want to let the caller allocate it and pass it in to the function, unless the function's sole purpose is to allocate an array and return it. This is because C++ memory management is from retardo-land. Same for C.

Name: Anonymous 2009-10-26 22:00

>>10
Boost's shared pointer classes make memory management more manageable.

Name: Anonymous 2009-10-26 22:26

>>11
This is what C++ programmers actually believe.

Name: Anonymous 2009-10-26 22:53

Boost's innovations make programming more enjoyable.

Name: Anonymous 2009-10-26 23:54

>>1

char** array(){
    char* array = new char[8];
    for(int c = 0;c < 8;++c){
        (array)[c] = '\\';
    }
    return &array;
}

int main(int argc, char*argv[]){
    char*strnig = *array();

    return 0;
}

This is a little wrong, but it's right enough. Think of an array as a pointer(if you don't know what a pointer is, think of it as a variable which points to a specific memory location), to change the value of a regular variable in a function in c you'd pass it's memory location to the function like so,


void edit_value(int *point){ //'declaring that point is pointing to an integer
    *point = 3; //'here the '*' value changes a little, to refer to the value which point is pointing to.
}

For an array, which is already a pointer, we need to pass a pointer of a pointer, **. And the rest is just the same as editing point's value.

Name: Anonymous 2009-10-27 0:28

>>10
C > sepples.
malloc() > new.

Name: Anonymous 2009-10-27 0:58


if(malloc == new){
    return ``>>15 == FAGGOT'';
}

Name: Anonymous 2009-10-27 1:20

████████████████████████████████████████████████████████
██▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓██
██▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓██
██▓▓▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒▓▓██
██▓▓▒▒░░      >>15: malloc my anus              ░░▒▒▓▓██
██▓▓▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒▓▓██
██▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓██
██▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓██
████████████████████████████████████████████████████████

Name: Anonymous 2009-10-27 2:15

>>14
For an array, which is already a pointer, we need to pass a pointer of a pointer, **. And the rest is just the same as editing point's value.
Are you retarded? If it's a pointer, why don't you pass the pointer?

Returning the address of a local variable.
Yup, you're retarded.

char* array() {
    char* array = new char[8];
    for(int c = 0;c < 8;++c){
        array[c] = '\\';
    }
    return array;
}

int main(int argc, char* argv[]) {
    char* strnig = array();
    return 0;
}

Name: Anonymous 2009-10-27 3:39

>>17 = (anus*)malloc(mysize * sizeof(anus));

Name: Anonymous 2009-10-27 3:40

>>18
This is /prog/ not /pr/.

Name: Anonymous 2009-10-27 3:41

namespace Anii {
    char * createArray(int arraySize = 8) {
        char *array = new char[arraySize];
        arrayFill(array, '\\', arraySize);
        return array;
    }

    void arrayFill(char *arr, char filler, int size) {
        for (int c = 0; c < size; ++c) {
            arr[c] = filler;
            }
    }
}

int main(int argc, char *argv[]) {
    char *strnig = Anii::createArray();

    return 0;
}

Name: Anonymous 2009-10-27 3:51

new(faggot) is what you do in java.
malloc()(manly) is what you do in C.

Name: Anonymous 2009-10-27 3:58

I would never suspect people from /prog/ to admit to know C++.

Name: Anonymous 2009-10-27 4:17

>>23
/prog/ is tsundere for C++

Name: Anonymous 2009-10-27 4:39

>>23
yeah yeah yeah.
that's what all the newfags who are here because they want to learn how to program games say.

Name: Anonymous 2009-10-27 5:44

>>22
C++:

faggot myFaggot = new faggotFactory.createFaggot();

C:

manly_t *Man = malloc(sizeof(manly_t));

Name: Anonymous 2009-10-27 6:40

DONT FORGET TO free() MY ANUS AFTERWARDS

Name: Anonymous 2009-10-27 6:43

>>27
NEVER!
ALL YOUR anus ARE BELONG TO ME.

Name: Anonymous 2009-10-27 6:52

>>23
We all know it, we all hate it, and some of us,me, even have ~4 books on the subject(none are specifically C++, but use it as the example language)
>>24
That would require us to secretly like it

Name: Anonymous 2009-10-27 7:16

>>24
Cprusprusmoe!

Name: Anonymous 2009-10-27 12:42

>>23
As >>14 shows, even people who don't know C++ pretend they know it.

Name: Anonymous 2009-10-27 13:29

Why does anyone bother to learn sepples? I remember when I tried. I thought I was really learning something, it felt difficult and strangely rewarding. Then I learned a decent language and I realize I had been trolled hard.

Name: Anonymous 2009-10-27 14:18

>>32
Wow, that is the same experience I had. But what I find really fascinating is that a lot of people can't accept that they have wasted years trolling themselves, so they cling to Sepples like their lives depend on it.

Name: Anonymous 2009-10-27 14:58

YOU RETURN A POINTER POINTING TO THE ARRAY YOU MADE IN THE FUNCTION.  GOD DAMN EVEN I KNOW THAT AND IM A PYTHON FAGGOT.

Name: Anonymous 2009-10-27 15:12

>>34
As a Python faggot, you forgot that the locally created array will be destroyed on function return, thus your pointer will point to nothing (of value) (was lost). malloc/new is necessary

Name: Anonymous 2009-10-27 15:17

>>35
Don't help him!

Name: Anonymous 2009-10-27 15:18


void *getArray(int length, int bytes)
{
   return new char[length * bytes];
}

NO EXCEPTIONS

Name: Anonymous 2009-10-27 15:20

>>37
you've essentially used new to remake malloc(). what is wrong with you

Name: Anonymous 2009-10-27 15:21

>>38
well, calloc, more accurately

Name: Anonymous 2009-10-27 15:22

>>38
I answered his question on how to return an array so redditers like you would stop bumping this shitty thread.  Now please use sage in the future!

Name: Anonymous 2009-10-27 16:11

>>39
calloc zeroes memory iirc

Name: Anonymous 2009-10-27 16:43

looks like you're right. w.e, I don't care, I'm a faggot and use new/delete anyway, I don't care about malloc/calloc/fuckloc

Name: Anonymous 2009-10-27 17:18

>>38
Superior implementation. If you're programming Sepples, you'd better use templates wherever possible.
template<class T>
T* getArray(int length) {
    return new T[length];
}

Name: Anonymous 2009-10-27 17:19

>>43
Templates make me RAGE

Name: Anonymous 2009-10-27 17:38

>>44
template<unsigned int n> struct fib
{
    static const unsigned int result=fib<n-1>::result+fib<n-2>::result;
};

template<> struct fib<1>
{
    static const unsigned int result=1;
};

template<> struct fib<0>
{
    static const unsigned int result=0;
};

int main()
{
    std::cout<<"fib<1>="<<fib<1>::result<<'\n';
    std::cout<<"fib<2>="<<fib<2>::result<<'\n';
    std::cout<<"fib<3>="<<fib<3>::result<<'\n';
    std::cout<<"fib<4>="<<fib<4>::result<<'\n';
    std::cout<<"fib<5>="<<fib<5>::result<<'\n';
    return 0;
}

Name: Anonymous 2009-10-27 17:45

>>44
How come? They're C++'s best (only good) feature. Are you just mad that C++ has a good feature?

Name: Anonymous 2009-10-27 18:10

>>46
No because a giant hack for a giant hack of a language

Name: Anonymous 2009-10-27 21:07

>>1
Simple:

return new int[5];

Of course you want that memory to be checked, transferable and exception safe, so you do this:

return std::auto_ptr<int>(new int[5]);

But that's not right, wrong delete. Boost to the rescue:

return std::tr1::shared_array<int>(new int[5]);

You should be using a vector anyway, but you don't want to be copying the vector, so you need a vector pointer:

return std::auto_ptr<std::vector<int>>(new std::vector<int>(5, 0));

Now you want the smart pointer to be thread safe and container safe of course, so you do this:

return std::tr1::shared_ptr<std::vector<int>>(new std::vector<int>(5, 0));

But you should of course allow configuring the allocation strategy, and it also needs to be exception safe, so you do something like this:

template <class Alloc>
std::tr1::shared_ptr<std::vector<int>> makeArray() {
  Alloc::rebind<std::vector<int>>::other alloc;
  std::tr1::shared_array<std::vector<int>> ret(alloc.allocate(1));
  alloc.construct(ret.get(), std::vector<int>(5, 0));
  return ret;
}



...In C, you take an pointer parameter, and modify the array in place. Crazy C programmers, always doing things the hard way...

Name: Anonymous 2009-10-27 22:14

I'm actually planning to write a program to combine the best features of Lisp and C++ by allowing you to define and use Lisp macros in C++ code. Instead of writing pair<int> x;, you'd just write (pair int) x;, and pair would be a Lisp macro that expanded it as appropriate. It'll be awesome!

Name: Anonymous 2009-10-27 22:20

...In C, you take an pointer parameter, and modify the array in place.
...and don't get any of the features you spent your whole post including. Write an equivalent C program, why don't you?

Name: Anonymous 2009-10-27 22:38

int *f(){
    int i = 6;
    return &i;
}

This probably isn't technically correct, but I only compile with gcc so it doesn't matter.

Name: Anonymous 2009-10-27 22:51

>>51
That's extremely bad and also wrong. Why do you idiots keep trying to return the addresses of local variables? Even gcc, which you claim to use, will warn you about this by default.

t.c:4: warning: function returns address of local variable

Name: Anonymous 2009-10-27 22:59

>>51
int* f()
{
    int i = 6;
    return &i;
}
void g()
{
     int destroy_the_stack[1000];
}
int main()
{
    int* a = f();
    g();
    cout << *a << endl; //uh-oh spagetti-o's
    return 0;
}

Name: Anonymous 2009-10-27 23:23

>>53
No one does this anyways. >>51-sensei's way is good enough, and is actually the fastest come run-time.  I would prefer speed over taking care of some random boundary case like >>53-chan's anyday.

Name: Anonymous 2009-10-27 23:29

>>54
0/10. I award you no points, and may God have mercy on your soul.

Name: Anonymous 2009-10-27 23:30

>>54
Setting yourself up for failure. I hope you don't program flight control computers

Name: Anonymous 2009-10-27 23:38

>>56
Haha, I am glad I don't.  I write games in C++.  I am currently writing 3 games, and I am hoping to release them in 2010 (probably for Christmas.  One my have to wait until 2011) Unlike you, I can actually program, make money, and have fun at the same time, and in games every bit of optimization is important.

Name: Anonymous 2009-10-27 23:41

>>57
HOLY SHIT IT'S MAT DICKIE

Name: Anonymous 2009-10-27 23:43

>>58
Don't be silly, Mat Dickie isn't real

Name: Anonymous 2009-10-27 23:47

>>59
o ok

Name: Anonymous 2009-10-28 0:29

>>57
Wow, you're pretty awesome Anonymous.

>>53
Interestingly your destroy_the_stack array doesn't actually destroy the stack. You just declared some stack space which is never actually used. Try destroy_the_stack[0]=0;.

>>50
Way to not get the point. These are not features, they are anti-features. They are a massive overcomplication of something that should be extremely simple.

This thread is like the twilight zone. Since when does /prog/ like sepples?

Name: Anonymous 2009-10-28 0:33

>>61
you're right, however on my gcc it was sufficient to corrupt the 6 located at a, so I went with it. your mileage may vary based on your compiler

Name: Anonymous 2009-10-28 0:36

Here's a more to-the-point demo prog based on >>61's suggestion (and one which is definitely *not* a boundary case)
int* f()
{
    int i = 6;
    return &i;
}
void g()
{
     int destroy_the_stack = 9;
}
int main()
{
    int* a = f();
    g();
    cout << *a << endl; //uh-oh spaghetti-o's -- displays 9
    return 0;
}

Name: Anonymous 2009-10-28 0:40

>>61
Trolled by an incompetent troll

Name: Anonymous 2009-10-28 0:41

>>54
Oh holy fuck, I didn't actually fully interpret the depth of this post the first time around. You think that having a pointer to a stack variable and then calling a function that overwrites it is a 'random boundary case'?

Honestly. You are seriously fucking retarded. You know when you build -Wall -pedantic and the compiler gives you hundreds of warnings? Those aren't a joke. You are seriously fucking up. In my last two jobs, I introduced the policy of building everything -Wall, and it all has to come out no warnings to ship.

Also what the fuck makes you think >>51 is fastest at run-time? It doesn't fucking do anything except give you a pointer to a literal, applied dangerously somewhere on the stack. None of these examples even make any sense. It certainly hasn't allocated an array; it has fuck all even to do with arrays.

And 'allocating an array' is an extremely generic concept; you can't just point at some code and say which is fastest. How big does the array need to be? Is it thread-local? Small? Function scoped? Then you can probably alloca() it. Is it small but shared? Consistent size? You can maybe pool it. Threaded? Add locks to the pool. Is it fairly large? malloc(). Quite large? mmap().

Honestly though all of this is superfluous. malloc() is going to be your best bet in almost all situations, since a good malloc() does all the above for you except stack allocations (which often cause more problems than they solve). You can never figure out the best way to do these things besides profiling, and honestly you always have bigger bottlenecks (like the fact that you have allocations outside of loading in the first place). The allocator is all powerful; trust the allocator.

Please tell me what your games are so I can avoid their bugs and security vulnerabilities.

Name: Anonymous 2009-10-28 0:44

>>65
A new is fine too

Name: Anonymous 2009-10-28 0:48

>>66
Not for arrays.

Name: Anonymous 2009-10-28 0:50

>>67
Do go on

Name: Anonymous 2009-10-28 1:03

>>68
Well, it's garbage for anything other than pointers or primitive types simply because of constructors. If you're trying to set up some kind of pool (say a pool of particle objects), to use new[] you have to subvert the usual constructor/destructor scheme and provide your own init/destroy functions. This is dumb. You're much better off malloc()'ing the memory, and using in-place construction/destruction, so you can have proper constructors and destructors for your objects without the associated allocation costs.

As far as primitive types go, there are safer ways. These sorts of arrays are usually either fixed compile-time sizes, so you're better off having them as a field of a struct/class, or for growable arrays, so you're better off using some sort of vector class (or std::vector if you're lazy). And no, there is no overhead to an std::vector of primitives aside from the size of the array (which, if you're sizing dynamically, you generally need to have stored anyway).

Name: Anonymous 2009-10-28 1:21

>>69
To add to this, boost has a memory pool built in that does exactly this, because getting this all correct and exception-safe in sepples can actually get quite complicated (easy to fuck up). As usual, something that should be simple is instead excruciating, but because it has a shitty prefab template for you to use people will cheer about how powerful their language and library is. Go sepples!

Name: Anonymous 2009-10-28 1:35

>>50
Love to!

int* make_array(void* (*alloc)(size_t)) {
  return (int*) (*alloc)(sizeof(int) * 5);
}

Check that shit out! Custom allocator and everything. Pretty bitching, right? It doesn't have the smart pointers, but guess what, you don't need them in C because there's no such thing as exceptions (nor threads. Remember kids, threads are evil. Isolate processes; avoid shared memory; communicate through pipes; the UNIX way). Memory management in C is pretty damn easy.

Name: Anonymous 2009-10-28 2:01

>>71
I think I had the UNIX equivalent of an orgasm

Name: Anonymous 2009-10-28 2:11

>>72

phiber@scout:~$ cum > filthy.sock

Name: Anonymous 2009-10-28 2:12

>>72
[Anonymous@/prog/ ~]$ yes oh yes

Name: Anonymous 2009-10-28 2:15

>>61
Since when does /prog/ like sepples?
Much as I hate Sepples, I hate people who Sepple wrong even more.

Name: Anonymous 2009-10-28 5:43

>>73
Lol I do that sometimes if I can't find a tissue. Else underwear

Name: Anonymous 2009-10-28 6:07

>>73
Why is sock an attribute of filthy, instead of the other way around
Sock.filthy = True

Name: Anonymous 2009-10-28 6:13

>>77
no no no your doing it wrong. The Sock object should implement the Filthy interface if it's filthy

Name: Anonymous 2009-10-28 6:24

>>78
Enjoy your Robust Scalable Turnkey Solutions

Name: Anonymous 2009-10-28 6:58

>>78
You can't dynamically implement an interface depending on whether the sock is filthy or not though. Your move.

Name: Anonymous 2009-10-28 7:57

>>80
Yes you can. NOW YOUR'E THINKING WITH RUBY

Name: Anonymous 2009-10-28 8:07

>>71
but guess what, you don't need them in C because there's no such thing as exceptions

Right. You have returns instead. I mean, goto cleanup;.

You never programmed anything remotely complex in C, I guarantee that.

Name: Anonymous 2009-10-28 8:13

>>82
what was your point?

Name: Anonymous 2009-10-28 9:15

>>82

in C there's no way to protect against unwinding the stack, moron

Name: Anonymous 2009-10-28 9:19

>>82
nope. the closest thing to exception handling C has is signals.
it's the manly way of doing things.

Name: Anonymous 2009-10-28 9:28

>>85
setjmp & longjmp

Name: Anonymous 2009-10-28 10:39

>>86
TEN POINTS FOR GRYFFFFIINNNNDORRRRRRRR

Name: Anonymous 2009-10-28 10:53

You can implement exception handling unportably in C, as long as you can write some assembly code for your platform.

Name: Anonymous 2009-10-28 10:59

>>83-85 I feel I'm being [spoiled]trolled[/spoiled].

>>71 said that I, personally, don't need smart pointers in C because "there's no such thing as exceptions". Being a professional C programmer, I was deeply offended by such a moronic statement.

Exception mechanism is merely a tool that provides one particular way for solving a certain class of problems. Not having this exact tool only means that I have to implement the solution in a slightly different way. I open a file, try to read something from it unsuccessfully and then need to close it before reporting error myself, with exceptions I put close in the finally block, without exceptions I make a "finally" label near the end of the function, close the file there, and set up return value and goto there whenever something fails.

The problem I'm solving is the same, the structure of the solution is roughly the same, and only the thin layer of syntax and semantics of an actual language produces somewhat different implementation.

I'm greatly saddened by the stupidity and arrogance of >>71,83-85, who not only can't see beneath that superficial layer, but are entirely convinced that there is nothing at all beyond that.

Of course I'd need more than one logical exit point in a function if it can fail somewhere. Of course I'd have to map these onto the real exit point(s) somehow and clean up all resources, and why the fuck anyone would think that 'throw' is somehow different from 'return' in this respect? Of course I would appreciate RAII greatly while I'm at it.

Name: Anonymous 2009-10-28 11:39

>>89
Stopped reading at you claiming to be offended by a moronic statement. You should by now know (if you lurked long enough, that is) that every post here contains at least 75% moronic content.

Name: Anonymous 2009-10-28 13:00

>>90
(if you lurked long enough, that is)
Non-moronic content.

Name: Anonymous 2009-10-28 13:03

>>89
RAII
Stopped reading there.  Did you mean RAF?

Name: Anonymous 2009-10-28 13:06

>>90
Of course I was not deeply or at all offended, you moron. It's a polite figure of speech that substitutes for "I'd rip your filthy tongue out and made you swallow it if I were unfortunate to listen to your bullshit in person". The kind of thing you do to people who are trying to offend you (unsuccessfully, of course).

Name: Anonymous 2009-10-28 13:36

lol RAII hacks.

I'll take my WITH- macros and UNWIND-PROTECT instead.

Name: Anonymous 2009-10-28 18:07

>>82
>>89

Not having this exact tool only means that I have to implement the solution in a slightly different way. I open a file, try to read something from it unsuccessfully and then need to close it before reporting error myself, with exceptions I put close in the finally block, without exceptions I make a "finally" label near the end of the function, close the file there, and set up return value and goto there whenever something fails.
...So you're saying compiler exception support is superfluous and unnecessary? Are you trying to prove my point here? What was your point again?

Of course I'd need more than one logical exit point in a function if it can fail somewhere. Of course I'd have to map these onto the real exit point(s) somehow and clean up all resources, and why the fuck anyone would think that 'throw' is somehow different from 'return' in this respect?
Nice job shithead. You don't seem to understand that the point of exceptions is that they propagate through many functions on the stack. Smart pointers and RAII aren't syntactic sugar for goto cleanup; they are syntactic sugar for longjmp and a thread-local cleanup stack (and in many compilers that's exactly how they're implemented).

This is why smart pointers aren't needed in C. Unless you're using a library that actually longjmps (like libpng), there's no danger that some exception will propagate through your function; unless the thread aborts your 'goto cleanup' will always be called, so it's sufficient to cleanup resources.

(And this is entirely unrelated to the issue of reference counting, which is often conflated with smart pointers; lots of C libraries use reference counting).

You never programmed anything remotely complex in C, I guarantee that.

Hilarious, from one professional C programmer to another. Ask the Linux kernel devs what they think about exceptions and smart pointers.

Name: ​​​​​​​​​​ 2010-10-24 18:12

Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -