allocation

I am looking for a good memory pool implementation in C. it should include the following: Anti fragmentation. Be super fast :) Ability to "bundle" several allocations from different sizes under some identifier and delete all the allocations with the given identifier. Thread safe I think the excellent talloc , developed as part of samba might be what you're looking for. The part I find most interesting is that any pointer returned from talloc is a valid memory context. Their example is: struct foo *X = talloc(mem_ctx, struct foo); X->name = talloc_strdup(X, "foo"); // ... talloc_free(X); //

For a project of mine, I am writing some STL containers from scratch (I have my reasons). Since I am mimicking the functionality and interfaces of the STL so closely I am doing my best to keep with the policy "if it has the same name as a standard construct, it will conform to the standard as much as possible." So, of course my containers take allocators as a template parameter, which is very nice as it allows for some custom allocation schemes. On to my question. The std::allocator interface separates memory allocation from object construction. Likewise it separates deallocation from

I need in a program to pass some allocatable arrays to subroutines, and i need to know if the way I do it are in the standard or not. If you know where I can search for the standard of fortran, Tell me please. Here is a little code that will better explain than words program test use modt99 implicit none real(pr), dimension(:), allocatable :: vx allocate(vx(-1:6)) vx=(/666,214,558,332,-521,-999,120,55/) call test3(vx,vx,vx) deallocate(vx) end program test with the module modt99 module modt99 contains subroutine test3(v1,v2,v3) real(pr), dimension(:), intent(in) :: v1 real(pr), dimension(0:),

Why do assembly languages use both a stack and a heap? They seem redundant. They're not redundant. Each of them has strengths and weaknesses: A stack is faster if used right, because memory allocation is trivial (push / pop). The downside is that you can only add and remove items at the top (hence the name, stack). Also, total stack space is limited, and when you run out, you have a... well, stack overflow. The heap, by contrast, allows random allocation and deallocation, and you can store large amounts of data there, but the downside is that allocation carries more overhead - for each

Wasn't exactly sure how to phrase the title, but the question is: I've heard of programmers allocating a large section of contiguous memory at the start of a program and then dealing it out as necessary. This is in contrast to simply going to the OS every time memory is needed. I've heard that this would be faster because it would avoid the cost of asking the OS for contiguous blocks of memory constantly. I believe the JVM does just this, maintaining its own section of memory and then allocating objects from that. My question is, how would one actually implement this? Thanks, dragonwrenn Most

In Golang, what is the difference between var s []int and s := make([]int, 0) ? I find that both works, but which one is better? VonC In addition to fabriziom 's answer , you can see more examples at " Go Slices: usage and internals ", where a use for []int is mentioned: Since the zero value of a slice ( nil ) acts like a zero-length slice , you can declare a slice variable and then append to it in a loop: // Filter returns a new slice holding only // the elements of s that satisfy f() func Filter(s []int, fn func(int) bool) []int { var p []int // == nil for _, v := range s { if fn(v) { p =

This may look like premature optimization, but I want to understand what happens on the inside and how this is typically programmed using the Qt library. Imagine an application that constantly produces an image that fills the complete window, e.g. a 3D realtime renderer. (A photo editor doesn't seem to have this problem since it's meant to preserve the output image size, instead adding scrollbars when the image doesn't fit.) Obviously, the output (buffer) image should get resized when the window gets resized. Now, in Qt, there appears no way to resize a QImage , instead, one has to deallocate

I am still confused about the requirements for a type to be used with a std::vector in C++11, but this may be caused by a buggy compiler (gcc 4.7.0). This code: struct A { A() : X(0) { std::cerr<<" A::A(); this="<<this<<'\n'; } int X; }; int main() { std::vector<A> a; a.resize(4); } works fine and produces the expected output, indicating that the default ctor (explicitly given) is called (and not an implicit copy ctor). However, if I add a deleted copy ctor to the class, viz struct A { A() : X(0) { std::cerr<<" A::A(); this="<<this<<'\n'; } A(A const&) = delete; int X; }; gcc 4.7.0 does not