Calling C++ Autists

Learning C++ after programming extensively in Python, Ruby and Java for the past couple of years. I want to know, is it really worth it to use arrays and manually manage the allocation/deallocation of memory like in pic related when resizing arrays rather than just using Vectors?

Other urls found in this thread:

python.org/dev/peps/pep-0008/
en.wikipedia.org/wiki/Haiku_(operating_system)
github.com/haiku/haiku/tree/master/src/system/kernel
gist.github.com/bkaradzic/2e39896bc7d8c34e042b
youtube.com/watch?v=xnqTKD8uD64
twitter.com/NSFWRedditImage

I can't read that shit.
Write it in C instead.

You wanna use modern C++? Use vectors and std::arrays.

On a side note, use smart pointers.

No, it isn't worth it. That's pretty obvious -- where are you learning c++ from that's telling you to do this?

Vectors you stupid fuck
It's literally why they were made.

Use vectors. You can change the allocator function for any stl container, look up the doc. You shouldn't really need to change that tho unless you have very specific needs.
Also use smart pointer when performance are not important because they WILL be slower than regular pointers, just don't be stupid.

You're literally doing C++ the worst way possible.

This also validates my entire perception that Python, and other lazy languages like it (including Java) teach bad habits.

It just resizes an array given (p) by the amount of new_space, can make it bigger with positive number or smaller with negative number

How so? If anything learning python, java and other languages would encourage me to immediately use vectors instead of what I posted, I want to understand how to manually manage memory and resize arrays to my needs where I couldn't do that in java or python.

this x10

You should definitely be using std::vector.

Vectors are almost certainly more performant than what you did.

>Also mfw not using stroustrup brackets

No. Stop.

Learn how do to it for educational purposes, but if you ever deploy unsafe, broken-ass code like that, we will hunt you down.

This kind of shit is why we have so many security issues and buggy-ass, unmaintainable code. Just because you can do something doesn't mean you should. That broken shit was kept for legacy reasons.

That's funny, because it's written in like 95% C.
Not only is it mostly all C syntax (minus the reference, bool, and new/delete statements), but it is typical C style code.

You just suck.

>because they WILL be slower than regular pointers
Partially wrong.
std::unique_ptr has no overhead whatsoever compared to raw pointers.

Meanwhile in C
arr=realloc(newsize);

>Doesn't call the objects copy/move constructors to move the data
>Just does a dumb bitwise copy
Trash.

No.

The standard library is the holy Grail. It is the hot shit. The people who wrote it are gods. We all bow before their magnificent coding skills.

Always use it whenever possible if you want to write maintainable code. The compiler will see that shit and optimize the shit outta that shit.

It has some overhead faggot. You first need to get() it and then dereference it. It's slower than raw pointers

>objects
Trash.

Man you are going to feel real silly in a couple of years when quantum computers make functional programming worthless.

Your post (and education course) is why it's dangerous to teach writing software from high-level Python -> C/C++. I guess schools do it because it's easy for them to teach it, but you come out with a substandard knowledge of programming.

The short answer is forget everything you learned about Python, Ruby and Java, if that's even possible. Then you can start to build the groundwork and learn something that isn't just a new language, but at this point learning C++ should be considered a new paradigm, much like functional programming is different from imperative programming.

An adequate education should be learning programming from machine code -> assembly -> C/C++, and then branch off into desired language routes.

Also, I really fucking hate Python for this reason:
python.org/dev/peps/pep-0008/
>Use 4 spaces per indentation level.
Or your Python doesn't fucking run. Fuck Python forever

It's inlined you fucking retard. It gets optimized to the exact same code as a raw pointer dereference.
There is literally no overhead at all.

The code for get() is basically something like this, literally:
T *get() {
return ptr;
}

And since it's a template in a header, it's always inlined and optimized away.

>what is inlining optimization
You're an idiot.

What is the overhead of shared_ptr?

Quantum computers are more fit for functional programming than regular computers.

Well, on creation, it has to allocate a control block (can be allocated in the same block as the object if you use std::make_shared)
On calling the copy constructor, it has to increment the ref count in the control block.
And on calling the destructor, it has to decrement the ref count in the control block, and if the ref count is zero afterwards, destroy the object and the control block.

Not much, but still some.

But de-referencing it should come at no cost, right? If so, there is literally no reason to ever use raw pointers again.

