C++ hate thread

Again, I'm not a C++ programmer, but that would clearly violate the strong typing of scoped enums. If you don't want the compiler to protect you from enum-related type errors, you could always switch to unscoped enums, or reap the benefits of both by using explicit casts where necessary. Or switch to Python :^)

Yeah it's annoying to write a templated from_enum or enum-indexed array every time you need to do a lot of that. Or other things like a templated array size function. There are a lot of little things that people keep rewriting that ought to be in the std lib. They finally added clamp in like C++17.

#include template constexpr auto to_underlying(E e) noexcept{ return static_cast(e);}
Works for all enums and all underlying types (requires C++14).

It wouldn't. I assume you're unfamiliar with the addition of enum base types. The base type /is/ now implicit when declaring a variable of that enum type, it's just not implicit as an rvalue. It's this weird, half-assed type.
In C++, the base type of a class can be used implicitly. E.g., this works without casting to Person *:
class Person {};class Faggot : public Person {};int main(int argc, char *argv[]) { Faggot f; Person *p = &f;}
But with these new enum class types, the base type of the enum class needs a cast. There's no legitimate reason why, or why they didn't provide a template to do the conversion since now everyone has to write their own.

Yes, but everyone now has to write their own special snowflake version of that template rather than use one from the STL. As I've been saying, they've failed in two different ways on what should have bee a simple fix.

I think you are conflating `base types` with `underlying integral types`. The latter does not entail type inheritance. What are you trying to do with your enum where this is actually a problem? The snippet you posted is obviously contrived to demonstrate your gripe, but I suspect you have object-oriented design issues if this is actually a pain point in a real project.

What are the best resources to learn C++ for a beginner?

Attached: serveimage.jpg (497x372, 18.16K)

The real code has messages of a wire protocol named by an enum and various data structures describing those messages as arrays that are indexed by the enum. Pretty basic stuff. It just uses regular enums rather than the usual big block of #define because I'd always hoped they'd make enums not shit someday. Fast forward about 10 years and they finally add base types, but they're only useful in the definition of the message types, not the structures indexed by the enum. I wanted to throw a shoe at Bjarne. While it's not some big showstopper, it's that they consistently half-ass and fuck up what should be the simplest additions, then it takes another 5-10 years for the fix.

This is not a use case for enum classes; arrays are indexed by integer. You are basically applying OOP to procedural code. You could make it a little more object-oriented by switching to a hashmap e.g. `unordered_map` and use the enum as the hash keys. You'll also need to provide a hashing function, since your enum is not a built-in. See: stackoverflow.com/a/24847480/159570 But you could go full-object-oriented by replacing your data structures with classes (if they aren't already) which share a basic template, then creating a factory which will instantiate the correct subclass depending on the enum it is given.

Actually you may not need it, if you're specifying the underlying integral type. not a C++ programmer as I said. Anyways I'd probably switch to the factory implementation.

I'm pretty new to C++ and programming in general but yesterday I did this by using a static_cast

Yes it is.
Pajeet, you would replace a flat array that can be O(1) indexed and stored in .rodata with a complicated combination of hashing and lists and constructors and dynamic allocations and hash functions that does the same thing but slower?

I would say this is a pretty solid argumentation.

Attached: niggers-created-cout.webm (1280x720, 810.14K)

You seem to want to dabble in OOP, so I gave you the recipe. But yes, I'm wasting my time with someone who doesn't know the difference between composition and inheritance. So stick to your basic enum, because you're not using enum you're using ints. Good luck with life.

I'm insulting you because you proposed switching a flat array to a hash and are defending that idiocy with it being "more OOP". You are the kind of person that got everyone thinking OOP = bloat.

You wanted to use `enum class` because its the new shiny thing, so I gave you a scenario where you could use said-shiny thing. It's an artifact of OOP. I should have instructed you to switch to basic enums when you demonstrated total ignorance with the phrase "enum base type".

You still have no idea what you're talking about. The problem with enums has always been that they were untyped (the implementation is free to choose any integral type that fits), and why people used #define blocks instead. Adding base types to enums gave them a type, but the compiler may only use it as the storage type for who knows what stupid reason. I can't "switch to basic enums" and still have a base type. That doesn't fucking work.

Projection, the post.

Modify the example in the OP with your ingenious solution.

I should probably add that it needs to show it used a specific integral type, since the OP code would be fine with any int.

Nigger, what makes you think I'll help you after speaking that way to me?

I know you can't write code, I'm just entertaining myself.

Coming from a guy who thinks a hash is complicated. Bruh

Compared to a flat array? Yes, Pajeet. It is.

You're embarrassing yourself by borrowing terms from this brainlet who is confused by basic type concepts.

