Marcus, Thank you for your detailed explanation.
Now, I can see that I can use an ordinary malloc if there is no specially aligned memory. Thanks. 2015-04-23 17:53 GMT+09:00 Marcus Müller <marcus.muel...@ettus.com>: > Hi Jeon, > > you just `malloc(...)` when you need to; why would you, in general, need > GNU Radio to wrap that simple libc call, especially since there's calloc? > > Or, is it not just a simple memory allocated array, > but a special array that something happens when items are put into the > array? > > It's special. > gr::fft needs these fftw_mallocs because FFTW (which is the FFT library > underneath) expects specially aligned memory, and therefore offers it's own > fftwf_malloc; thus, we need to wrap this up. It's an FFTW-speciality, and > shouldn't be used for different things than memory that FFTW works on. > When you work with fftw (which is a C library) in C++, you'll notice that > C++ is a bit more strict than C when it comes to pointer types, and you > have to cast around the pointer type just to get it working. Since that is > a bit ugly to do in-line, there's these malloc abstractions that you've > mentioned. > > Generally, as we try to write beautiful C++, we don't malloc much -- new[] > might be your friend if you actually want to work with arrays. > However, GNU Radio is a bit doomed when it comes to having beautiful, > type-safe code, because the core concept of gr_buffer basically is that > buffers between blocks are just memory regions, not data of a specific type > -- hence all the "ugly" pointer casting that happens in about every work(). > > There's a lot of places where `malloc` is really handy in our code, for > example in the DVB decoders, where structures for decoding need to > dynamically be allocated, or in the GUIs, where you often just want to have > a bit of memory representing your framebuffer. But as a rule of thumb, you > should try to avoid dynamically allocating memory manually (using malloc) > as much as possible -- it's just one of the most popular causes for > hard-to-debug bugs. > > It's often practical to use `std::vector<type> > myvector(number_of_elements)` instead -- it does the allocation for you, > allows for resizing, and you can, just like with malloc, get the address of > the first element ( `&(myvector[0])` ) . As a bonus, `myvector[x]` always > actually has the right type, and you don't need to first cast the return > value of malloc to a pointer of whatever you want to have. > If you don't need the resizing of `std::vector`, just the dynamic > allocation, `std::array` is also awesome; both being STL containers offer a > great deal of functionality that you'd have to implement yourself if you > just go a C-style array in some malloc'ed memory. > > Best regards, > Marcus > > > On 04/23/2015 10:18 AM, Jeon wrote: > > It's not a big deal, but I'm just curious. > > Why are malloc functions, malloc_complex, malloc_double, malloc_float in > gr::fft ? > I think memory allocating functions can be used in various purposes, not > only in FFT. > > Is it just a workaround that > there are no more proper places (gr::analog, gr::digital, gr::blocks...) > for malloc? > > Or, is it not just a simple memory allocated array, > but a special array that something happens when items are put into the > array? > > > Regards, > Jeon. > > > _______________________________________________ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
