Can I convert my Visual C++ win32 project into a crossplatform later?











up vote
-2
down vote

favorite












does anybody know if it is possible to use the code from a win32 static libary
in a cross platform one? I know i have to make some changes to the code but i think c++ code is the same on all platforms except for the classes. For simple types somebody told me to use the int16_t or int16_fast_t instead or short for example. Is that correct that i could just copy ally the headers and files from visual studio and compile them for mac with for example code lite - if code itself is crossplatform?



Best Regards,



K










share|improve this question






















  • Be careful not to call any OS specific functions.
    – Jesper Juhl
    Nov 11 at 11:29










  • It would be a good idea to define your own types (or at least type alias) serving specific purpose instead of generic int16_t. As for question itself, it is not clear why are you calling your library "win32", it code is the same on all platforms, then it is platform-independent, if it is not - then you can extract platform depended parts and implement them differently on different platforms.
    – VTT
    Nov 11 at 11:32












  • Thats what i wanted to know - i can reuse code. Pls write an answer :)
    – Kerbo Games
    Nov 11 at 11:39















up vote
-2
down vote

favorite












does anybody know if it is possible to use the code from a win32 static libary
in a cross platform one? I know i have to make some changes to the code but i think c++ code is the same on all platforms except for the classes. For simple types somebody told me to use the int16_t or int16_fast_t instead or short for example. Is that correct that i could just copy ally the headers and files from visual studio and compile them for mac with for example code lite - if code itself is crossplatform?



Best Regards,



K










share|improve this question






















  • Be careful not to call any OS specific functions.
    – Jesper Juhl
    Nov 11 at 11:29










  • It would be a good idea to define your own types (or at least type alias) serving specific purpose instead of generic int16_t. As for question itself, it is not clear why are you calling your library "win32", it code is the same on all platforms, then it is platform-independent, if it is not - then you can extract platform depended parts and implement them differently on different platforms.
    – VTT
    Nov 11 at 11:32












  • Thats what i wanted to know - i can reuse code. Pls write an answer :)
    – Kerbo Games
    Nov 11 at 11:39













up vote
-2
down vote

favorite









up vote
-2
down vote

favorite











does anybody know if it is possible to use the code from a win32 static libary
in a cross platform one? I know i have to make some changes to the code but i think c++ code is the same on all platforms except for the classes. For simple types somebody told me to use the int16_t or int16_fast_t instead or short for example. Is that correct that i could just copy ally the headers and files from visual studio and compile them for mac with for example code lite - if code itself is crossplatform?



Best Regards,



K










share|improve this question













does anybody know if it is possible to use the code from a win32 static libary
in a cross platform one? I know i have to make some changes to the code but i think c++ code is the same on all platforms except for the classes. For simple types somebody told me to use the int16_t or int16_fast_t instead or short for example. Is that correct that i could just copy ally the headers and files from visual studio and compile them for mac with for example code lite - if code itself is crossplatform?



Best Regards,



K







c++ visual-c++






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 11 at 11:26









Kerbo Games

14




14












  • Be careful not to call any OS specific functions.
    – Jesper Juhl
    Nov 11 at 11:29










  • It would be a good idea to define your own types (or at least type alias) serving specific purpose instead of generic int16_t. As for question itself, it is not clear why are you calling your library "win32", it code is the same on all platforms, then it is platform-independent, if it is not - then you can extract platform depended parts and implement them differently on different platforms.
    – VTT
    Nov 11 at 11:32












  • Thats what i wanted to know - i can reuse code. Pls write an answer :)
    – Kerbo Games
    Nov 11 at 11:39


















  • Be careful not to call any OS specific functions.
    – Jesper Juhl
    Nov 11 at 11:29










  • It would be a good idea to define your own types (or at least type alias) serving specific purpose instead of generic int16_t. As for question itself, it is not clear why are you calling your library "win32", it code is the same on all platforms, then it is platform-independent, if it is not - then you can extract platform depended parts and implement them differently on different platforms.
    – VTT
    Nov 11 at 11:32












  • Thats what i wanted to know - i can reuse code. Pls write an answer :)
    – Kerbo Games
    Nov 11 at 11:39
















Be careful not to call any OS specific functions.
– Jesper Juhl
Nov 11 at 11:29




Be careful not to call any OS specific functions.
– Jesper Juhl
Nov 11 at 11:29












