- Announce: Expressive C++, a readability/safety/convenience dialect of C++. - 1 Update
- boost::flyweight and smart pointers - 1 Update
- copy-on-write - 1 Update
- Lapacke inputs - 4 Updates
| "Öö Tiib" <ootiib@hot.ee>: Feb 26 02:07PM -0800 On Sunday, 26 February 2017 02:09:03 UTC+2, Alf P. Steinbach wrote: > void cpp_main( ref_<const vector<string>> args ) I see '$proc cpp_main' here in your online tutorial. I did like your threaded tree tutorial bit better. Will there be more chapters of it? ;) |
| "Öö Tiib" <ootiib@hot.ee>: Feb 26 01:45PM -0800 On Sunday, 26 February 2017 02:36:35 UTC+2, bitrex wrote: > new class is created with a key that hashes to the same value type it > makes a new wrapper and clones the reference, rather than call the > copy/move constructor on my own. You got false dichotomy: "look into code" (what a silly idea) versus "randomly speculate" (what a silly idea). Other usual choices are "try it out" (can't hurt), ask around (should raise RTFM answers) and "look into documentation" (good idea but lot of people leave it as last). By documentation it seems that how the boost flyweight is behaving internally can be configured. http://www.boost.org/doc/libs/1_63_0/libs/flyweight/doc/tutorial/configuration.html That is quite usual with boost so I already suspected that. > instance of it are finally all referring to the same resource. When all > the flyweights are gone the pointer to my wrapper is released, and along > with it goes the unique_ptr contained within. Stuff that is contained in that flyweight seems that needs to be copy assignable and hashable with Boost.Hash by the very same documentation. Have you tried the thing at all? |
| Vir Campestris <vir.campestris@invalid.invalid>: Feb 26 09:04PM On 24/02/2017 22:59, Öö Tiib wrote: > good in multi-threaded program and can cause major hidden performance > hit there. Most programs written nowadays are multi-threaded and so CoW > is not too good idea most of the time. Isn't CoW the standard method Linux uses when implementing fork()? Give the forked process a page table pointing at all the same pages as the parent, but read only? and only copy them when they are written? That seems reasonably efficient. Although the idea that any page fault could result in an out of memory error does bother me! Andy |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 26 09:51PM +0200 > #include "lapacke.h" > using namespace std; > // allocate space for function LAPACKE_ssyev This comment is wrong, there is no space allocation going on, it's just a declaration of a function. > extern lapack_int LAPACKE_ssyev(int* matrix_layout, char* jobz, char* uplo, const lapack_int* n, > float* a, const lapack_int* lda, float* w); There is no need to declare lapack library functions like that, such declarations should come from the included header file (lapacke.h). Besides, this declaration seems to be all wrong, the correct signature according to "http://www.netlib.org/lapack/explore-html/de/dfb/lapacke__ssyev_8c.html" is: lapack_int LAPACKE_ssyev( int matrix_layout, char jobz, char uplo, lapack_int n, float* a, lapack_int lda, float* w ); I wonder how you were able to compile your code at all, but in any case you should remove this invalid declaration. |
| thebtc@hotmail.com: Feb 26 12:06PM -0800 Thanks for the tip Paavo, I got rid of that line. Somehow it had been compiling no problem which is why I hadn't suspected that there was an issue with that line. I also figured out why my results weren't being printed to the textfile- I added an extra ";" after my for loop and so basically the for loop was useless and wasn't doing anything. So now I'm getting my eigenvalues printed to the textfile as expected. Thanks to all the posters in this thread for your help! I really appreciate it. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 26 10:31PM +0200 > Thanks for the tip Paavo, I got rid of that line. Somehow it had been compiling no problem which is why I hadn't suspected that there was an issue with that line. I also figured out why my results weren't being printed to the textfile- I added an extra ";" after my for loop and so basically the for loop was useless and wasn't doing anything. So now I'm getting my eigenvalues printed to the textfile as expected. Good to hear! In some other languages like Perl the for loop content must be always placed inside braces, I always follow this style and wish it would be mandatory in C++ as well! With mandated braces this kind of error would be much easier to spot, and much harder to make in the first place. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 26 10:45PM +0200 > Thanks for the tip Paavo, I got rid of that line. Somehow it had been compiling no problem which is why I hadn't suspected that there was an issue with that line. Now I understood why your code was compiling with the invalid declaration. I was expecting errors because the lapack library is a C library, and in C one cannot overload the same function with different argument types. Alas, in your declaration there was no 'extern "C"' specifier which would be actually needed in a C function declaration. So for the compiler is was just another C++ overload of some function which you declared but never called, so it was just ignored. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment