roomforthetuna posted:

pseudorandom name posted:

NULL in gcc is either ((void*)0) in C or __null in C++, neither of which will convert to an integer without warning because ints and pointers aren't the same size these days.

shrughes posted:

Not true, if you include the right header file NULL will be replaced by 0 in C++ and produce surprise behavior in certain situations.

Edit: Maybe I'm actually thinking of clang. But I think it's with gcc.

pseudorandom name posted:

I looked at both gcc's and clang's stddef.h before quoting what NULL is, it's ((void*)0) or __null. (Granted, they both have #define NULL 0 clauses for other compilers, but that isn't particularly relevant.)

I suspect you're referring to the plethora of headers from bad third-party libraries that unconditionally #undef and then redefine NULL to be ((void*)0), which does break when used from C++.

JasH posted:

Hiya,

I am toying a bit with C++ on my Raspberry Pi, but I am not yet very familiar with either...

I am currently building an application which communicates wirelessly (not WiFi) with an Arduino.
My idea was to have a C++ application looping on my rPi which handles the communication with my Arduino and have a CGI application (also in C++) which I can use to send commands from a webbrowser to the Arduino.

The problem I have is that I don't know how I can communicate from my CGI application to my looping C++ application.
The simplest solution would be to write my commands from the CGI application to a text file and have the C++ application check it, but I'd rather avoid this setup...

Any suggestions?

Jerry SanDisky posted:

Take a look here. In particular, you may be interested in Pipes or Domain Sockets.

nielsm posted:

For a graph like this to work you need to use references of some kind.

One way of doing this would be to make a Graph class that has "master lists" of all the nodes and edges. Each node and edge then only reference other nodes/edges by their index into the vectors of them contained in the Graph. Additionally, each node and edge could possibly contain a pointer back to the Graph object, but I don't think that's necessary.

Papes posted:

Yeah, I think you might be right on that. However I'm not sure I really follow your suggestion. Are you saying that the containers should be in the Graph class and everything should be referenced by container index?

seiken posted:

I have a (mathematical) vector class which stores its elements in an array. However it'd be nice if I could also access the elements with their common names (v.x, v.y, etc) when the vector is a small enough size.

My first try at a solution:

C++ code:

template<typename T, std::size_t N>
stuct vec_accessors {
  vec_accessors(T* elements) {}
};

template<typename T>
struct vec_accessors<T, 3> {
  vec_accessors(T* elements)
    : x(*elements)
    , y(*(1 + elements))
    , z(*(2 + elements))
  {}

  const T& x; const T& y; const T& z;
};

// ... and so on ...

template<typename T, std::size_t N>
class vec : vec_accessors<T, N> {
public:

  T elements[N];

  vec()
    : vec_accessors<T, N>(elements)
    , elements{0}
  {
  }

  // ...

};

This basically works; the problem is that if I make the references x, y etc non-const (so that I can mutate the vector through them), then I can even mutate a const vec through them since the const-ness doesn't propagate through references.

It's not the end of the world, I could always add functions and use v.x(), or just use the long names v.elements[0] for mutating, just wondering if there's a better way?

harvestsun posted:

