jeff8j

I wish you luck but sharing a bit of my experience its not pretty but I do hope it keeps getting better.

 

Pros

1. Ease of conversion only real issue was pthread_cancel in my case

2. Excellent performance must faster than java in some heavy cpu encryption cases

 

Cons

1. With much research I still cannot get a gl context without java

2. Targeting multiple devices is a pain I must be doing something wrong but that leads to 3. Out of the 4 devices in my home apparently there are 3 different types of arm cores which makes sense being some are old and 1 is a media player but I still havent been able to get all of them to work.

3. Horrible docs alot of things are not documented

4. pthread_cancel is non existent and probably more but thats just something my project was using that it cant anymore.

 

I hope this is just me and not the ndk itself this has just been my experience and I have never compiled for arm devices before maybe someone knowing more can put tell if the cons are just me or not I would be interested to know.

 

One note about my findings so far I have not done audio so thats a bit scary as the library we were using is not capable and were looking for low level audio im not sure how well it will come out.

@cornstalks Im not too concerned anymore knowing its not at least in my current system but I would almost rather it break than start swapping out and become horribly slow. Im just worried on cross compiling for arm devices since im sure they put far less time into the implementations than x86 but ill cross that path if it ever arises.

@yewbie lol pretty much I dont have to worry about null terminations and keeping the size for binary data, not that its difficult just why do it when strings are cleaner and easier well there is this scenario when I would have more control but I dont believe I need it now that we covered everything.

Thanks Cornstalks thats good news now I would assume its c++11 not sure about the cross compiler though but ill give it the benefit of the doubt for now.

@SiCrane Thats what I was thinking but I get the warning warning: cast to pointer from integer of different size and a seg fault when running

Thanks everyone its much clearer in my head now everything is working with the c_str()

Thanks yewbie
It was me that was doing the extra memory allocation I falsely blammed c_str() but that page brings up a question it says maybe it allocates memory maybe not. Im handling big data on little resources so maybe makes a copy is a bit of an alarm is there a way to do my original idea of &data[0] but for strings that way I can make sure it gets a direct pointer?

Im not worried about writing back to it it will remain a const so no worry there. Im just trying to guarantee 2 100MB strings and program and os overhead can run safely on a 512MB device.

@yewbie Im not quite sure what your doing there and it seems like your still make duplicates of the string

@hodgman It works width the ->c_str() but im trying to avoid making an extra copy of the data thats why I was trying to point directly to the data

Now that im looking at everything im not sure c_str() is causing the extra data I think it might of been me so I guess going up a step does c_str() allocate any memory or is it a pointer to the data?

I am trying to avoid making an unnecessary copy of my data as I believe string->c_str() would do
so im trying to point directly to the string data like &string[0]
but my problem is I have a string pointer like this

void somefunction( std::string* data ){
     someotherfunction( data->c_str() ); //needs char*
}

how can I do the equivalent of &data[0] with the pointer?

Post the code the wild guesses are not helping but ill try some anyways
1. Are you using the old fixed pipeline approach (it could be phasing out driver wise because opengl is/did drop it)
2. VC6? common with all the hotpatches and crap over the years I wouldnt be surprised if just mentioning it leaked some memory
3. What kind of machine are you on? vc6, noticeable 6mb difference in memory, cant use the gdebugger?
4. How are you timing the frames in code and screen
5. Could just be your drawing code is off causing it to look slower and slower (get the fps)

How is that a stupid question more like that was a stupid answer. I have content already in bsp format I also dont know of an editor for octrees so thats what I am trying to figure out. I know that octrees and bsps are very different in the way data is stored and theres probably not a easy way to convert between them but there has to be something that can do it I dont care if it has to process for a week.