mercredi 2 septembre 2015

Showing values of parameters packs in gdb

How can one see the values of a parameter pack in a variadic function in gdb?

Sample code (VariadicDebug.cpp):

template <typename... Ts> int Do(int a, Ts... ts)
{
  // Add breakpoint here. a can be seen using 'print a' but how to show ts???
  return a;
}

int main(int argc, char **argv)
{
  return Do(0, "Hello world!", 88.9);
}

Compile with

g++ --std=c++11 -O0 -g VariadicDebug.cpp

And run gdb:

$ gdb ./a.exe
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://ift.tt/KpOJT7;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-msys".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://ift.tt/xLrliR;.
Find the GDB manual and other documentation resources online at:
<http://ift.tt/1gENejF;.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.exe...done.
(gdb) break VariadicDebug.cpp:4
Breakpoint 1 at 0x100401760: file VariadicDebug.cpp, line 4.
(gdb) run
Starting program: /c/Data/tests/a.exe
[New Thread 8008.0x1dd0]
[New Thread 8008.0x2898]
[New Thread 8008.0x26f0]
[New Thread 8008.0x1498]

Breakpoint 1, Do<char const*, double> (a=0) at VariadicDebug.cpp:4
4         return a;
(gdb) info args
a = 0

As you can see: It only gives the value for a not for ts.

Trouble using the sieve of eratosthenes