If you're using C++, you should be using the STL's vector class. If you are rolling your own vector, it should be either for an educational purpose, or because for some reason, you need a feature not available in std::vector.

>you need a feature not available in std::vector.
If only there was this concept called inheritance.

I'm a third year CS student and I don't know how to write a associative container. Fucking std::map.

>extending STL classes
STL is not made for OOP, it's a fucking compile time optimized static polymorphism wasteland. Inheriting these classes will leak memory because they don't have virtual destructors.

We learned that first year in Java...

>But de-referencing it should come at no cost, right?
Not that I know of, but yeah, probably.

Or if you're making a kernel and don't have an STL.

I've heard a lot of dev teams roll their own replacements for STL (especially stuff like std::string or the godawful std::map), because it's much more performant that way. STL is not good quality.

Just use vectors unless you're dealing with something performance critical (and remember, your code isn't "performance critical" unless your program ends up being too slow to meet its design goals AND profiling shows that slowness originates in your vector-related code). Basically, there's little to no justification for using C-style arrays (with the exception of string literals, which are basically unavoidable) in C++ code unless you're trying to fix a known performance issue. You have a standard library, you might as well use it.

Most times you simply don't need it. C++, simply by generating native code, already gives you a considerable performance advantage over Java or Python, even using the standard abstractions. Only go low-level if you actually need to, i.e. if the program can't do its job otherwise.

You wouldn't be using C++ in a kernel anyways.

Do it if you run into performance or reliability issues, or if you have nothing better to do with your time, but it should really take a back seat to application logic. Unless of course the actual project being developed is a better container library.

That is nothing but a dumb meme.

Name one good kernel written in C++.

>en.wikipedia.org/wiki/Haiku_(operating_system)
>Haiku is written in C++

>github.com/haiku/haiku/tree/master/src/system/kernel

>cpp files everywhere

That is a dumb argument.
You're saying that because Linux isn't written in C++, then no one should ever use C++ in a kernel.
The only reason Linux is written in C is because Linus is a C fanboy who hates C++.

About the only thing in C++ that is unfit for kernel development is exceptions and maybe RTTI, and they are in general shit anyway. Disable them.
Everything else is fine and does come in useful, such as RAII and templates.

NT is written in C as well. And XNU is as well. C++ is suitable for use in operating system code, but not in kernels specifically.

C++ is suitable, but there is no point in using it since the STL isn't available if you're writing for a kernel. What's the point?

>What's the point?
Write your own, it's not really that hard, and it's worth it.

>std::arrays
>smart pointers
y tho

Not at the same time. Basically just saying to use the standard libraries.

>objects in C

>Basically just saying to use the standard libraries.
Why though? I don't really see the reason to the standard library if you don't have to.

C has objects.
I'm not sure what you're on about.

C is for brainlets.

>, is it really worth it to use arrays and manually manage the allocation/deallocation of memory like in pic related
yes, disregard the children ITT

also if you can store everything on the stack

>also if you can store everything on the stack
You could store smart pointers on the stack and not manage memory yourself.

This is C++. The standard libraries are part of the language specification.

It's a matter of making efficient and maintainable code. The standard libraries are good. You should always use them unless you're absolutely sure they don't do what you want. Otherwise, you're just wasting your time.

Inheriting STL containers is not really a wise idea, particularly given that their member variables do not have a name defined by the standard. Using implementation-specific information would make your program cease to be portable. If you're just using the public methods, you might as well use composition over inheritance.

Well yes, obviously if you're working on a system without an STL, you would roll your own STL.

VxWorks was made in C++, and it seems to find itself used in a number of places.

I am trying to make a method that will convert from iso-8859 to utf, remove accents or other sorts of symbols that could be added(áüòŷ ->auoy) and also pass everything to lower. I've got this at the moment but it's not working properly.

string Class::isoToUtf(const string& str) const
{
string strOut = str;
for (std::string::iterator it=str.begin(); it != str.end(); ++it)
{
uint8_t ch = *it;
if(ch < 0x80) {
strOut.push_back(ch);
} else {
strOut.push_back(0xc0 | ch >> 6); // first byte, simplified since our range is only 8-bits
strOut.push_back(0x80 | (ch & 0x3f));
}
}
std::transform(strOut.begin(), strOut.end(), strOut.begin(), ::tolower);
return strOut;
}

