14
LostEth0
68d

I can not fuckin stress how goddamn annoying it is to work with strings in C++. I'm not talking about std::string, those are bearable. But fucking char foo[number], char* foo, and const char* foo. AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Comments
  • 9
    That's C strings - which are uncommon in idiomatic C++.
  • 2
    @Fast-Nop Was trying to loosely work with a book, and was gonna have a std::string in a union, which threw an error, so I tried char foo[256] but no, "incompatible types of char[256] and char". Not sure what the write approach is :P
  • 9
    Those are better referred to as character arrays.
  • 5
    @LostEth0 Unions are also rare in C++ because one of their main usage scenarios in C is type punning through unions - but that's undefined behaviour in C++.

    In general, just stick to the STL in C++ and drill down if and only if you can't avoid it. Especially because std::string is much easier to handle with regard to avoiding buffer overflows than raw C strings.
  • 2
    @Fast-Nop Ah alright, thanks! Probably should take what a book called "C++ crash course: A fast paced introduction" says with salt, given that its 700+ pages. :^)
  • 0
    Also tagging @RememberMe whom I regard as a C++ guru here. :-)
  • 4
    Why do you think an array even makes sense in a union?

    However, learn the C-Core. Especially working with char arrays. Yes, std::string is convenient, but also a giant monster.
    Know when to conveniently use it, and when to use core functions. Hint: if you have to really process many strings, and speed matters, give std::string a wide birth.

    Same with the other standard containers. If you need their bells and whistles, go ahead. But if you just want to chain a bunch of structs together for later, linear, processing, learn how to whip up your own singly linked list.

    Any serious C++ developer should have at least scanned "Mastering Algorithms with C" (ISBN 1565924533)
  • 2
    @Yamakuzure Will def check it out, I'm trying to get into C++ for game development with a background in interpreted languages (Lua, Python, JS in particular). I only know a little bit of C, and that was from modifying a de compilation of Pokemon Emerald and making games for the Ti-84+CE.
  • 2
    @Yamakuzure Linked lists and performance don't mix well these days because linked lists trash cache locality, which tends to dominate the whole thing.
  • 2
    Ahh I feel you! Learning C is often not the easiest of things given how you can just grab stdlib from C++. Trust me though, you will really benefit from learning it properly!

    I'm in the fortunate position of having had one of the best lecturers I know as our C/C++ teacher and we had to learn all the basic C memory management as part of our course. It seemed useless as hell but the more I learned the more I realised how well it fits in the bigger picture of C++ and generally writing a performant code.

    Don't give up, strive for knowledge and you'll appreciate it!
  • 0
    @LostEth0 it’s a nice book, I always recommend books by that publisher
  • 1
    @Gorlami Learning C helped me understand programming concepts I couldn’t understand, it’s given me perspective of how spoiled we are with languages that handle a lot of stuff for us like Java, C#, and Python, and even though I don’t like C++ as much I think people could potentially learn some of the same lessons with C++ to a degree
  • 0
    @Fast-Nop au contraire! Imagine a parsing thread organizing its findings by chaining them together, then passing the pointer to the root element to another thread processing it. ;-)
  • 1
    @Yamakuzure The read access would be so slow that it would negate any performance benefit of linked lists. Vector is likely to have better performance if it can be used at all. Plus that you can of course give a reference to the vector to another thread, you don't have to copy it around.

    Stroustrup gave a nice talk on that already several years ago: https://youtube.com/watch/...
  • 1
    @Bubbles I couldn't ++ your reply enough (:
  • 0
    @Gorlami thank you! I’m glad I’m not alone with all that
  • 1
    @Fast-Nop lol, I'm sure @Yamakuzure has forgotten more about C++ than I'll ever know

    In any case @LostEth0 afaik C++11 and onwards should allow you to use std::string in a union, but there are a ton of rules about it (also it's usually a terrible idea). The standard goes on and on about deleted members and braced initializers and placement new, but essentially it's nontrivial.

    std::string is a complex object which manages its own construction and destruction, whereas a union is a way to look at the same data in different ways. If you union a string with say an int, the compiler can't figure out how and when to call std::string's ctors and dtors and member functions because it doesn't know what exactly the object is because C/C++ union objects don't carry type information along with them. You could use a library like boost::variant instead, but I'd still not recommend it.

    Put a pointer to the data in the union if you want, that's much nicer because pointers are Plain Old Data.
  • 1
    @RememberMe Plus that the correct STL types are usually fast enough. Also, if one incurs the higher language complexity of C++, then the very least should be getting rid of the memory handling headaches from C as not to combine the worst of both worlds.
  • 1
    @Fast-Nop agreed, and STL containers implement move semantics etc. as well which a lot of self-made containers tend to forget or do improperly.

    Agreed, it's pointless writing C++ without using its higher level features (that said, it's usually fine and/or necessary to have some parts written C-style and then packaged into C++ style).

    Honestly these days I find myself using Rust more and more, I love the ecosystem and libraries, the language is a pleasure to work with (that is, when you aren't bashing heads with the borrow checker), and it's as low level as C/C++ so about as fast and efficient. Embedded Rust is pretty nice too, though low level hardware manipulation is unsafe (i.e. without guarantees i.e. C-like) out of necessity.
Add Comment