Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[alway]

Unless you need to worry about alignment... both malloc and new don't handle that at all, which is total crap.

There are custom-allocator versions of both make_shared (allocate_shared) and make_unique (surprisingly, allocate_unique) which are far superior if you really need fine control over allocation (e.g. using a pool). But if you don't have to write it, why bother? delete/free don't know how you allocated the object, and so can go disastrously wrong at deallocation time. The smart pointers track that too. Use smart pointers, get less bugs. Win!

No.

If you need to worry about alignment, you're doing something so close to the hardware you don't care about getting your hands dirty. And most likely, your data type will be raw u8 or u32. You then either do a static allocation (in which case there are things to align that) or you use malloc and a manual alignment offset into it. Why?
https://stackoverflow.com/questions/3628081/shared-ptr-horrible-speed
http://seanmiddleditch.com/dangers-of-stdshared_ptr/
That's why.

[miauw62]

I ask for help to find tutorials and I get warnings not to do things and I don't even know what those things are ;_;

[Thief^]

If you need to worry about alignment, you're doing something so close to the hardware you don't care about getting your hands dirty. And most likely, your data type will be raw u8 or u32. You then either do a static allocation (in which case there are things to align that) or you use malloc and a manual alignment offset into it. Why?
https://stackoverflow.com/questions/3628081/shared-ptr-horrible-speed
http://seanmiddleditch.com/dangers-of-stdshared_ptr/
That's why.

That stackoverflow thing is mostly totally misusing shared_ptr. shared_ptr is for shared ownership of something, and shouldn't be used anywhere that is merely referencing something owned by someone else. No wonder they saw poor performance. For temporarily referencing an object you should use a reference to the object itself (i.e. T& / const T&), not a copy of its owning pointer.

As for malloc with a manual alignment offset... That's a crap way to do it. It wastes massive amounts of memory! Tell me, how much extra memory do you have to ask malloc for if you want to align to 16 bytes afterwards (typical for SSE2, for example)? If the allocation it returns is already 16-byte aligned, how much have you just wasted? How much have you wasted if it returns memory with an 8-byte offset from 16-byte aligned? (hint, it's the same number) There's a reason most C libs provide an aligned_malloc.
You don't have to be writing SSE2 code yourself to hit these problems, they crop up all the time when simply using a math library which happens to have an SSE2 implementation. No need to be writing bare-metal code, ordinary users can be hit by this.

On the other hand, what if you are only allocating 1-byte aligned data (e.g. ascii/utf-8 strings)? The C malloc typically returns 8-byte aligned results, so will be rounding that up to the nearest multiple of 8, wasting up to 7 bytes per allocation. That's just crap.

[Thief^]

I ask for help to find tutorials and I get warnings not to do things and I don't even know what those things are ;_;

What language(s) do you know? If you know something similar enough then you'll just need a cheat sheet, otherwise you'd likely be better off with the java option. It's a much easier language to learn quickly.

[miauw62]

I am decent with Python and have dabbled a bit in C#. Usually I code in some semi-esoteric language because that's what SS13 is written in and nobody wants to port 350k lines of sewage. Python should be close enough, though.

[Thief^]

Well first, C++ is a curly braces language like C#. if() {}, for() {}, etc work like they do in C#.
Second, C++ is a typed language, so (like C#) you need to put the type of things everywhere. "auto" can help here if you don't care that much about the type, it works like C#'s "var".
Third, unlike C# and python, by default variables and instances of classes in C++ are values, where they are references in C# and python. This is where C++ gets more difficult, but also much more flexible, than any other OO language. To learn more, I recommend you find a tutorial on "dynamic memory allocation in C++", new/delete being the old way (and what you'll most likely find taught) and make_unique/make_shared being the new (which most things teach as a new thing at the end (if at all) rather than teaching them before new/delete and relegating new/delete to the advanced section at the end where they belong).

[EnigmaticHat]

In regards to the values/references issue, is it like python where you have access to both options and the tutorials don't tell you?

[Rose]

No, the tutorials make it pretty clear.
Everything can be accessed either as a value, or as a reference, and the tutorials tell you how to do that.

[alway]

If you need to worry about alignment, you're doing something so close to the hardware you don't care about getting your hands dirty. And most likely, your data type will be raw u8 or u32. You then either do a static allocation (in which case there are things to align that) or you use malloc and a manual alignment offset into it. Why?
https://stackoverflow.com/questions/3628081/shared-ptr-horrible-speed
http://seanmiddleditch.com/dangers-of-stdshared_ptr/
That's why.

That stackoverflow thing is mostly totally misusing shared_ptr. shared_ptr is for shared ownership of something, and shouldn't be used anywhere that is merely referencing something owned by someone else. No wonder they saw poor performance. For temporarily referencing an object you should use a reference to the object itself (i.e. T& / const T&), not a copy of its owning pointer.

As for malloc with a manual alignment offset... That's a crap way to do it. It wastes massive amounts of memory! Tell me, how much extra memory do you have to ask malloc for if you want to align to 16 bytes afterwards (typical for SSE2, for example)? If the allocation it returns is already 16-byte aligned, how much have you just wasted? How much have you wasted if it returns memory with an 8-byte offset from 16-byte aligned? (hint, it's the same number) There's a reason most C libs provide an aligned_malloc.
You don't have to be writing SSE2 code yourself to hit these problems, they crop up all the time when simply using a math library which happens to have an SSE2 implementation. No need to be writing bare-metal code, ordinary users can be hit by this.