Am I being kidded? Have you looked at gcc's unordered_map implementation? It's a dynamically allocated set of buckets containing dynamically allocated singly linked lists with dynamically allocated value pairs. Go read c++/6/tr1/hashtable.h, look for how they use _Node_allocator_type, _Bucket_allocator_type, and _Value_allocator_type.

A hash table is not interchangeable with an array.

I'm pretty sure the entire purpose of a "scoped" enum is to effectively treat an enum as a unique type ("strong typing") rather than an implicit int so you actually have to be forced to cast. It's an abstraction thing (e.g. you can't do an implicit cast between a "Color" enum and a "Direction" enum). As of C++11 you can declare an "unscoped" enum with a fixed underlying type (has nothing to do with inheritance), and all "unscoped" enums are implicitly castable to int. If you still want it to be confined to an actual scope you can put it in a namespace or a class or a struct or whatever.

#include #include enum foo: int8_t { //valid as of c++11 X, Y};namespace bar { enum aaa: long long { A, B, Y };}struct thats3as { enum aaa: unsigned long { H, J, Y, A = 4294967292 };};int main(int argc, char* argv[]) { int A = thats3as::A; //should bork std::cout

Why are you this retarded? Enum classes exist exactly to prevent implicit conversions, if you want them to do what you think they should do, just use a plain enum or a static_cast.

I don't need to read the implementation, it's O(1) insertion and retrieval, and given that you're writing a networked program, worrying about muh dynamic buckets is a useless micro-optimization.

I never said it was. But he's only using the array in parallel with the enum indices, which is a violation of the enum abstraction.

The history of enum:
- (C) enums are a loosely defined integral type and assign increasing values automatically
- (C++) enums can be strongly typed, have scope
- (C++11) enums can be even stronglyer typed, given a base integral type
That last one is the relatively recent addition I'm talking about, not the strong typing. They're still fixing type issues with it, C++17 fixes some of the brain damage with initialization not honoring the base type, but not what I'm calling out in the OP. Maybe in C++20..
It is actually meant to look like inheritance.
No, only those 'enum class' variants have a default base type of int, regular enums are still loosely defined. Example:
#include enum Foo { X = 2147483647};enum Foo64 { Y = 4294967296};int main() { Foo foo; Foo64 foo64; std::cout

You really do, as you're advocating something that will be easily 10 times slower, take 10 times more ram, have O(n) worst cases, require runtime initialization, and can throw.

Sepples + const correctness is gay

False.
So can array out of bounds lookups.
Completely ridiculous lmao

wew

...

See, it's exactly this kind of mentality that has created the modern mess modern software is.

...

All because a retard couldn't read cppreferences.com.
Just drop the fucking "class" from your code you absolutely cripplingly retarded pajeet. I tried to give you a google-able hint with my post but you had to drag out your retardation for ~45 more posts in this shitty thread for the whole world to see.

You don't even rise to the level of a StackOverflow negress. Fuck off from this entire website. You are not welcome back here.

I mean, look at this reply. What kind of MORONIC reply was that? Hur dur scope has nothing to do with it!

That's literally the NAME OF THE FUCKING CONCEPT YOU'RE USING! YOU DON'T EVEN KNOW THE NAME OF THE FUCKING CODE CONSTRUCT YOU'RE USING! That's how I know you're a copypasting pajeet that only codes by stealing code from stackoverflow and steals different pieces of code until things compile (but throw 900 warnings). NEVER COME BACK HERE FAGGOT!

I love how this place has no CoC, it's so liberating to vent my rage at incompetent fools like this. :)

ENUMS DON'T HAVE BASE TYPES, NIGGER
ENUMS DON'T HAVE BASE TYPES, NIGGER
ENUMS DON'T HAVE BASE TYPES, NIGGER
ENUMS DON'T HAVE BASE TYPES, NIGGER
ENUMS DON'T HAVE BASE TYPES, NIGGER
ENUMS DON'T HAVE BASE TYPES, NIGGER
ENUMS DON'T HAVE BASE TYPES, NIGGER
ENUMS DON'T HAVE BASE TYPES, NIGGER
ENUMS DON'T HAVE BASE TYPES, NIGGER
ENUMS DON'T HAVE BASE TYPES, NIGGER
ENUMS DON'T HAVE BASE TYPES, NIGGER
ENUMS DON'T HAVE BASE TYPES, NIGGER

No it's this mentality that made faggots use linked lists as default everywhere when a vector would be orders of magnitude faster and more memory efficient.

your a fukcing retrad
the WH OLE POINT of scoped enuns is ti oprevent this kind of fukup wher it silenly convers to othar thype

DUMB OP PRESON!

The issue isn't from scoping, it's from the base type extension to scoped enums in C++11. But don't let that stop your autismal tantrum.

...

fuck bjarne

...

It's a base type. You can retrieve it using std::underlying_type.

...

Enum has-an int
not
Enum is-an int

en.wikipedia.org/wiki/Object_composition
en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

I dunno? Why does C++ even exist?

We're wasting our time trying to civilize a streetshitter.

Streetshitter detected.

vtables are not a requirement to have a base type.
Indeed.

You're still wrong, and no amount of shitting in the streets will change that fact.

It's an "is an" relationship as in C++17 its list initialization honors the type, no cast or encapsulated member reference required. It's inconsistent as it implicitly acts as the type in initialization and declaration, but as an rvalue it acts as the enum type. There's no other type like this in C++, and even after the fixes in C++17 (proof that it was broken) it's still broken.

Check the size of a class with a base type that has no virtual methods. You'll see there's no vtable pointer. I'm never wrong, Pajeet. I am a white male and am superior in every way.

No, Tyrone. The compiler is just performing the conversion for you in that context.
en.cppreference.com/w/cpp/language/list_initialization

Attached: Capture.PNG (774x83, 10.75K)

Do you understand what you're saying? I know it's intended. I'm saying the inconsistency is stupid.
Thr current design doesn't make anyone happy as the "muh strong types" guys can initialize with any valid value of the base type with no cast (as if it was the base type) despite it not being a valid enum type, and the guys who want it to act as its base type when used are forced to cast and write their own templated wrapper on std::underlying_type (as if it was the enum type). It is the worst possible implementation they could have gone with.
While I'm sure they will eventually fix it, it will probably be a decade after they fucked it up. And that's not unusual for C++ at all.

Again, Enum has no base type. Underlying type != base type. Your obstinate refusal to use the correct words for concepts is contributing to your misunderstanding.
Enum never, ever inherits from its underlying type. 100% consistent. If you would sit down and actually learn the C++ type system, you'd recognize syntactic sugar for what it is, instead of this comical perception that objects are morphing in nature willy nilly.

I don't play word games.
Consistent with what? It's now completely unique in the type system, being the only type that acts as two different types depending on where it gets used. It is language gore. People have called this out as stupid and broken since C++11, Bjarne then went "hold my beer" and made it even worse in C++17. Now it's almost perfectly half-way between both paradigms, and can be initialized to an invalid type without even having to cast. And the helper function that everyone has to have to get any value out of it without Pajeetcoding is still missing from the standard.
"but the letter of the standard" is no defense against claims the standard is bad.

More like you're a stubborn child. Let's test that theory. Given that I've shown you two excerpts from the C++ reference docs demonstrating as such, do you accept that you were wrong about Enum is-an int, and that list initialization is not "honoring" that, but rather performing a conversion? Can we get on the same page here?

Because everything in C is broken and fucked up.
Exactly like C. C++ is just carrying on a tradition started by C and B.

I've always thought that if Lisp were a ball of mud, and APL a diamond, that C++ was a roll of razor wire.That comparison of Lisp and APL is due to Alan Perlis - heactually described APL as a crystal. (For those who haven'tseen the reasoning, it was Alan's comment on why everyoneseemed to be able to add to Lisp, while APL seemedremarkably stable: Adding to a crystal is very hard, becauseyou have to be consistent with all its symmetry andstructure. In general, if you add to a crystal, you get amess. On the other hand, if you add more mud to a ball ofmud, it's STILL a ball of mud.)To me, C is like a ball. Looked at from afar, it's nice andsmooth. If you come closer, though, you'll see littlecracks and crazes all through it.C++, on the other hand, is the C ball pumped full of toomuch (hot) air. The diameter has doubled, tripled, andmore. All those little cracks and crazes have now growninto gaping canyons. You wonder why the thing hasn't justexploded and blown away.BTW, Alan Perlis was at various times heard to say that(C|Unix) had set back the state of computer science by(10|15) years.

This works in D:

enum Foo : int { X }void main() { import std.stdio : writeln; int[] arr = [1,2,3]; writeln(arr[Foo.X]);}

New C++ features basically fucking steal from D and make them worse / less useful.

D has been outdated since std 11.

We're going in circles. Yes, I'm fully aware the standard has special-cased this and the letter of the law is being followed, what I've been saying is it's bad design and it doesn't need to be a special case and so nonsensical. The feature should have been designed to not be brain damaged like D's implementation seen in . It was shit in C++11 as the committee conceded but not fixed by their "fixes" in C++17.

c++ is shit but there's no better language /thread

Unfortunately, everyone knows this is the truth, but few will admit it.

what about AVAJ

That's right, Pajeet; enum classes are not integer. Thet's the point: not being able to accidentally pass an arbitrary int when a Foo is asked, and vice versa. Just do this: namespace Foo { enum : int { X}; }int main(int argc, char *argv[]) { return argv[Foo::X] == 0;} and the "problem" is solved.

Stubborn little baby boy. Please fuck off of this board.

fuck off and die pajeet