Calling C++ Autists

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

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

On a side note, use smart pointers.

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

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

>>61346483
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.

>>61346483
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.

>>61346536
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

>>61346616
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.

>>61346547
this x10

>>61346483
You should definitely be using std::vector.

>>61346483
Vectors are almost certainly more performant than what you did.

>Also mfw not using stroustrup brackets

File: 1495574178170.png (371KB, 832x868px) Image search: [Google]

371KB, 832x868px

>>61346646
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.

>>61346536
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.

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

>>61346483
Meanwhile in C

arr=realloc(newsize);

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

File: 1497025152288.jpg (17KB, 540x304px) Image search: [Google]

17KB, 540x304px

>>61346609
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.

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

>>61346805
>objects
Trash.

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

>>61346646
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:
https://www.python.org/dev/peps/pep-0008/
>Use 4 spaces per indentation level.
Or your Python doesn't fucking run. Fuck Python forever

>>61346814
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.

>>61346814
>what is inlining optimization
You're an idiot.

>>61346765
What is the overhead of shared_ptr?

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

>>61346924
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.

>>61346984
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.

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

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

>>61347073
>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.

File: Slofox.gif (12KB, 400x491px) Image search: [Google]

12KB, 400x491px

>>61347083
We learned that first year in Java...

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

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

>>61347060
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.

>>61346483
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.

>>61346646
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.

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

>>61347197
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.

>>61347267
That is nothing but a dumb meme.

>>61347307
Name one good kernel written in C++.

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

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

>cpp files everywhere

>>61347315
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.

>>61347419
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.

>>61347583
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?

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

>>61346547
>std::arrays
>smart pointers
y tho

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

>>61346805
>objects in C

>>61348124
>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.

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

>>61346536
C is for brainlets.

>>61346483
>, 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

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

File: 1495965798627.jpg (238KB, 750x750px) Image search: [Google]

238KB, 750x750px

>>61348153
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.

>>61347073
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.

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

>>61347267
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?

>>61346483
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.

>>61347097
Well, except for streams.

>>61346483
>NULL instead of nullptr

>>61351958
Do you have to iterate through a string like that? can't you just use

for (auto& nigger : string) {

?

>>61347594
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.

>>61351958
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 >>61352056 said you can do

for (auto ch : str) {

File: ?????.jpg (100KB, 500x500px) Image search: [Google]

100KB, 500x500px

>>61352083
>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

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

>>61352100
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.

>>61352100
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.

File: bawling pepe.jpg (85KB, 580x563px) Image search: [Google]

85KB, 580x563px

>>61352128
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.

>>61352154
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.

>>61352154
>>61352184

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

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

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

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

>>61346616
most online tutorials teach bad habits

>>61352277
>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.

>>61352317
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.

>>61352428
https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b

>>61352355
>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?

>>61352444
*row

>>61352317
>>61352428
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, >>61352428 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.

File: msvc.png (8KB, 549x304px) Image search: [Google]

8KB, 549x304px

>>61352444
>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.

>>61352553
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.

>>61346483
>*&
what the fuck am I reading

>>61352604
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.

>>61352615
passes a pointer by reference

>>61352511
https://www.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.