Timeline for How to convert data types in a LibraryLink wrapper
Current License: CC BY-SA 3.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 5, 2013 at 18:14 | comment | added | Stefan | @JacobAkkerboom thank you for the upvote :) cheers | |
| Dec 5, 2013 at 18:03 | history | edited | Jacob Akkerboom | CC BY-SA 3.0 | Removed disputed statement as per comments |
| Dec 5, 2013 at 17:59 | comment | added | Jacob Akkerboom | Stefan I see I also wrote a bit of nonsense in: "the file WolframLibrary.h varies across platforms." I mean that the resulting size of a mint varies across platforms, sorry for being unclear, I guess it happens :). Thanks for allowing me to edit, I will just remove the sentence and then upvote :) | |
| Dec 5, 2013 at 17:45 | comment | added | Stefan | to conclude this. I thought it was appropriate for the question to make this distinction. If someone uses mint as a typedef for a LP64/LLP64 signed integer...well there is trouble to come, but this wasn't the case here and I used it inaccurately as a hint, which I wouldn't if someone is asking this kind of a question on a blog which is assigned to system programming. You may delete the line if you want to, if you fear that someone may get on the wrong track, by taking my statement universally valid. | |
| Dec 5, 2013 at 17:28 | comment | added | Stefan | but anyways. talking about portability and using system types is always kind of a headache, but due to the fact you're dealing with a real machine and not a mathematical abstraction. Again I'd advise you to use the stdint.h or cstdint header for portability, but then WRI must change their code as well to work properly...which I doubt they do. So yes. To be portable you should use some preprocessor statements in order to find out what platform you are on. | |
| Dec 5, 2013 at 17:22 | comment | added | Stefan | @JacobAkkerboom as long as there is no one else using mint as a typedef for a signed 4 byte value, it is absolutely distinguishable. Actually there are two common schemes for integer size representation. LP64 and LLP64 (used by Microsoft). On a LP64 system (MacOsX, Linux etc.) LP64 is used where a long is 64- bit. On a LLP64 it has the same size as a regular int (32-bit). I don't have the header file here to check that for Unix. But I can remember for Windows there are a ladder of #ifdefs using the most appropriate signed int type on that platform. | |
| Dec 5, 2013 at 16:48 | comment | added | Jacob Akkerboom | So my guess is that that is what the mint typedef is for, and that it is not for distinguishing between code that deals with librarylink vs other code | |
| Dec 5, 2013 at 16:45 | comment | added | Jacob Akkerboom | Herm no you never mentioned that they were for portability issues. That's not my point :). I guess it seems intuitive to expect that mint will be the same size as a signed int (int), but I found this is not the case. Quoting halirutan in the linked question above: "What I would have to do is to look up the underlying type of mint, which is long on my machine here". My guess is that long is now usually being used for 64 bit integers and int for 32 bit integers, so much so that in 64 bit operating systems int may not be most efficient integer type to work with, whereas mint does satisfy this. | |
| Dec 5, 2013 at 15:59 | comment | added | Stefan | @JacobAkkerboom hmm. I don't get your comment. Did I ever mention that these types are for portability issues? But you shall expect that on a specific platform where LibraryLink is available the typedef'd mint type is of same size than the internal used type for a signed integer by the runtime library. If someone in his code relies on a signed integer to be 4 bytes always (you shouldn't do this anyways) then this someone has indeed a problem. That is why there is a stdint.h where the integer types are well defined, according the standard (C99). which LibraryLink lacks to support...alas | |
| Dec 5, 2013 at 14:02 | comment | added | Jacob Akkerboom | @Stefan, concerning your statement: "These typedefs are just there so that you can easily distinguish between code that deals with LibraryLink and your C/C++ library side"; Maybe I am reading this wrong, but the the file WolframLibrary.h varies across platforms. For some people mint will be defined as a long or something else. So this will not lead to a portable solution. See also. | |
| Apr 7, 2013 at 2:49 | vote | accept | xslittlegrass | ||
| Apr 7, 2013 at 2:48 | comment | added | xslittlegrass | Yes, that's a very good advice, and thank you very much for you help! | |
| Apr 6, 2013 at 8:47 | comment | added | Stefan | @xslittlegrass Had no machine with Mma yesterday. Glad that someone else helped you, although i've to say, that your original question was a bit different. In the end it was all C-coding and not a type conversion problem. My advise to you is to use MathLink at the beginning, so if you do something wrong, your kernel does not crash at all and if you're really sure about what you're doing you may switch over to LibraryLink. | |
| Apr 5, 2013 at 19:25 | comment | added | xslittlegrass | The struct M_TENSOR_STRUCT error is because I forgot to include the "WolframCompileLibrary.h" file. After fix that the compilation is OK. But I still can't get the answer right. I've add the code I use to the questions. Could you have a look? Thank you very much. | |
| Apr 5, 2013 at 18:11 | comment | added | Stefan | let's try it anyways... say you have a function. there you declare a MTensor struct type (MTensor a;) then you assign the tensor from Mma to a. a = MArgument_getMTensor(Args[0]); now you can access the data type, since it is correctly initialized. your question concerning the void* type... void* is a pointer pointing to nothing, so if you want that pointer to point to something you have to assign this pointer to something, but you have to cast it. it's the same with e.g. malloc which returns a void* and you assign it to an int*. int* i_ptr = (int*)malloc(sizeof(int) * 8); | |
| Apr 5, 2013 at 18:04 | comment | added | Stefan | ok. at that it'd be better you post your actual code. it's obvious that you declared your MTensor struct but did not initialized it. | |
| Apr 5, 2013 at 16:20 | comment | added | xslittlegrass | when I do this, I get compile error: MMA.cc: In function 'int add(st_WolframLibraryData*, mint, MArgument*, MArgument)': MMA.cc:35: error: invalid use of incomplete type 'struct M_TENSOR_STRUCT' WolframLibrary.h:46: error: forward declaration of 'struct M_TENSOR_STRUCT' MMA.cc:35: error: invalid use of incomplete type 'struct M_TENSOR_STRUCT' WolframLibrary.h:46: error: forward declaration of 'struct M_TENSOR_STRUCT' Beside data is a void* type, is it OK to assign it to int [] type? Thanks | |
| Apr 5, 2013 at 16:07 | comment | added | Stefan | i don't get it. is ta now a pointer to a MTensor struct or not? what is wrong with a = ta.data? (as i said before, there is no type conversion needed. the types are identical.) | |
| Apr 5, 2013 at 15:02 | comment | added | xslittlegrass | Thanks for the answer, but I still can't get it to work. Could you be more specific about the data type conversion? For example, I have a MTensor ta which contains a one dimensional array of mint, how can I convert it to a which is a int array? I tried something like a=(*ta).data but it dones't work. | |
| Apr 5, 2013 at 8:13 | history | answered | Stefan | CC BY-SA 3.0 |