It would be a good idea to define your own types (or at least type alias) serving specific purpose instead of generic int16_t. As for question itself, it is not clear why are you calling your library "win32", it code is the same on all platforms, then it is platform-independent, if it is not - then you can extract platform depended parts and implement them differently on different platforms.
– VTT
Nov 11 at 11:32






It would be a good idea to define your own types (or at least type alias) serving specific purpose instead of generic int16_t. As for question itself, it is not clear why are you calling your library "win32", it code is the same on all platforms, then it is platform-independent, if it is not - then you can extract platform depended parts and implement them differently on different platforms.
– VTT
Nov 11 at 11:32














Thats what i wanted to know - i can reuse code. Pls write an answer :)
– Kerbo Games
Nov 11 at 11:39




Thats what i wanted to know - i can reuse code. Pls write an answer :)
– Kerbo Games
Nov 11 at 11:39












1 Answer
1






active

oldest

votes

















up vote
2
down vote



accepted










It depends on what's in that library. The fact that it's a Visual C++ Win32 static library project tells us how your library is compiled. It does not tell us anything about what code goes into that library. It might be all perfectly portable Standard C++ code. It might as well be code where every second line is a Windows API function call that will obviously not be portable.



Whether or not the code of a library will be portable all depends on the code. Replacing short with int16_t or int_fast16_t will do nothing to increase the portability of code (unless the original use of short assumed some implementation-defined properties). So I'm not sure what a blanket replacement of short with int16_t is supposed to achieve. short is a fundamental type built into the language. int16_t is a type defined by the standard library if the target platform supports it. So, in a way, int16_t is actually less portable than short. While int_fast16_t is always defined, so is short. Use the fixed-width integer types of the standard library if you need the semantics that they provide. If you don't then there's no reason to use them. Note that to use the fixed-width integer types in C++, include the C++ header <cstdint> rather than <stdint.h> which is not guaranteed to be present in C++. Also note that <cstdint> is only guaranteed to place declarations in namespace std. So for maximum portability, use std::int16_t because it is not guaranteed that ::int16_t is available.



If the code of the library is portable, then all you will need to build that library on another platform is a buildsystem for that platform. So yes, it is correct that if the code is portable, all you need to do is compile that code on the other platform using whatever tools you use on that other platform…that's kind of the very definition of what it means for code to be portable… ;-)






share|improve this answer























  • Thank you very much :)
    – Kerbo Games
    Nov 11 at 14:38











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53248253%2fcan-i-convert-my-visual-c-win32-project-into-a-crossplatform-later%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote



accepted










It depends on what's in that library. The fact that it's a Visual C++ Win32 static library project tells us how your library is compiled. It does not tell us anything about what code goes into that library. It might be all perfectly portable Standard C++ code. It might as well be code where every second line is a Windows API function call that will obviously not be portable.



Whether or not the code of a library will be portable all depends on the code. Replacing short with int16_t or int_fast16_t will do nothing to increase the portability of code (unless the original use of short assumed some implementation-defined properties). So I'm not sure what a blanket replacement of short with int16_t is supposed to achieve. short is a fundamental type built into the language. int16_t is a type defined by the standard library if the target platform supports it. So, in a way, int16_t is actually less portable than short. While int_fast16_t is always defined, so is short. Use the fixed-width integer types of the standard library if you need the semantics that they provide. If you don't then there's no reason to use them. Note that to use the fixed-width integer types in C++, include the C++ header <cstdint> rather than <stdint.h> which is not guaranteed to be present in C++. Also note that <cstdint> is only guaranteed to place declarations in namespace std. So for maximum portability, use std::int16_t because it is not guaranteed that ::int16_t is available.



If the code of the library is portable, then all you will need to build that library on another platform is a buildsystem for that platform. So yes, it is correct that if the code is portable, all you need to do is compile that code on the other platform using whatever tools you use on that other platform…that's kind of the very definition of what it means for code to be portable… ;-)






share|improve this answer























  • Thank you very much :)
    – Kerbo Games
    Nov 11 at 14:38















up vote
2
down vote



accepted










It depends on what's in that library. The fact that it's a Visual C++ Win32 static library project tells us how your library is compiled. It does not tell us anything about what code goes into that library. It might be all perfectly portable Standard C++ code. It might as well be code where every second line is a Windows API function call that will obviously not be portable.