Can any wizard help me out?

Use new[] while you're learning so you know what it does, but prefer vectors in general.
Similarly you should learn new, but you should stick to smart pointers in "real" code.

Well, except for streams.

>NULL instead of nullptr

Do you have to iterate through a string like that? can't you just use
for (auto& nigger : string) {

?

One can cherry-pick the good parts for kernel developement, like namespaces, operator overloading, move semantics and constexpr stuff. I certainly wouldn't want to see too much template stuff or any exceptions and rtti in kernel code.

You are copying str to strOut and then you're appending characters to that copy. You probably want to start with an empty strOut.
Your lower function won't work because utf-8 is a multibyte format and tolower can only work with a single byte.

As said you can do for (auto ch : str) {

>I certainly wouldn't want to see too much template stuff or any exceptions and rtti in kernel code.

But templates don't exist after compile, they just generate the relevant functions that you use

Once you make it work, consider making it working on streams instead of strings.

Templates lead to bloated executables. You don't want templates in the kernel for the same reason you don't want excessive inlining, it'll thrash your cache.

Sure, maybe they have their use in certain parts, but they have their drawbacks.
>Concepts are still not a thing
>Potentially bloat up code size if not used carefully
>Potentially blowing up compilation times if not used carefully
It's totally possible to use them right though.

I wish some whore would let me thrash her cache

Normally, you should use vectors unless memory is critical. Ideally, you want to double the allocated array size each time it gets overfilled (you never use more than twice what you need, and it asymptotically decreases the complexity of some algorithms). How vectors work behind the scenes is implementation-dependant, but I assume it does something similar.

If memory usage is critical then you probably know your requirements and all you need to do is sprinkle a few reserves and shrink_to_fits here and there.

You're both wrong - if memory is critical you should be working within fixed limits, discarding or queuing excess values.

Absolutely dependent on access patterns. But yeah, if you can right-size your vectors then you should.

That applies regardless of which container you use to store data.

Enjoy your shit performance. Right sizing your vector on construction: yes, thoughtlessly sprinkling reserves and shrink_to_fits: fuck no. These potentially need reallocation.

most online tutorials teach bad habits

>Right sizing your vector on construction
Sometimes you don't know how much memory you need. Sometimes it changes.

>thoughtlessly
Where'd you get that from?

>These potentially need reallocation
That's the fucking point. You get a reallocation when you request it, not on a random push_back call.

This. C++ is difficult to teach because it's difficult to learn. Writing it like C is wrong, writing it like Java is wrong, even writing it like C++98 is wrong.

gist.github.com/bkaradzic/2e39896bc7d8c34e042b

>Where'd you get that from?
Well, the word "sprinkling" somehow implicitly implies that. Like the statement "sprinkling mutexes in your code makes it thread-safe" sounds horribly wrong. Anyway, I don't want to argue on a word.

>That's the fucking point. You get a reallocation when you request it, not on a random push_back call.
Fair enough, that makes the point for reserve whenever you call push_back lots of times in a raw and you know the number. I don't know about shrink_to_fits though. Where would be a good place to put it?

*row

I'm OP, the code I posted in the pic is code I had to write for my summer programming course, we need to be able to understand how memory works, thats why I asked is this worth it or should I just do it to learn.

Also, which books do you recommend then for modern C++? I downloaded C++ primer to help my studies but it's kind of basic and doesn't help me much.

>Where would be a good place to put it?
When you want to discard half of a large vector and release memory without having to create a copy.
The standard doesn't guarantee that the memory will be released but every mainstream implementation will.

Yeah, but a usage pattern could be like this:
1. deleting half of the elements of the vector
2. pushing back the same number of elements.

These can happen at different places in your code. If at your first place you called shrink_to_fit and at the second place you call reserve then you pay the cost of two needless reallocations.

Point being, if your vector regularly changes size, but it's never too large then calling shrink_to_fit might not worth it.

>*&
what the fuck am I reading

The tools are there to solve a particular set of problems.
You're imagining scenarios where those problems happen to not exist. I don't see your point.

passes a pointer by reference

youtube.com/watch?v=xnqTKD8uD64
This is a really good talk and I think it sets some good style guides for general C++ application development. But you should be fairly familiar with the language before you listen, i.e. if you don't know what an rvalue reference is then it's not for you.