portability

问题 I understand that writing anything in assembly, or adding assembly to any program harms its portability. But, how bad? I mean, basically all PC's are x86 or x64 these days, right? So, if I embed assembly into a C program, why wouldn't it still compile no matter where it went? Does this notion of un-portability just refer to when you really dig in to the specific quirks of a specific processor, to squeeze out every drop of performance from a piece of code? The PC game "Roller Coaster Tycoon"

问题 In my SConscript I have the following line: Program("xtest", Split("main.cpp"), LIBS="mylib fltk Xft Xinerama Xext X11 m") How do I get scons to use mylib.a instead of mylib.so, while linking dynamically with the other libraries? EDIT: Looking to use as few platform specific hacks as possible. 回答1: Passing the full filepath wrapped in a File node will force static linking. For example: lib = File('/usr/lib/libfoo.a') Program('bar', 'main.c', LIBS = [lib]) Will produce the following linker

问题 I'm developing an application for Android, and I'm thinking that it's functionality might be useful on other (Java-running) platforms (say a regular desktop app -- although I hope that the other platform(s) involved are immaterial to the question at hand). It's unlikely that the UI will be in any way portable (there's just too much of a difference between a good touch-capable, 4in screen UI, and a mouse-and-keyboard 19in screen UI), so I'm happy enough reimplementing that separately. However,

问题 Help me settle a score. I have a piece of software written in C++ that's meant to run on as many linux distributions as possible and I need to figure out a strategy that's effective. I'm trying to ship binaries in this case not source code (might be good to know). It's already a commercial product and I have intellectual property issues that prevent me from open sourcing the product but also means I have to deal with a myriad of GPL issues. The current line of reasoning has been to pick a

问题 With Mingw 4.7.2, I have a library that doesn't compile because of a call to isnan . The compiler says "everything will be fine" if I use std::isnan , and indeed I manage to compile my file. But if I check here ( Edit: but maybe I should have checked also here :-) ), the std:: doesn't seem to be necessary. If I add it, will the file be portable? More in general, for each case is there a general way to understand when putting std:: is necessary (for portability), optional or to be avoided?

问题 If there is for example a class that requires a pointer and a bool . For simplicity an int pointer will be used in examples, but the pointer type is irrelevant as long as it points to something whose size() is more than 1 . Defining the class with { bool , int *} data members will result in the class having a size that is double the size of the pointer and a lot of wasted space If the pointer does not point to a char (or other data of size(1) ), then presumably the low bit will always be zero

问题 Edited again because it originally wasn't clear that I'm trying to initialize the arrays at compile time, not at run time... I've got the following reduced testcase: typedef struct TestStruct { int length; int values[]; }; TestStruct t = {3, {0, 1, 2}}; TestStruct t2 = {4, {0, 1, 2, 3}}; int main() { return(0); } This works with Visual C++, but doesn't compile with g++ under linux. Can anyone help me make this specific kind of initializer portable? Additional details: the actual structure I'm

问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 3 years ago . I'm looking for a good and easy in maintenance portable build system for C++ projects. Main platforms should include Windows (Visual Studio 8+) and Linux (gcc); Cygwin may be an advantage. We're considering two main possibilities: CMake and Boost.Jam . SCons can be also an option, but I haven't investigated it

问题 What is the defined behavior in C for UINT_MAX + 1u ? How safe is to assume it is zero? 回答1: From the standard (C11, 6.2.5/9, emphasis mine): [...] A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type . If UINT_MAX is 10 : (10 + 1) % (10 + 1) == 0 So, yes, it's safe to assume it's zero.

问题 Background When designing binary file formats, it's generally recommended to write integers in network byte order. For that, there are macros like htonhl() . But for a format such as WAV, actually the little endian format is used. Question How do you portably write little endian values, regardless of if the CPU your code runs on is a big endian or little endian architecture? (Ideas: can the standard macros ntohl() and htonl() be used "in reverse" somehow? Or should the code just test runtime