On the other hand, what if you are only allocating 1-byte aligned data (e.g. ascii/utf-8 strings)? The C malloc typically returns 8-byte aligned results, so will be rounding that up to the nearest multiple of 8, wasting up to 7 bytes per allocation. That's just crap.

You seem to think magic happens when you can't see what code is doing. Things don't just happen magically on a computer, even if you like to pretend they do; and pretending they do is not a valid reason to justify any argument.

Every implementation of it does that same thing, whether it's a raw c malloc or a shared ptr.
Want proof? Just google for aligned allocation source code. You will find them all doing the same thing under the hood.
Every. Single. One.

In fact, without looking at the implementation, I would bet even make_shared is doing it.

With looking at its implementation, I got through half a dozen layers of code more abstract than a book of zen koans, whose purpose I suspect is to help the compiler seek enlightenment in the midst of the burning rubble which was once your performance.... At which point I gave up because holy crap, allocating a few extra bits is the least of your worries there.

And therein lies the problem. You don't know what you're talking about there. Those Nifty Programmer Tricks^tm have an underlying behavior hidden behind 10 layers of abstraction and caked on manure. And yet, you talk about it like it's superior without actually knowing what it is doing. If you don't know what it is actually doing under the hood, you can't even begin to talk about cost or performance. And that reason alone is precisely why Nifty Programmer Tricks are more or less banned in a lot of actual workplace environments, and basically anywhere that performance and stability are important. And same goes double for the boost lib from whence it came.

[Thief^]

burning rubble which was once your performance...

Once again you claim shared_ptr is slow... If its slow you're using it wrong - it's no slower than implementing shared ownership (i.e. reference counting) yourself! If you always have one single defined owner at any point, you use unique_ptr instead, which has precisely zero performance and memory overhead over a raw pointer, but saves you the pitfalls of having to call delete yourself. Failing to call delete or free are together pretty much entirely responsible for all the memory leaks in people's C/C++ code, which is why the advice now is to never use them.

If you don't believe me, Bjarne Stroustrup himself (creator of C++) says never use raw pointers for ownership and delete, instead always use handles (smart pointers) http://www.slideshare.net/mobile/complementverb/bjarne-stroustrup-the-essence-of-c-with-examples-in-c84-c98-c11-and-c14
http://channel9.msdn.com/Events/GoingNative/2013/Opening-Keynote-Bjarne-Stroustrup

[alway]

There is no one way to use C++. However, if you want performance, you do things the data oriented way. It is the way you maximize performance specifically because it focuses on what is actually being done and how to ensure that reflects the capability of the system. Also from CppCon, and more in line with the zeitgeist of how performance-critical application developers think about it:
https://www.youtube.com/watch?v=rX0ItVEVjHc

Even the new graphics APIs are moving in that direction. More unsafe, lower level, and all because that's how you get performance.

[Thief^]

We were talking about the general case, specifically I was originally on about what new coders should be taught. I firmly believe "new/delete" should not be the first C++ thing that gets taught (generally C++ courses seem to start with C-style this is a variable, this is a function, and then suddenly this is new/delete), as generally speaking manual memory management is hard, and even professional software is full of memiry leaks and stale pointer bugs.

Data oriented design is beautiful when doing heavy data processing, but you wouldn't include that in lesson 7 of "learn C++" either.

[alway]

On the contrary, most of it I would. Dispelling the notion that magic stuff exists under the floorboards is largely a good thing, and will clarify the most important question for learning anything: "why?"

Want to know how a std::vector works? Well, now we need several pages of documents, an explanation of how arrays work, and so on. And you will need the help of all the gods if you want to explain why, when, and how it breaks with pointers into them to a new programmer.
Yeah, it works great and does exactly what you wanted. Up until the point it doesn't because you aren't OCD enough to read and memorize every miniscule detail of the docs. At which point you face non-trivial bugs caused by a mismatch of expectations and reality.

