crt
i changed the virtual funcs into generic functions on the deriving 2d renderer
crt
but when i do a cast from the renderer base class pointer to the 2d renderer it gives the same error
Nils
struct inotify_event *thisevent = malloc(event_size);
for (;;) {
// Read next event
read(notifier_fd, thisevent, event_size);
// Log event to file
write(log_fd, thisevent->name, thisevent->len);
write(log_fd, ",\n", 2);
}
I am trying to use inotify, but thisevent->name ends up being always empty and thisevent->len being 0. Any idea?
Dima
why not just sizeof(struct inotify_event) ?
Dima
for allocation
Nils
struct inotify_event {
int wd; /* Watch descriptor */
uint32_t mask; /* Mask describing event */
uint32_t cookie; /* Unique cookie associating related
events (for rename(2)) */
uint32_t len; /* Size of name field */
char name[]; /* Optional null-terminated name */
};
Dima
oh, didn’t notice
Nils
oh, didn’t notice
It also seems like the watcher does notice all events, so something must be deeply faulty
Anonymous
Anonymous
how can I get a random number then?
seed std::mt19937 or std::mt19937_64 by following this https://stackoverflow.com/questions/45069219/how-to-succinctly-portably-and-thoroughly-seed-the-mt19937-prng. then use the engine to generate random numbers through the various random number distribution functions.
see <random> header details in cppreference
Anonymous
for a basic program like the one you are doing, just seeding it with an std::random_device should be fine. that will be the equivalent of using srand(time) followed by rand() in C in terms of complexity
Anonymous
Oohhh!
I get it, thanks
Anonymous
how can I get a random number then?
so,
std::mt19937 eng(std::random_device{}()); <- remember that this is bad for anything other than the most basic experiments
then pass this engine to your function as a reference.
in the function do
int generate_random_int(int RANDOM_NUMBER_MAX, std::mt19937 &eng) {
static std::uniform_int_distribution idist(1, RANDOM_NUMBER_MAX);
return idist(eng);
}
Anonymous
MᏫᎻᎯᎷᎷᎬᎠ
Why do they say C is faster than C++?
Is it true?!
What C++ really lacks?
Anonymous
AFAIK C++ has more things than C that a lot of people considers bloat
Anonymous
Why do they say C is faster than C++?
Is it true?!
What C++ really lacks?
C++ strives for 0 cost abstractions. but there are often some costs
MᏫᎻᎯᎷᎷᎬᎠ
AFAIK C++ has more things than C that a lot of people considers bloat
Bloats comes from programmers bad code
It's just a matter of don't overuse templates, don't do this, do that....etc
MᏫᎻᎯᎷᎷᎬᎠ
C++ strives for 0 cost abstractions. but there are often some costs
Some costs like what exactly?!
Anmol
Why do they say C is faster than C++?
Is it true?!
What C++ really lacks?
C code is like raw C++ code without any wrappers and checks. These things add up and hence C++ is kinda slower than C
vinícius*
those are not zero-cost
vinícius*
exactly, you don't. that's why it's not zero cost
Anonymous
I would say that it'll be even more fast in C++ since compilers can devirtualize some calls
Anonymous
exactly, you don't. that's why it's not zero cost
You do not understand what "cost" mean
Anonymous
🤔
vinícius*
zero cost doesn't mean "it's zero cost in equivalent C"
vinícius*
it means it's an abstraction layer with no runtime penalty
vinícius*
virtual functions are not zero-cost because they create a pointer lookup in a vtable and indirect jumps that cannot be branch-predicted
Anonymous
ye i'm not telling him to use std::random_device
vinícius*
I get what you're saying, but your definition of "zero-cost" isn't what people commonly refer to zero-cost, such as when Stroustrup talks about it
Anonymous
;-; "<- remember that this is bad for anything other than the most basic experiments"
and i also provided the SO link with all the methods for initialising
vinícius*
zero-cost is about abstractions that cost nothing
vinícius*
classes are zero-cost because they're effectively eliminated at runtime
vinícius*
please look "zero cost abstractions" up on Google
MᏫᎻᎯᎷᎷᎬᎠ
virtual methods, for example
Well I'm sure if you do the same work that virtual methods do it as a workaround in C, it will be more or equal in term of cost
So you just take as a shortcut programming principal the same way that templates saves you from writing the same code more than once
vinícius*
Well I'm sure if you do the same work that virtual methods do it as a workaround in C, it will be more or equal in term of cost
So you just take as a shortcut programming principal the same way that templates saves you from writing the same code more than once
yeah, it will be equivalent and have taken you a lot more time to implement
MᏫᎻᎯᎷᎷᎬᎠ
exactly, you don't. that's why it's not zero cost
Btw
There is a constexpr virtual methods in C++20
+ Yes exactly, I'd rather have a choice whether to do it or not, instead of restricted one way
vinícius*
the only big reason to still use C on non-embedded projects is interoperability
MᏫᎻᎯᎷᎷᎬᎠ
it means it's an abstraction layer with no runtime penalty
I really want to have a reliable definition of abstraction layer term
vinícius*
the only big reason to still use C on non-embedded projects is interoperability
such as in CPython, they mostly use C because FFI'ing into C is easy
vinícius*
I agree, but virtual methods are still costly abstractions. These two things don't negate each other.
vinícius*
wikipedia is not allowed? huh
Anonymous
you joined recently
MᏫᎻᎯᎷᎷᎬᎠ
So, can we confidently say that C++ is equal to C in terms of performance?!
And sometimes faster because it offers more paradigms that reduces the extra checks that the developer has to write In C?
vinícius*
even in the case where a C program is faster than its (correct) C++ equivalent, the C version would have taken a lot more time to implement
vinícius*
so all in all C++ is just more worth it
MᏫᎻᎯᎷᎷᎬᎠ
What are the other cases be like?
vinícius*
yeah because C++ is a "you pay for what you get" language, as Stroustrup defined it. Virtual methods are just an example of an abstraction where you'd have a small performance hit, but only iiif you decide to use them
vinícius*
What are the other cases be like?
an advantage to C is that its binaries are usually smaller
vinícius*
plus it runs virtually anywhere
MᏫᎻᎯᎷᎷᎬᎠ
You know that std:: variant can replace polymorphism entirely except the area of extendablity
MᏫᎻᎯᎷᎷᎬᎠ
an advantage to C is that its binaries are usually smaller
Why it's smaller than C++?!🤔
Didn't we agree that C++ has zero-cost abstraction?
MᏫᎻᎯᎷᎷᎬᎠ
But It's a zero cost abstraction
I would pay a zero overhead as stated before
MᏫᎻᎯᎷᎷᎬᎠ
Yeah C is still everywhere
But we are talking about performance
vinícius*
Why it's smaller than C++?!🤔
Didn't we agree that C++ has zero-cost abstraction?
Sure, but that relates to performance, not binary size. C++'s STL is filled with inline template classes, which are usually copy-pasted several times during compilation to increase performance, but at the cost of having slightly larger binary sizes.
MᏫᎻᎯᎷᎷᎬᎠ
A + B = C that's C++
It's the same equivalent to:
A + B + D + E = C which in C language
You can't use Just A in C++ it only offers A + B with the same performance results in C language
BUT: In C language you can just use A for its purpose
MᏫᎻᎯᎷᎷᎬᎠ
:D
vinícius*
me neither
MᏫᎻᎯᎷᎷᎬᎠ
Your logic in equation language
vinícius*
are the letters... abstractions?
MᏫᎻᎯᎷᎷᎬᎠ
It doesn't matter
What matters I understood you
MᏫᎻᎯᎷᎷᎬᎠ
I got my answer
Thank you both guys
MᏫᎻᎯᎷᎷᎬᎠ
Yeah I was a such a nerve xD
MᏫᎻᎯᎷᎷᎬᎠ
MᏫᎻᎯᎷᎷᎬᎠ
Wait
It's the same assembly code, isn't it?
MᏫᎻᎯᎷᎷᎬᎠ
I mean
No matter what C++ is what it offers extends to C
It will be just compiled to some native assembly code that both C and C++ can generate, am I wrong?
vinícius*
they don't (usually) generate the same ASM but what Madhu means is a problem that happens during compilation, not after
vinícius*
C++ is traditionally dynamically linked, which means it reads its standard library from somewhere else in the system
vinícius*
and C++'s standard library is not as common to find as one of C's several libc implementations
vinícius*
C is most often dynamically linked