C++ really doesn't handle const-ness in as complete of a fashion as I would like. One of my few gripes with the language. It's hard to do tricky stuff like this (unless I'm forgetting something obvious).

That Turkey Story posted:

What problem do you have with const? If you're talking about propagation, it's correct that const does not propagate with a pointer or reference. It wouldn't really make sense the other way around -- why would a const pointer imply that what it's pointing to is const?

harvestsun posted:

I've also run into situations with the opposite problem: I have some member variable which is being used internally (for performance optimization), which doesn't affect the object's state (as seen by external classes). But const-ness propagates to that variable, so I can't modify it from a const member function. I would like to able to say "this is something which DOESN'T affect the object's state", and have const-ness NOT propagate to that object...

That Turkey Story posted:

Don't do that thing you're doing with the references. That const issue is just one of a slew of problems. You're making the type larger and making accesses harder to optimize, both of which I would imagine you would like you avoid for something as low-level as a vector type. Just make named accessor functions. As for alternatives, a similar question came up a few pages back I think. What I personally do is I have empty types that I use as accessors, so I can do things like my_vector[x] = 5; or my_vector[right] = 5, where "x" and "right" are just instances of those empty types and the vector type has operator[] overloaded accordingly. Simple accessor functions is more concise and I would just recommend that unless you really want or need something else.

harvestsun posted:

You may have a point, but I think the argument could also be made that it doesn't make sense that, in this situation, he's able to modify a const structure.

harvestsun posted:

You could say "well he just has a badly designed class, it shouldn't be exposing a reference to its own data". But it would be NICE (in my opinion) if there was a way to distinguish between association and aggregation. To be able to say "this is a pointer to something that affects the object's state".

harvestsun posted:

I've also run into situations with the opposite problem: I have some member variable which is being used internally (for performance optimization), which doesn't affect the object's state (as seen by external classes). But const-ness propagates to that variable, so I can't modify it from a const member function. I would like to able to say "this is something which DOESN'T affect the object's state", and have const-ness NOT propagate to that object...

seiken posted:

Yeah, I knew it was gonna be bad for optimisation, but luckily you've come along with this v[x] idea that I really like. Thank you.

Edit: in case anyone else has this problem, this is what I came up with

That Turkey Story posted:

Something along those lines should be fine. Depending on whether or not you declare an explicit default constructor will affect your ability to do those declarations of x, y, and z in that manner, at least in a standard-compliant compiler (I think VC++ lets you get away with it).

Edit: There are technically potential ODR issues. If you're a pedant, the "correct" way to do the declaration of those x, y, and z names is either with externed variables or with references. It's probably unnecessary, though boost often does little dances for declaring objects like this. Here is how Boost.Units does it, for example (this macro is used for things like "meters" and "seconds" when you make a quantity like 5 * meters / second).

seiken posted:

Thanks for the ODR info, I've fixed that. I'm not sure what difference an explicit default constructor would make here, though. For the record I'm using gcc 4.7 with -Wall, which didn't seem to complain about either of the two things you pointed out.

decl.init paragraph 6 posted:

pre:

To default-initialize an object of type T means:
  — if T is a (possibly cv-qualified) class type (Clause 9), the default constructor for T is called (and the
initialization is ill-formed if T has no accessible default constructor);
  — if T is an array type, each element is default-initialized;
  — otherwise, no initialization is performed.

If a program calls for the default initialization of an object of a const-qualified type T, T shall be a class type
with a user-provided default constructor.

GrumpyDoctor posted:

That's what mutable is for.

harvestsun posted:

Can't believe I didn't know about mutable, that's exactly what I was looking for. You learn something every day... I gotta lurk here more often.

I have related question. Say I have a class Foo with some property bar which is only generated as needed (again, for performance). So I have an accessor function like so:

code:

Bar Foo::getBar() const {
    if (!generatedBar) {
        bar = generateBar();
    }
    return bar;
}

Would it be "correct" to declare bar as mutable, so I can modify it from within this function? Or is there a "better" way to get what I'm after?

scissorman posted:

I'm thinking of getting back into C++ after not using it for several years, therefore I'm looking for a good, up-to-date book on how to write C++ code.
I'm especially looking for advice on C++11 as well as the recommended programming style.
Are there any books you'd recommend?

shrughes posted:

What have you done with C++ so far? Are you relatively noobic? Would you benefit from reading Koenig & Moo (for pre-C++11 learnings)? To go from there into C++11 mostly involves looking at the Wikipedia C++11 page and being non-retarded.

scissorman posted:

How is Accelerated C++ compared to the The C++ Programming Language book?
I've still got an old edition of Stroustrup's book lying around and the new version is coming out soon, so I might get that instead.

Begall posted:

This is the file in question. My first question is, since these seem like basic syntax errors, why does it still compile fine against 3.6 and below? And secondly, since compiling seems to have failed purely due to this one file, is there anything I can do to fix it?

Plorkyeran posted:

std::optional was accepted for C++14

Vanadium posted:

Should I wait for the C++14 version of TC++PL?