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
c++ visual-c++
add a comment |
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
c++ visual-c++
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
add a comment |
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
c++ visual-c++
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++
c++ visual-c++
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
add a comment |
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
add a comment |
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… ;-)
Thank you very much :)
– Kerbo Games
Nov 11 at 14:38
add a comment |
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… ;-)
Thank you very much :)
– Kerbo Games
Nov 11 at 14:38
add a comment |
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… ;-)
Thank you very much :)
– Kerbo Games
Nov 11 at 14:38
add a comment |
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… ;-)
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… ;-)
edited Nov 11 at 14:25
answered Nov 11 at 12:43
Michael Kenzel
3,153715
3,153715
Thank you very much :)
– Kerbo Games
Nov 11 at 14:38
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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