portability

Converting Little Endian to Big Endian

孤者浪人 提交于 2019-11-26 20:37:40
All, I have been practicing coding problems online. Currently I am working on a problem statement Problems where we need to convert Big Endian <-> little endian. But I am not able to jot down the steps considering the example given as: 123456789 converts to 365779719 The logic I am considering is : 1 > Get the integer value (Since I am on Windows x86, the input is Little endian) 2 > Generate the hex representation of the same. 3 > Reverse the representation and generate the big endian integer value But I am obviously missing something here. Can anyone please guide me. I am coding in Java 1.5

What's the difference between “int” and “int_fast16_t”?

夙愿已清 提交于 2019-11-26 20:19:19
问题 As I understand it, the C specification says that type int is supposed to be the most efficient type on target platform that contains at least 16 bits. Isn't that exactly what the C99 definition of int_fast16_t is too? Maybe they put it in there just for consistency, since the other int_fastXX_t are needed? Update To summarize discussion below: My question was wrong in many ways. The C standard does not specify bitness for int . It gives a range [-32767,32767] that it must contain. I realize

Is there any “standard” htonl-like function for 64 bits integers in C++?

独自空忆成欢 提交于 2019-11-26 19:48:38
I'm working on an implementation of the memcache protocol which, at some points, uses 64 bits integer values. These values must be stored in "network byte order". I wish there was some uint64_t htonll(uint64_t value) function to do the change, but unfortunately, if it exist, I couldn't find it. So I have 1 or 2 questions: Is there any portable (Windows, Linux, AIX) standard function to do this ? If there is no such function, how would you implement it ? I have in mind a basic implementation but I don't know how to check the endianness at compile-time to make the code portable. So your help is

GLIBCXX versions

狂风中的少年 提交于 2019-11-26 19:34:51
问题 If I compile a C++ program on my machine, and run it on another one (with older software) I get: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found . In fact on my system glibc is newer (I got gcc-libs 4.5.1: libstdc++.so.6.0.14) and strings /usr/lib/libstdc++.so.6 | grep GLIBCXX prints from GLIBCXX_3.4 to GLIBCXX_3.4.14 . On the other system, instead, it only prints up to GLIBCXX_3.4.8 (I got libstdc++.so.6.0.8). So I've got a few questions: Why my linker links C++ binaries against

Using Python's ftplib to get a directory listing, portably

爷,独闯天下 提交于 2019-11-26 19:17:02
问题 You can use ftplib for full FTP support in Python. However the preferred way of getting a directory listing is: # File: ftplib-example-1.py import ftplib ftp = ftplib.FTP("www.python.org") ftp.login("anonymous", "ftplib-example-1") data = [] ftp.dir(data.append) ftp.quit() for line in data: print "-", line Which yields: $ python ftplib-example-1.py - total 34 - drwxrwxr-x 11 root 4127 512 Sep 14 14:18 . - drwxrwxr-x 11 root 4127 512 Sep 14 14:18 .. - drwxrwxr-x 2 root 4127 512 Sep 13 15:18

OS specific instructions in CMAKE: How to?

有些话、适合烂在心里 提交于 2019-11-26 18:56:34
问题 I am a beginner to CMAKE. Below is a simple cmake file which works well in mingw environment windows. The problem is clearly with target_link_libraries() function of CMAKE where I am linking libwsock32.a. In windows this works and I get the results. However, as expected, in Linux, the /usr/bin/ld will look for -lwsock32 which is NOT there on the Linux OS. My Problem is: How do I instruct CMAKE to avoid linking wsock32 library in Linux OS??? Any help will be greatly appreciated. My Simple

Does TortoiseGit work with PortableGit-x.x.x.x-previewyyyyyy? What are compatible git versions for TortoiseGit?

本小妞迷上赌 提交于 2019-11-26 16:55:55
问题 Does Tortoisegit work with PortableGit-x.x.x.x-previewyyyyyy? If yes, how to arrange these? 回答1: Original answer (Nov. 2011) It depends on your Os (Win32 or 64), and on the combination of TortoiseGit and msysgit. The latest versions of both should usually work together, but you can see some bugs still pending: Issue 948: TortoiseProc crashes when repo contains huge files Issue 875: TGitCache crash Whenever you have a similar issue, report it on the bug list, and look for an intermediate build

In C++, is it safe/portable to use static member function pointer for C API callbacks?

不羁岁月 提交于 2019-11-26 16:22:30
In C++, is it safe/portable to use static member function pointer for C API callbacks? Is the ABI of a static member function the same as a C function? Michael Burr It is not safe per the C++ standard. As stated in this SO posting : A C callback function implemented in C++ must be extern "C". It may seem to work as a static function in a class because class-static functions often use the same calling convention as a C function. However, doing that is a bug waiting to happen (see comments below), so please don't - go through an extern "C" wrapper instead. And according to comments made by

msys path conversion (or cygpath for msys?)

社会主义新天地 提交于 2019-11-26 15:47:47
问题 I need to pass /DEF:c:\filepath\myLib.def" command line option from a bash script to MS compiler/linker. The path is generated as part of build process by a bash script. Basically, the argument that my script passes is: -DEF:/c/filepath/myLib.def MSYS path conversion can't handle it properly because it doesn't understand /DEF: part. It works if I do -DEF=/c/filepath/myLib.def but then ms tools don't understand this parameter. In short, what's the proper way to write that parameter in MSYS

Portable way of setting std::thread priority in C++11

假装没事ソ 提交于 2019-11-26 15:37:27
问题 What is the correct way in the post C++11 world for setting the priority of an instance of std::thread Is there a portable way of doing this that works at least in Windows and POSIX (Linux) environments? Or is it a matter of getting a handle and using whatever native calls are available for the particular OS? 回答1: There's no way to set thread priorities via the C++11 library. I don't think this is going to change in C++14, and my crystal ball is too hazy to comment on versions after that. In