Given a number k, i have to find the smallest number which is not prime and does not divide with the first k prime numbers. I used the sieve of eratosthenes algorithm but i always get the result 1. I can`t understand why because i starts from 2. Any suggestions?

#define lim 100000
#include <fstream>
using namespace std;

bool prim [lim];
int i,j,k,c,n;

fstream f("prim.in");
ofstream g("prim.out");

int main()
{
f>>k;
for(i=2;i<=lim;i++)
{
if(prim[i]==0)
    {
        c++;
for(j=i*2;j<=lim;j+=i)
   prim[j]=1;
   }
if(prim[i]==0) if(c==k+1){ g << i*i; return 0;}
}
}

mardi 1 septembre 2015

Undefined behavior with std::move

From the move page of the cppreference

Unless otherwise specified, all standard library objects that have been moved from are placed in a valid but unspecified state. That is, only the functions without preconditions, such as the assignment operator, can be safely used on the object after it was moved from

So, from the example on the same page, this code below is considered undefined behaviour

vector<string> v_string;
string example = "example";
v_string.push_back(move(example));
cout << example << endl;

MSVC will output nothing on the console, but if I do this

vector<int> v_int;
int number = 10;
v_int.push_back(move(number));
cout << number << endl;

will output 10. Is there a reason why this happens? Or is it always undefined behavior?

Regarding the C++ array type

I asked a similar question before but my next question will be in reference to the following code

#include <iostream>
using namespace std;

template <typename T>
struct which_type {
    static inline string type() {return "General type";}
};

template <typename T>
struct which_type<T*> {
    static inline string type() {return "T*";}
};

template <typename T>
struct which_type<T**> {
    static inline string type() {return "T**";}
};

template <typename T, int N>
struct which_type<T (&) [N]> {
    static inline string type() {return "T (&) [N]";}
};

template <typename T, int N>
struct which_type<T (*) [N]> {
    static inline string type() {return "T (*) [N]";}
};

template <typename T, size_t N>
struct which_type<T[N]> {
    static inline string type() {return "T[N]";}
};

template <typename T>
struct which_type<T[]> {
    static inline string type() {return "T[]";}
};

void which_type_is_array(int a[]) {
    cout << which_type<decltype(a)>::type() << endl;
}


extern int e[];

int main() {

    int a[1];
    int *b;
    int* c[1];
    int (&d) [1] = a;
    cout << which_type<decltype(a)>::type() << endl;
    cout << which_type<decltype(b)>::type() << endl;
    cout << which_type<decltype(c)>::type() << endl;
    cout << which_type<decltype(d)>::type() << endl;
    cout << which_type<decltype(e)>::type() << endl;
    which_type_is_array(a);

    // cout << what_number<2>::what() << endl;


    // int (*ret_int) (int);
    // ret_int = &foo;
    // cout << ret_int(1) << endl;


    return 0;
}

In which cases does the call to which_type<>::type() get resolved to the partially specialized case of the struct taking a T[]? The case of the extern int does but not of the one in which_type_is_array(). Why?

Thanks!

c++ Why low level const important when doing assignment?

I have the following codes:

const int v2 = 0; int v1 = v2;                 // v2 - top level const
int *p1 = &v1, &r1 = v1;
const int *p2 = &v2, *const p3 = &i, &r2 = v2; // p2 - low level const
                                                  p3 - top level const & low level const
                                                  r2 - low level const

I do understand the top and low level const.

Question:
Why p1 = p2 failed?

According to C++ Primer 5th Ed (Stanley Lipmann) p2 const is low level and hence cannot be ignored. Assignment of p2 low level const to p1 which is int * failed.

But if i think hard, assigning to p1 doesn't change object p2. So what does it matter if p1 is int * and the p2 has low level const? Just doesn't make sense to me.

Xcode: how to build for older Intel processors (i5, Core 2 Duo) on i7

My is built using the Xcode (6 and 6.4), on OSX 10.9 and 10.10, when using llvm (6.1) and C++11. The SDK is 10.10, the target OSX is 10.7,

The crash is very very early on when the C runtime is loading my application binary:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.ReconInstruments.UplinkDesktop  0x000000010cd10e7a _GLOBAL__I_a + 10
1   dyld                            0x00007fff61fd3ceb    ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 265
2   dyld                            0x00007fff61fd3e78 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
3   dyld                            0x00007fff61fd0871 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, 

This is before any of my application code. The crash does not occur on the build machine (i7 CPU). Crashes occur on i5 and Core 2 Duo machines. I suspect that an extended (CPU specific) instruction is creating the crash on load.

I am also using homebrew: libmtp, libusb, libusb-compat, cryptopp, curl (with c-ares, openssl, nghttp2), boost. I have specified C++11 where necessary. I am statically linking to these libraries.

I have tried to use otool -tV on all libraries, the final binary, etc to find SSE instructions (grep SSE) to no avail.

I have tried to set the Xcode LLVM build setting "Enable Additional Vector Extensions" to "platform" and "SSE3" to no avail.

Are there other tools I can should use to narrow down the offending instruction?

undefined reference to WinMain@16 C++, SDL-2

I've been getting the error undefined reference to WinMain@16. To save space, here's a link to all the files currently in the project. At present, it shouldn't do much other than create a window, fill it in green and then draw a box in the corner, all the while tracking my mouse's position through the console. However, it won't build and I'm given the aforementioned error.

My linker libraries are:

  • glew32s
  • libSDL2main
  • mingw32
  • libSDL2
  • opengl32
  • glew32

I am using Codeblocks 13.12 with g++ following the C++11 ISO C++ language standard. My PC is using windows 10 in case that's relevant.

I've spent quite a while trying to find a solution and it seems everyone has an entirely different one, and so far none of them have worked for me. A few examples include:

  • Adding SDL2_image to my link libraries in accordance with this similar question. It gave me the error -lSDL2_image.
  • Starting the project entirely from scratch in case some typo I failed to notice was the cause. (I got exactly the same error).
  • Changing my main function to WinMain. I got the same error message.
  • Adding a Windows.h header. This did nothing noticeable.
  • Various alleged "right orders" for my liker libraries. None of those have seemed to help thus far.

I should also point out that the answer provide by the user, Cheers and hth. - Alf, here might be what I'm looking for, but in all honesty I can't fully understand what I'm supposed to do in based on it.

If there's any relevant information that I forgot to include, please tell me and I'll do so as soon as possible. Thanks in advance.