Xun posted:

Not sure if this is the right place to ask, but next semester I'm required to take Operating Systems, which uses C. I only know java and python and I'm shaky at C++ at best. I'm feeling super unprepared because so far my programming education have been a progression of Java -> Java/LISP(???) -> A tiny bit of assembly and some C++ -> C

What should I do? Should I take a C++ class next year (C isn't offered)? I'm not sure how to go about learning a more complex language like C on my own, most of the tutorials online seem to be basic programming stuff like ints and loops. I feel like I've been literally taught nothing.

Xeom posted:

code:

 classtype &thing2(int a, int b) const { do things; return *this; };

Here we add a low level constant that makes it so this function cannot edit the object.

Vanadium posted:

The bit with const in the middle just means that the function can be called on class instances that are themselves const, and that the this pointer inside the function body will be a pointer to const.

It's kinda weird that your member function is returning *this but also returning type int&.

nielsm posted:

This should fail to compile.

Inside the function, this is of type const classtype *, meaning that the type of *this will be const classtype. If you attempt to return a reference to that, the reference must of of type const classtype & because the object in question is const.

And it's not a "low level constant", you're declaring the function as being const.

PRADA SLUT posted:

In OSX, if I'm trying to .open a file on my desktop, what do I enter as the path? "Users/Me/Desktop/file.txt" isn't it.

PRADA SLUT posted:

One other question. I'm writing a program that has the user input the directory of a .txt file (string location) and then it parses the data and does something. It's supposed to kill the program if the user enters an incorrect directory.

code:

ifstream fin;
    fin.open(location.c_str());
    if (!fin)
    {
        cout << "Invalid file: " << location << "\n";
        return 1;
    }

Normally, when I run this part and enter an invalid anything, it ends the program. However, if I enter the character "a" or "/", it continues to run the program, even though it shouldn't be valid. Any idea why?

Xeom posted:

I am trying to understand some of the differences between the different constant types when defining a function in a class. Lets assume all this code is written within a class definition. Please let me know if I have misunderstood anything, I have a feeling I got something wrong.

code:

 classtype &thing1(int a, int b) { do things; return *this; };

Here we have a implied constant to this. That is the functions pointer will always point to the object that it was called with.

code:

 classtype &thing2(int a, int b) const { do things; return *this; };

Here we add a low level constant that makes it so this function cannot edit the object.

code:

const classtype &thing2(int a, int b) const { do things; return *this; };

This constant in front is just for having constant and non constant versions of you function.

Zopotantor posted:

Subjunctive posted:

Strict aliasing lets the compiler assume that pointers to different types are never the same object, so mutation of one can't affect what's seen of the other. For your read-only case, there's no ordering constraint that matters, so IMO you should be fine.

It seems like with some template magic (containing an inner union type) you should be able to make it work too?

Harik posted:

Well the problem is if I've hit UB who the gently caress knows what the compiler will do - if casting results in UB then the actual pointer assignment could be elided leading to not a segfault on embedded because there is no zero-page, so I just end up reading/writing from IO registers bad things happening

As far as a union that's also problematic since the serial code is shared so I'd have to either teach it every structure type in on gigantic union or have each subsystem pass-in a buffer/union with the types it knows about, etc.

Actually, how the hell do you write malloc() without strict-aliasing warnings? Does the pass through void* clear them?

Edit: Oh, it's firing the warning on my code because char[] != char *, and as such isn't exempted from strict-aliasing rules. If I add the pointer and a malloc the warning goes away - but does the danger? Am I reading the standard right that the compiler has to assume that type-punning a char * into a struct may alias?

Subjunctive posted:

(I'm not sure how the sockaddr parts of the sockets API can be used without tripping the UB technicalities here, similarly.)

C99, 6.5.2.3 posted:

One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them ... Two structures share a common initial sequence if corresponding members have compatible types ... for a sequence of one or more initial members.

Bonfire Lit posted:

There's a special exception for stuff like this, by use of unions.

Harik posted:

Yeah, it sucks that a copy of a 32 byte structure is something you need to worry about. On a real machine I'd just memcpy to a struct on the stack and call it a day.

Bonfire Lit posted:

That's right. But that exception allows you to turn a sockaddr_in (or sockaddr_in6 or whatever) into a sockaddr to pass to bind(2), via a union. bind then can (legally) inspect the sa_family member to figure out what kind of object the sockaddr* it got actually is, and is allowed to cast to that back to its original type.
^{But I'm not a compiler writer so I might be interpreting the standard incorrectly.}

pseudorandom name posted:

There's a compiler extension called transparent unions that makes this work, standard C doesn't allow it.

Otto Skorzeny posted:

e: and when you look at the gen'd asm, you see that the actual call to memcpy will get elided in most cases where you're using it for type punning

ISO/IEC 9899:1999 Technical Corrigendum 3 posted:

15. Page 073, 6.5.2.3
Attach a new footnote to the words "named member" in paragraph 3:
*) If the member used to access the contents of a union object is not the same as the member last used to store
a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning"). This might
be a trap representation.

PiCroft posted:

My theory is that it is trying to demonstrate where in memory an object member lies relative to where the object itself lies, so in the case of A, the pointer to the object itself and the pointer to the member m_x within it both point to the same space in memory and thus subtracting one from the other gives 0. This is my theory though, I'd appreciate it if someone could tell me if I'm right.

Skuto posted:

That's correct.

B demonstrates that replacing a var in a derived class hides it but the original var still exists, so the ptr is offset for the second var.

C has a virtual function, so there is a vtable in its instances and it sits before the vars.

PiCroft posted:

I'm looking for some help with some c++ code.

I'm brushing up on my pointer arithmetic and I was pointed to this site: http://www.interqiew.com/tests?type=cpp to get some good questions to test myself. I arrived at the following question however, and I have no idea whats going on:

code:

#include <cstddef>
#include <iostream>

class A
{
public:
    A() : m_x(0) { }

public:
    static ptrdiff_t member_offset(const A &a)
    {
        const char *p = reinterpret_cast<const char*>(&a);
        const char *q = reinterpret_cast<const char*>(&a.m_x);

        return q - p;
    }

private:
    int m_x;
};

class B
    : public A
{
public:
    B() : m_x('a') { }

public:
    static int m_n;

public:
    static ptrdiff_t member_offset(const B &b)
    {
        const char *p = reinterpret_cast<const char*>(&b);
        const char *q = reinterpret_cast<const char*>(&b.m_x);

        return q - p;
    }

private:
    char m_x;
};

int B::m_n = 1;

class C
{
public:
    C() : m_x(0) { }
    virtual ~C() { }

public:
    static ptrdiff_t member_offset(const C &c)
    {
        const char *p = reinterpret_cast<const char*>(&c);
        const char *q = reinterpret_cast<const char*>(&c.m_x);

        return q - p;
    }

private:
    int m_x;
};

int main()
{
    A a;
    B b;
    C c;
    std::cout << ((A::member_offset(a) == 0) ? 0 : 1);
    std::cout << ((B::member_offset(b) == 0) ? 0 : 2);
    std::cout << ((A::member_offset(b) == 0) ? 0 : 3);
    std::cout << ((C::member_offset(c) == 0) ? 0 : 4);
    std::cout << std::endl;

    return 0;
}

I can get access to the answer but thats not good enough, I'd like to know what is happening. For example, I can see that in Class A, its creating a couple of char* pointers, one to the A object thats passed in and one for the m_x variable it contains. I don't know how to interpret what is going on though. My theory is that it is trying to demonstrate where in memory an object member lies relative to where the object itself lies, so in the case of A, the pointer to the object itself and the pointer to the member m_x within it both point to the same space in memory and thus subtracting one from the other gives 0. This is my theory though, I'd appreciate it if someone could tell me if I'm right.

The output at the end is 0204 for the record,

PiCroft posted:

So I take it that static int m_n in B doesn't actually take up memory for a B object? I read that a static member variable is a special case because being static makes it a class-level object and not strictly speaking a part of the instance-level object, so a static int in B wouldn't count for memory purposes.

Otto Skorzeny posted:

What uC are you working with where memcpy doesn't work? I do it all day long on Cortex-M and Freescale S08.

e: and when you look at the gen'd asm, you see that the actual call to memcpy will get elided in most cases where you're using it for type punning

Harik posted:

You misunderstand - memcpy works just fine, but I've only got 128/256 bytes of RAM depending on the part, so I'm trying to use the data in-place in the receive buffer rather than using more RAM to make a copy.

As for your edit: How does the memcpy legally get elided? If I push a structure on the stack and memcpy to it, the compiler will just skip that whole bit and alias the structure to the buffer? That seems problematic.

quote:

code:

uint64_t c5 (const uint16_t *buf)
{
  uint64_t num;
  memcpy(&num, buf, 8);
  return num;
}

Again, although we might expect that adding a function call would make the code harder to optimize, both compilers understand memcpy deeply enough that we get the desired object code:

code:

c5:
        movq    (%rdi), %rax
        ret

rjmccall posted:

Fourth, memcpys of small constant size are extremely likely to be turned into the obvious load/store sequence; I would not stress about it unless you are using a terrible custom embedded compiler (which probably does not implement type-based aliasing optimizations anyway).

rjmccall posted:

aliasing discussion

Otto Skorzeny posted:

Cf. http://blog.regehr.org/archives/959