Whether or not the code of a library will be portable all depends on the code. Replacing short with int16_t or int_fast16_t will do nothing to increase the portability of code (unless the original use of short assumed some implementation-defined properties). So I'm not sure what a blanket replacement of short with int16_t is supposed to achieve. short is a fundamental type built into the language. int16_t is a type defined by the standard library if the target platform supports it. So, in a way, int16_t is actually less portable than short. While int_fast16_t is always defined, so is short. Use the fixed-width integer types of the standard library if you need the semantics that they provide. If you don't then there's no reason to use them. Note that to use the fixed-width integer types in C++, include the C++ header <cstdint> rather than <stdint.h> which is not guaranteed to be present in C++. Also note that <cstdint> is only guaranteed to place declarations in namespace std. So for maximum portability, use std::int16_t because it is not guaranteed that ::int16_t is available.



If the code of the library is portable, then all you will need to build that library on another platform is a buildsystem for that platform. So yes, it is correct that if the code is portable, all you need to do is compile that code on the other platform using whatever tools you use on that other platform…that's kind of the very definition of what it means for code to be portable… ;-)






share|improve this answer























  • Thank you very much :)
    – Kerbo Games
    Nov 11 at 14:38













up vote
2
down vote



accepted







up vote
2
down vote



accepted






It depends on what's in that library. The fact that it's a Visual C++ Win32 static library project tells us how your library is compiled. It does not tell us anything about what code goes into that library. It might be all perfectly portable Standard C++ code. It might as well be code where every second line is a Windows API function call that will obviously not be portable.



Whether or not the code of a library will be portable all depends on the code. Replacing short with int16_t or int_fast16_t will do nothing to increase the portability of code (unless the original use of short assumed some implementation-defined properties). So I'm not sure what a blanket replacement of short with int16_t is supposed to achieve. short is a fundamental type built into the language. int16_t is a type defined by the standard library if the target platform supports it. So, in a way, int16_t is actually less portable than short. While int_fast16_t is always defined, so is short. Use the fixed-width integer types of the standard library if you need the semantics that they provide. If you don't then there's no reason to use them. Note that to use the fixed-width integer types in C++, include the C++ header <cstdint> rather than <stdint.h> which is not guaranteed to be present in C++. Also note that <cstdint> is only guaranteed to place declarations in namespace std. So for maximum portability, use std::int16_t because it is not guaranteed that ::int16_t is available.



If the code of the library is portable, then all you will need to build that library on another platform is a buildsystem for that platform. So yes, it is correct that if the code is portable, all you need to do is compile that code on the other platform using whatever tools you use on that other platform…that's kind of the very definition of what it means for code to be portable… ;-)






share|improve this answer














It depends on what's in that library. The fact that it's a Visual C++ Win32 static library project tells us how your library is compiled. It does not tell us anything about what code goes into that library. It might be all perfectly portable Standard C++ code. It might as well be code where every second line is a Windows API function call that will obviously not be portable.



Whether or not the code of a library will be portable all depends on the code. Replacing short with int16_t or int_fast16_t will do nothing to increase the portability of code (unless the original use of short assumed some implementation-defined properties). So I'm not sure what a blanket replacement of short with int16_t is supposed to achieve. short is a fundamental type built into the language. int16_t is a type defined by the standard library if the target platform supports it. So, in a way, int16_t is actually less portable than short. While int_fast16_t is always defined, so is short. Use the fixed-width integer types of the standard library if you need the semantics that they provide. If you don't then there's no reason to use them. Note that to use the fixed-width integer types in C++, include the C++ header <cstdint> rather than <stdint.h> which is not guaranteed to be present in C++. Also note that <cstdint> is only guaranteed to place declarations in namespace std. So for maximum portability, use std::int16_t because it is not guaranteed that ::int16_t is available.



If the code of the library is portable, then all you will need to build that library on another platform is a buildsystem for that platform. So yes, it is correct that if the code is portable, all you need to do is compile that code on the other platform using whatever tools you use on that other platform…that's kind of the very definition of what it means for code to be portable… ;-)







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 11 at 14:25

























answered Nov 11 at 12:43









Michael Kenzel

3,143715




3,143715












  • Thank you very much :)
    – Kerbo Games
    Nov 11 at 14:38


















  • Thank you very much :)
    – Kerbo Games
    Nov 11 at 14:38
















Thank you very much :)
– Kerbo Games
Nov 11 at 14:38




Thank you very much :)
– Kerbo Games
Nov 11 at 14:38


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53248253%2fcan-i-convert-my-visual-c-win32-project-into-a-crossplatform-later%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Bressuire

Vorschmack

Quarantine