| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13
Comments:
<0> I realy got the idea everybody already knew.
<1> pfft i'm not reading your gun forums
<2> exception you're likely worried about optimization before you've ever profiled the program
<3> I'm all for portability - but whenever possible, the system should be efficient. It's possible to write a generic wrapper that would use alloca if possible on the system
<4> why use alloca at all?
<2> HAVE you profiled the program??
<4> create a memory pool type thing
<5> if you're doing that much allocating and freeing
<5> you've likely ****ed up anyway
<3> vawjrwrk : we are considering architecture changes, and I'm considering ways to boost it
<3> I'm not going to put it in before profiling, of course
<6> alloca() memory also cannot be returnecd and in fact must be freed before the function that allocated it returns
<3> but it's important to know what are my options
<2> HAVE YOU PROFILED the program???
<3> vawjrwrk : there is no program that needs profiling yet
<3> don't give me this rant
<2> then why are you even considering optimizations already?
<7> when the program will be ready probably it will work faster
<3> it's important to know what are the options
<2> forget it
<6> it wouldn't be very useful for allocating space for a string because when the constructor returns the allocated memeory is gone
<3> cn28h : I worked it around - I'm allocating it outside and p***ing it to the ctor. Ugly - yes, but works way faster than dynamic allocation
<6> that is dynamic allocation, btw
<2> insanity
<3> cn28h : not on the heap - so it's way cheaper, no need to search on a tree, just modify the stack pointer
<6> you can do that with the heap too, you know
<2> "modify the stack pointer" ????
<6> using sbrk()
<3> vawjrwrk : alloca does it internally, obviously I'm not fiddling with it
<2> finding a C99 compiler and declaring local arrays might be safer
<3> maybe, but I want c++
<3> when there will be dynamic arrays in next c++ it would be way better
<3> basically - yes, alloca is a crude way to do dynamic arrays
<7> ok... what would be the difference between a dynamic array and std::vector?
<3> sk8ing : dynamic array is on the stack, and exists only in the skope
<3> std::vector is an object that exists on the stack, but the memory it allocated internally exists on the stack - you can safely return it or keep it in a variable after your function ended
<6> not if the object is on the stack you can't
<6> well
<6> you return a colpy of it
<6> not its address
<7> return &vec; will crash
<3> cn28h : you'll return a cheap copy of the object, but the heavy data itself will still be on the heap
<7> if vec is defined inside the function
<6> exception, nope if you return the object you will make a deep copy
<3> ok, I ***umed the implementation does copy on write
<3> for returning, local array - static or dynamic - is not an option, anyway
<5> http://www.nopers.com/video/476/college_girl_abused_by_police_for_loud_music
<5> hehe
<3> but for internal use of a function, dynamic array is much faster
<6> copy on write is an operating system level thing, I'm not sure how you would pull that off directly in a C++ implementation
<6> I guess if you used reference counting
<3> you can implement string to do copy on write
<3> take MS's CString for example
<3> exactly the same about vector
<3> operator [] is tricky - you can't know if a change was performed, so you must ***ume every [] is changing
<8> anyone know if visual studios hardcodes indentification information in the compiled binary?
<6> so you're telling me if you create a CString object, copy that object, their memory will be pointing to the same memory until you wrrite to one of them?
<3> cn28h : with recent implementations - yes
<3> CString X("hey"); CString Y(X); // same buffer
<5> it's nice to see them **** up and pick on the wrong person
<3> X.SetAt(1.'H'); // copy
<3> I don't remember the real syntax for changing a letter
<7> exception: I don't know if that would work for CString x; return x;
<7> the copy constructor is called, it may probably create an object that points to the same buffer but the function has to call the destructor
<3> sk8ing : why not ? a good optimizer might eliminate the whole copy ctor/dtor altogether, but ***uming they are called -
<3> a copy is created, increasing rc
<7> in fact I think the object itself could implement that...
<3> the original is destroyed, decreasing rc. voila.
<6> where is the reference count stored then? it would hjave to be shared among the objects
<3> in CString, they keep the reference counter at a negative index of the buffer
<6> ah
<3> nice hack, actually
<7> what happens if you derive it?
<3> dunno, but why would deriving break it ? the original ctor/dtor are still called...
<7> yeah, I guess you're right
<9> is there a problem if I load two modules with dlopen and I have two functions with the same name in each of them?
<10> I guess that's pretty much of a trouble
<3> catalinux_ : probably no problem - since the symbols aren't linked anywhere, and you p*** the handle to the library when you call dlsym
<1> catalinux_: i would hope not, as dlsym takes a handle
<3> unless the two libraries reference each other
<9> thanks
Return to
#c++
or
Go to some related
logs:
#linux
iduri fete
#skype
#AllNiteCafe
read() failed: Resource temporarily unavailable
#c++
melan12345
as_rights
HI 5
#php
|
|