C/C++ Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›641 »

Xerophyte: Mar 17, 2008; This space intentionally left blank

I think VS2012 did add support for initializer lists and uniform initialization in some CTP or other, although it didn't have it initially. Regardless, all versions of 2012 support emplace (in-place construction) for containers and shared_ptr:s are EmplaceConstructible so

code:

std::unordered_map<int, std::shared_ptr<BNode>> map;
map.emplace(k,node);

should work.

# ? Sep 29, 2013 15:56

Adbot: ADBOT LOVES YOU

# ? Jun 9, 2024 02:14

xgalaxy: Jan 27, 2004; i write code

2013 supports initializer lists but I don't know how buggy it is

It's also not released yet. It's in RC until November I think.

# ? Sep 29, 2013 16:29

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

Yeah, the VS C/C++ compilers can be... janky. The one people most often run into (in VS2012 at least) is that its C compiler insists local variables be declared at the beginning of their scope. Which is C89.

# ? Sep 29, 2013 18:49

xgalaxy: Jan 27, 2004; i write code

coffeetable posted:

Yeah, the VS C/C++ compilers can be... janky. The one people most often run into (in VS2012 at least) is that its C compiler insists local variables be declared at the beginning of their scope. Which is C89.

Well.. thats because Visual Studio only has a C89 compiler.
VS 2013 brought in some C99 library support but not much.

# ? Sep 29, 2013 18:57

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

xgalaxy posted:

Well.. thats because Visual Studio only has a C89 compiler.
VS 2013 brought in some C99 library support but not much.

For some reason I thought it had a fair bit of C99 already, but yeah you're right. Mystery solved.

# ? Sep 29, 2013 19:02

MrMoo: Sep 14, 2000

xgalaxy posted:

VS 2013 brought in some C99 library support but not much.

Building NaCl in C99 I found basic

code:

for (int i = 0;;)

constructs fail in inline functions, bizarre.

# ? Sep 29, 2013 19:28

Mr.Radar: Nov 5, 2005; You guys aren't going to believe this, but that guy is our games teacher.

xgalaxy posted:

Well.. thats because Visual Studio only has a C89 compiler.
VS 2013 brought in some C99 library support but not much.

VS2013 is also (finally) adding support for _Bool, compound literals, designated initializers, and mixing declarations with code although Microsoft don't really seem to be going out of their way to publicize these new features.

# ? Sep 29, 2013 19:41

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Is there a system call to determine whether the system is big endian or not? I've got code that works, so this is more a curiosity than anything.

code:

bool isBigEndianSystem()
{
   static bool firstCall = true;
   static bool result;

   if (firstCall)
   {
      firstCall = false;
      
      union
      {
         unsigned int u;
         unsigned char c[4];
      } u;
      u.u = 1;
      result = (u.c[3] == 1);
   }

   return result;
}

# ? Sep 30, 2013 19:10

pseudorandom name: May 6, 2007

BSDs and Linuxes have a endian.h which defines a BYTE_ORDER, although there isn't really a reason to test it.

Your data has a defined endianness, just unconditionally use the endian functions to do the conversion and rely on the fact that they'll be no-ops on the platforms where the endian matches.

# ? Sep 30, 2013 19:26

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

Why do you want to check the byte order? If you need to encode and decode integers in a standard format, Unix systems already have functions for that.

# ? Sep 30, 2013 20:12

Volguus: Mar 3, 2009

Gazpacho posted:

Why do you want to check the byte order? If you need to encode and decode integers in a standard format, Unix systems already have functions for that.

In embedded development you may. If you get a board from some strange vendor that has a chip with few K of ram and runs like is being powered by hungry hamsters, chances are that you won't have access to endian.h .
At which point you will have to write your own test routine. What I found on stackoverflow looks like a good approach, though there may be simpler ones out there: http://stackoverflow.com/questions/2100331/c-macro-definition-to-determine-big-endian-or-little-endian-machine

# ? Sep 30, 2013 22:09

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Gazpacho posted:

Why do you want to check the byte order? If you need to encode and decode integers in a standard format, Unix systems already have functions for that.

'cos I'm an idiot who totally didn't forget about those, nosir :saddowns:

(The real answer: I'm still working on a port from Solaris/SPARC/SunCC to Linux/Intel/GCC and gotta fix all the file I/O issues that have cropped up.)

_{^{god, six years outta college and i still don't have simple poo poo like this straight}}

Ciaphas fucked around with this message at 23:20 on Sep 30, 2013

# ? Sep 30, 2013 23:16

hooah: Feb 6, 2006; WTF?

For a previous class assignment, we had to calculate pi to 18 decimals via a few different iterative methods and compare them to the "exact" value calculated by arccos(-1). This worked fine for me in Visual Studio 2013, but in NetBeans (7.3.1, g++ 4.8.1), I get some crazy number for pi. Here's the shortest code that generates the problem, and the number I get:

code:

#include <iostream>
#include <iomanip>
#include <cmath>


using std::cout;
using std::endl;
using std::setprecision;
using std::acos;

int main() {
    long double pi_18 = acos(static_cast<long double>(-1.0));
    cout.precision(18);
    cout << pi_18 << endl;
}

Result is -8.8796093704934495e+043.

The line that declares and initializes pi_18 is what the professor gave us. What's going wrong?

# ? Oct 2, 2013 14:52

nielsm: Jun 1, 2009

hooah posted:

The line that declares and initializes pi_18 is what the professor gave us. What's going wrong?

Good question.

Works just fine for me, i686-apple-darwin11-llvm-g++-4.2 and also a vanilla 4.7 version.

# ? Oct 2, 2013 15:21

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

Wild guess: You're linking to a C math library that only has acos(double), so the argument and the result are being reinterpreted accordingly.

edit: Relevant stackoverflow: http://stackoverflow.com/questions/7134547/gcc-printf-and-long-double-leads-to-wrong-output-c-type-conversion-messes-u

The gist is that gcc and MSVC do not agree on what a long double is, and MSVC considers it the same as double. Try cygwin, or a Unix platform if you have one.

Gazpacho fucked around with this message at 07:55 on Oct 3, 2013

# ? Oct 2, 2013 21:59

fritz: Jul 26, 2003

nielsm posted:

Good question.

Works just fine for me, i686-apple-darwin11-llvm-g++-4.2 and also a vanilla 4.7 version.

Same here, on a linux 2.6 machine (centos?) with an ancient g++ (4.1.2)

# ? Oct 2, 2013 22:24

Marta Velasquez: Mar 9, 2013; Good thing I was feeling suicidal this morning...; Fallen Rib

fritz posted:

Same here, on a linux 2.6 machine (centos?) with an ancient g++ (4.1.2)

Also works on my 64-bit Gentoo system. (x86_64-pc-linux-gnu-c++-4.7.3)

# ? Oct 2, 2013 22:40

AlexG: Jul 15, 2004; If you can't solve a problem with gaffer tape, it's probably insoluble anyway.

hooah posted:

Result is -8.8796093704934495e+043.

The line that declares and initializes pi_18 is what the professor gave us. What's going wrong?

This value is what you get if you calculate pi as a long double (80-bit "extended precision"), but then truncate to the first eight bytes and interpret them as a double (64-bit "double precision") - the bits are the same.

So it looks like the acos is working correctly, but something is wrong with the printing. If you say "cout << static_cast<int>(pi_18) << endl;", do you get 3? If so, then everything is working well up to the point where the iostream library chooses the wrong type.

# ? Oct 3, 2013 19:37

hooah: Feb 6, 2006; WTF?

AlexG posted:

This value is what you get if you calculate pi as a long double (80-bit "extended precision"), but then truncate to the first eight bytes and interpret them as a double (64-bit "double precision") - the bits are the same.

So it looks like the acos is working correctly, but something is wrong with the printing. If you say "cout << static_cast<int>(pi_18) << endl;", do you get 3? If so, then everything is working well up to the point where the iostream library chooses the wrong type.

Yup, that prints out 3. What's the next step in figuring out what's going on, then?

# ? Oct 3, 2013 21:52

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

Read my edited post. long double is just broken in MinGW, and in VC too if you really need 18-digit precision.

Gazpacho fucked around with this message at 23:24 on Oct 3, 2013

# ? Oct 3, 2013 23:18

Jinx: Sep 9, 2001; Violence and Bloodshed

I'm having a goof around with templates and I am having trouble with template template functors:

code:

template <template <typename T, typename = std::allocator<T>> class C>
struct UserToUserId
{
    UserToUserId(DB2DBI & db, std::insert_iterator< C<UInt32> > & inserter) :
        db(db), inserter(inserter) {}

    void operator()(const std::string & username) {
        inserter = db.getUserID(username);
    }

private:
    DB2DBI & db;
    std::insert_iterator< C<UInt32> > & inserter;
};

int main() {
     std::vector<UInt32> all_users;
     std::insert_iterator< std::vector<UInt32> > userid_inserter(all_users, all_users.begin());
     UserToUserId<std::vector> userid_gen( db, userid_inserter );
     std::for_each( json_decoder.for_users().begin(), json_decoder.for_users().end(), all_users.begin(), userid_gen);
}

I'm getting a compile error with the template template functor and std::copy:

code:

/.../main.cpp: In function �int main(int, char**)�:
/.../main.cpp:76:123: error: no matching function for call to �for_each(std::vector<std::basic_string<char> >::const_iterator, std::vector<std::basic_string<char> >::const_iterator, std::vector<unsigned int>::iterator, UserToUserId<std::vector>&)�
/.../main.cpp:76:123: note: candidate is:
/usr/include/c++/4.6/bits/stl_algo.h:4373:5: note: template<class _IIter, class _Funct> _Funct std::for_each(_IIter, _IIter, _Funct)
make[2]: *** [.../CMakeFiles/loadTestData.dir/main.cpp.o] Error 1
make[1]: *** [.../CMakeFiles/loadTestData.dir/all] Error 2

I'd rather use a lambda but I can't. So perhaps my understanding of templates is too shallow, but doesn't "template <typename T, typename = std::allocator<T>> class C" define a proper type at compile time when it gets to figuring out the type for "class _Funct" in std::copy?

EDIT: This is what happens when you're doing 5 things at once. std::copy requires both iterator types to be the same type - duh. You can't copy a std::vector<std::string> into a std::vector<unsigned int>. You can all laugh at me now.

EDIT EDIT: Why was I taking about std::copy when I was using std::foreach? :iiam:

Sigh, fixed the dumb error. It's been a long day and I'm going home.

Jinx fucked around with this message at 02:48 on Oct 4, 2013

# ? Oct 4, 2013 02:25

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Does anybody know any VS2010 tricks for changing how a data type is represented in the debugger? I am using a big decimal data type so all I see are its built-in exponent and mantissa fields. These are pretty well useless on-the-fly. Can I get VS2010 to display them as their actual quantities?

# ? Oct 5, 2013 17:24

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Rocko Bonaparte posted:

Does anybody know any VS2010 tricks for changing how a data type is represented in the debugger? I am using a big decimal data type so all I see are its built-in exponent and mantissa fields. These are pretty well useless on-the-fly. Can I get VS2010 to display them as their actual quantities?

As far as I know, autoexp.dat is the only built-in option and it's really limited (i.e. it can't handle type casts either). NatVis in 2012 appears to be a lot more flexible.

The closest thing to a good option in 2010 is store the debug value with the data and omit that behavior in release builds.

# ? Oct 5, 2013 19:19

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

http://www.virtualdub.org/blog/pivot/entry.php?id=120
http://www.virtualdub.org/blog/pivot/entry.php?id=172

I think this is still basically accurate for 2010.

# ? Oct 5, 2013 22:46

Dog Jones: Nov 4, 2005; by FactsAreUseless

Say I've got a class:

code:

class MyClass
{
	vector<int> MyVec;

public:
	const vector<int>& GetMyVec() const { return MyVec; }
};

Meaning, I want people to be able to look at MyVec's value without changing it.

Later on, I write:

code:

MyClass mine; 
vector<int>& refint = mine.GetMyVec();

With intel's compiler, this produces a warning:

code:

warning #476: qualifiers dropped in binding reference of type ...

And that's it. I can then go on to modify MyVec's contents. Why is this just a warning? Shouldn't this be invalid? How do you actually keep people from modifying MyVec?

# ? Oct 6, 2013 18:27

GeneralZod: May 28, 2003; Kneel before Zod!; Grimey Drawer

Dog Jones posted:

And that's it. I can then go on to modify MyVec's contents. Why is this just a warning? Shouldn't this be invalid? How do you actually keep people from modifying MyVec?

For what it's worth, g++ gives an error:

code:

error: invalid initialisation of reference of type 'std::vector<int>&' from expression of type 'const std::vector<int>'

# ? Oct 6, 2013 19:55

Dog Jones: Nov 4, 2005; by FactsAreUseless

GeneralZod posted:

For what it's worth, g++ gives an error:

code:

error: invalid initialisation of reference of type 'std::vector<int>&' from expression of type 'const std::vector<int>'

This is exactly what I'd expect. Intel's documentation says my compiler conforms to the 1998 standard, but I can't find a copy of that. My intuition says that the program I posted before is invalid, and should report an error not just a warning.

# ? Oct 6, 2013 20:10

Qwertycoatl: Dec 31, 2008

Dog Jones posted:

This is exactly what I'd expect. Intel's documentation says my compiler conforms to the 1998 standard, but I can't find a copy of that. My intuition says that the program I posted before is invalid, and should report an error not just a warning.

The standard is pretty forgiving about what a compiler is allowed to do with invalid programs. I believe it's required to emit a diagnostic message, which it did. Beyond that, I don't think there's any requirement that the compiler ever refuse to compile something.

In any case const more or less runs on an honour system in C++. Even if you can't do it implicitly, you can get rid of the const pretty simply:

code:

vector<int>& refint = const_cast<vector<int>&>(mine.GetMyVec());

Qwertycoatl fucked around with this message at 21:47 on Oct 6, 2013

# ? Oct 6, 2013 21:43

VulpesInculta: Jul 11, 2012

I'm working through K&R, still on Chapter 1 and this is the program I've put in:

code:

#include <stdio.h>

/* count characters in input; 2nd version */
main()
{
    double nc;
    for (nc = 0; getchar() != EOF; ++nc)
        ;
    printf("%.0f\n", nc);
}

When I compile this with GCC and run it in the terminal it will take input, but it never actually prints out any sort of count - I assume this is because while it is still running it never reaches the end of file. How do I get it to hit EOF so that I can actually check for myself that the code is doing what it's supposed to?

# ? Oct 6, 2013 23:16

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Ctrl-D

# ? Oct 6, 2013 23:18

VulpesInculta: Jul 11, 2012

Plorkyeran posted:

Ctrl-D

Perfect - thanks for the speedy reply.

# ? Oct 6, 2013 23:20

VulpesInculta: Jul 11, 2012

I've continued on and got stuck on Exercise 1-12 which asks to write a program to prints the output one word per line.

code:

#include <stdio.h>

main()
{
    int c;

    while ((c = getchar()) != EOF){
      
        if (c == '\n' || ' ' || '\t')
            putchar('\n');            
        else
            putchar(c);
              
    }
}

The result is that I get as many newlines as characters in my input. I can't figure out why this is happening - why does it seem the first if clause is triggering for every character (not just \n, ' ', and \t) when it appears that they should skip the first if and go to the else clause and just be printed as normal?

# ? Oct 7, 2013 02:12

Nippashish: Nov 2, 2005; Let me see you dance!

VulpesInculta posted:

The result is that I get as many newlines as characters in my input. I can't figure out why this is happening - why does it seem the first if clause is triggering for every character (not just \n, ' ', and \t) when it appears that they should skip the first if and go to the else clause and just be printed as normal?

This: c == '\n' || ' ' || '\t' doesn't do what you think it does. It evaluates like ((c == '\n') || ' ') || '\t' which is always going to be true. You need to write c == '\n' || c == ' ' || c == '\t' to get what you want.

# ? Oct 7, 2013 02:33

Precambrian Video Games: Aug 19, 2002

VulpesInculta posted:

if (c == '\n' || ' ' || '\t')

You need to review operator precedence (that's for C++ but C is probably similar.

(c == '\n' || ' ' || '\t') is not at all the same thing as if ((c == '\n') || (c == ' ') || (c == '\t')), although the inner brackets are optional. What do you think the result would be if you wrote (c == 1 || 2 || 3)?

^^Also, nuts to you^^

# ? Oct 7, 2013 02:34

VulpesInculta: Jul 11, 2012

Nippashish posted:

This: c == '\n' || ' ' || '\t' doesn't do what you think it does. It evaluates like ((c == '\n') || ' ') || '\t' which is always going to be true. You need to write c == '\n' || c == ' ' || c == '\t' to get what you want.

eXXon posted:

You need to review operator precedence (that's for C++ but C is probably similar.

(c == '\n' || ' ' || '\t') is not at all the same thing as if ((c == '\n') || (c == ' ') || (c == '\t')), although the inner brackets are optional. What do you think the result would be if you wrote (c == 1 || 2 || 3)?

^^Also, nuts to you^^

Gah! Don't believe I missed that. It's working now exactly as intended. Thanks for the help.

# ? Oct 7, 2013 04:10

Scaevolus: Apr 16, 2007

eXXon posted:

(c == '\n' || ' ' || '\t') is not at all the same thing as if ((c == '\n') || (c == ' ') || (c == '\t')), although the inner brackets are optional. What do you think the result would be if you wrote (c == 1 || 2 || 3)?

I wish more languages supported something equivalent to it-- very commonly if statements want to check a value against a few different options. Python has things like if x in (1, 2, 3), but that's not the same semantics as the ==/or combination.

It's especially frustrating when you're testing the value of some long variable in a namespace.

# ? Oct 7, 2013 05:53

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

As long as operator precedence is being mentioned, two things to always be aware of lest you run into frustrating bugs: | and & are much higher priority than arithmetic operators (i.e. they're above comparisons), and && and || aren't the same priority.

# ? Oct 7, 2013 05:58

Nippashish: Nov 2, 2005; Let me see you dance!

Operator precedence is an important thing to be aware of, but it was not the source of confusion in this case.

# ? Oct 7, 2013 06:02

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Scaevolus posted:

Python has things like if x in (1, 2, 3), but that's not the same semantics as the ==/or combination.

Of course it is. in checks for equality, not identity.

# ? Oct 7, 2013 06:08

Adbot: ADBOT LOVES YOU

# ? Jun 9, 2024 02:14

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Suspicious Dish posted:

Of course it is. in checks for equality, not identity.

in also evaluates all the arguments, whereas a == b || a == c || ... won't evaluate the later options if an earlier one turns out to be sufficient.

# ? Oct 7, 2013 12:47

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›641 »