What is stored in a variable? A value. What is stored in a pointer? A value. Both are just data; you can even print out the pointer's number. So what's a pointer? It's just a fancy street address. Still just a value. What's an array? Just a street address of the first house, and some other number which tells you how many houses in a row there are. Dereference a pointer and you go to the street address and take a look at the house directly. You can also build a house. When you build a house, you write down the street address for where you built it. If you lose that street address, now nobody knows where the house is. But if somebody comes along and decides they want to build some houses, they won't be able to build at that address, since there's already a house there. And so you should tear down your house (or at least sell the lot) before forgetting you own something there, or the town fills up with vacant rundown houses.

Two or more people own a home together? Introduce timeshare or similar analogies and you're set to continue in this vein. Simple concepts, without the need for anything more than layman's understanding of the every day. Likewise, which you mention bugs as being a big problem with this, I would turn it around and say they're the biggest benefit. You can name the types of bugs because they are consistently similar. Likewise, relatively trivial automation and tool environments can detect them, and any experienced dev can diagnose and correct them immediately. The same can not be said for bugs or errors involving internally complex and abstract high-level structures. Any day of the week, I would rather debug a trivial out of bounds or leak bug over a crash 10 functions deep in STL triggered by a similarly trivial but now obfuscated change to data fed into a more complex system.

[Gentlefish]

On the contrary, most of it I would. Dispelling the notion that magic stuff exists under the floorboards is largely a good thing, and will clarify the most important question for learning anything: "why?"

Want to know how a std::vector works? Well, now we need several pages of documents, an explanation of how arrays work, and so on. And you will need the help of all the gods if you want to explain why, when, and how it breaks with pointers into them to a new programmer.
Yeah, it works great and does exactly what you wanted. Up until the point it doesn't because you aren't OCD enough to read and memorize every miniscule detail of the docs. At which point you face non-trivial bugs caused by a mismatch of expectations and reality.

What is stored in a variable? A value. What is stored in a pointer? A value. Both are just data; you can even print out the pointer's number. So what's a pointer? It's just a fancy street address. Still just a value. What's an array? Just a street address of the first house, and some other number which tells you how many houses in a row there are. Dereference a pointer and you go to the street address and take a look at the house directly. You can also build a house. When you build a house, you write down the street address for where you built it. If you lose that street address, now nobody knows where the house is. But if somebody comes along and decides they want to build some houses, they won't be able to build at that address, since there's already a house there. And so you should tear down your house (or at least sell the lot) before forgetting you own something there, or the town fills up with vacant rundown houses.

Two or more people own a home together? Introduce timeshare or similar analogies and you're set to continue in this vein. Simple concepts, without the need for anything more than layman's understanding of the every day. Likewise, which you mention bugs as being a big problem with this, I would turn it around and say they're the biggest benefit. You can name the types of bugs because they are consistently similar. Likewise, relatively trivial automation and tool environments can detect them, and any experienced dev can diagnose and correct them immediately. The same can not be said for bugs or errors involving internally complex and abstract high-level structures. Any day of the week, I would rather debug a trivial out of bounds or leak bug over a crash 10 functions deep in STL triggered by a similarly trivial but now obfuscated change to data fed into a more complex system.

This is why I liked my data structures class. We had to build out own linked lists/trees/hashtables/heaps on our own without relying on outside libraries.

Bugs galore? You bet. But now I know how all of that works, and it's okay for me to wrap it all up in neat little helper functions and classes and be okay because I know how they handle memory. Forget to move a pointer around? Whoops!

Heh. Another reason I like programming in a linux environment. When running one of my lab assignments, a Binary Search Tree used to store a database of movies sorted by year, when I ran it on my windows machine after compiling, the thing just hung without printing anything, and the code::blocks debugger was zero help.

Soon as I ported the source to linux, recompiled, and oh holy shit, a memory dump, thank you based OS. I was able to track the bug down the second it crashed because it actually gave me something.

[MorleyDev]

Honestly, learning C++ is difficult. You can start from lower principles (C-like), but then you risk introducing and encouraging them to stay with the inherent complexity.

Personally, this is how I learnt. Spent a bit of time with QuickBASIC to get the basic ideas of loops and the like down (would recommend something more modern, Python maybe, for that now). Would I recommend it? Don't know, I've seen it go wrong and I've seen starting at the higher level go wrong. Starting at a higher level is easier, but may risk producing more worse programmers. Or may not, I'm not sure and ask me on a different day I'll probably give a different answer.

For C++, you need to know how new and delete work, and you need to learn not to use new or delete. You can't do that without first feeling the pain of new and delete, otherwise you won't appreciate the 'why of things', and that's a dangerous attitude.

C++ by it's nature gives itself the tools to build the higher level concepts like shared_ptr, unique_ptr, list and vector, rather than baking them into the core of the language itself. Greatest strength and greatest weakness of the language.

Feeling the pain of an approach is an important thing for a programmer to do, especially in a language like C++. That pain shapes decisions, informs how they use the language and moulds the structure of the code. To teach a programmer, you must allow them to feel the pain, and guide them towards finding ways to alleviate that pain.