Is it a good idea to ban methods in c++?

>pointers
Use containers and/or smart pointers, manual memory management is a source of many bugs.
>unsigned
My dude, the only data types (other than those in STL) you should know are "auto", "int", "size_t" and "bool" when you can't write "auto" instead of "bool".

you should specify uint64_t or whatever instead of unsigned

if you wanna write auto everywhere and guess whatever the type is, why not use python?

What containers? I'm making the container.

>why not use python?
Speed, dipshit.

Nah, you should write size_t. In 10 years we'll be using 68 bit processors and you'll go fuck yourself with your deprecated uint64_t crap all over the place.
I don't guess what the type is, I literally don't care what the type is when I read code, it's a visual clutter that decreases readability and forces me to concentrate not on the logic but on the plumbing. If I need to, I hover my mouse over whatever function call result was assigned to "const auto&" and I'll find out the type in 125 ms it takes for my IDE to look it up.

You're banned from bitwise operations in your code.

Bitwise operations won't pass my code review, grandpa. There is no reason to use them anywhere. Use std::bitset if there is some weird-ass exotic reason for you to have a bit field.

Good thing you're not writing my code, then. I use bit-packing extensively.

>hover my mouse
Deprecated.

People like you are why PUBG runs badly.

are you saying someone's suddenly gonna change uint64_t contra something as ambiguous as integer? you need to get your head checked

Guys I know you're having a nice convo and all but I'd like a concrete answer.

>ban methods
>methods
They're called functions you dirty java monkey.

Are you using move semantics? If yes, sure, go ahead. If no, I don't see why you'd bother.

I'm not using move semantics. I just don't see the reason of having all this functionality when it's outside the intended use of the class.

Are you making raw data packets to send over the wire?
Call me when std::bitset will show in profiler output. It's all nothing compared to what happens during some tree walking or texture copying or whatever. PUBG uses one of the most technologically superior engines, most likely their graphics engineers fucked up, picked bad materials and did not optimize meshes very well.
Nope, I mean, I'll have to spend 10 seconds wondering why the hell do we even have uint64_t instead of auto/int/size_t for no reason at all. Should it be 64 bit, is it a big number? Is it a size of something, then why it's not size_t? It's a timestamp? Why it's not size_t as in "count of pixels"? Should I replace it with something else for consistency, can it break things if I do?

Bitset set is as fast as bitwise operation. Why don't you guys trust STL? Have you see the STL codes? It's the most elegent C++.

You've got an answer. It's a normal common practice to remove constructors if they will break the contract of immutability, non-copyableness non-movingness or non-default-constructiveness or whatever. It is a good idea, sublime bugs become compiler errors.

I'm afraid. My lecturer scolded me last time saying it sucks to forbid functionality and that a good API aids the user in whatever he wants to do.
I mean, I could ask him, but he gets pissed off often.

>Are you making raw data packets to send over the wire?
No, I'm piping compressed data to shaders.

>Nope, I mean, I'll have to spend 10 seconds wondering
Enforce better commenting.

deleted copy, without move constructor
#include
struct Post {
Post(const Post&) = delete;
};
int main() {
std::vector x;
x.push_back({});
}

# g++ test.cc
...etc
/usr/include/c++/8.1.0/ext/new_allocator.h:136:4: error: use of deleted function ‘Post::Post(const Post&)’
{ ::new((void *)__p) _Up(std::forward(__args)...); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...etc

deleted copy with move constructor
#include
struct Post {
Post(const Post&) = delete;
Post(Post&&) = default;
};
int main() {
std::vector x;
x.push_back({});
}

g++ test.cc # compiles fine

I don't get it, I'm asking a philosophical question.

You think your lecturer is some arbiter of valid usage? That's literally the reason explicit deletion of functions exist. Ask him if it's better to have the compiler generate a bunch of shit you don't need.

>arbiter of valid usage
He writes grades, his word is final. He explicitly said "the moment you have pointers in a class, you must write the big 4".

The only reason I consistently see to delete copy constructors is if destructing the object twice would cause a double-free type error, most likely on a system resource.

>big 4
doesnt he mean rule of 5.

Default and copy constructors, operator=, and deconstructor?

You mean the rule of three? Just slap in some smart pointers.

What's a smart poiner and why do I need them?

google is your friend

en.cppreference.com/w/cpp/language/rule_of_three

>rule of three
>has 4 methods
Alrighty then

Your lecturer may be wrong. Your API is good, it doesn't allow its users to breach the contract. If it shouldn't be copyable, it should not be copyable. Be prepared to prove to your lecturer that it is indeed a non-copyable object and should never be default-constructed.
It's like making all function parameters const. You forbid the functionality to change the parameter, yes, but you forbid the ill and wrong practice of changing input parameters, so it's not something to cry about.
Piping compressed data is a perfect reason to mess with some bytes, I think. You know what you're doing and what you're doing affects performance in a dramatic way, since CPUGPU communication is slow. Review passed.
>Enforce better commenting.
Comments are needed only in exceptional cases, most of the time clean code is all you need.
>the big 4
The big three maybe? It can also be the big 5 if you care about moving.

>a non-copyable object
But it does makes sense to you guys, right? Why in the world would I want to straight copy/clone a post in my facebook ripoff? Makes no sense.
There is a requirement that every post can be "got" by another user via an HTML file, not straight handing over const Post&.

learncpp.com/cpp-tutorial/15-1-intro-to-smart-pointers-move-semantics/

It doesn't make much sense right now though, you won't be able to put your post in any container without emplacing. Add a move constructor at least.
You also won't be able to pass your post around different threads easily, being forced to share memory will lead to many fuckups.

Post* arrPost[10];
arrPost[0] = new TextPost("blablabla");
//etc

This is a crushed down version of what I intend to do - just manually add posts one by one.

I'd recommend not just solving the task but seeking the truth and learning how you would do the same in industry. In industry you'd do:
std::vector posts;
posts.emplace_back("blablabla");

Amen brother but my lecturer will literally assault me if he saw that.
"OH youre really smart huh, using vectors. What's a vector? Here, draw me its hierarchy. What are templates?" etc.

Thanks for the tip, but do you find my code or ideas insane, too?

>Why in the world would I want to straight copy/clone a post in my facebook ripoff?
This is implementation agnostic. If you have a Post type that's expensive to construct you'd much rather std::move() it to a vector instead of reconstructing it.

Are you taking a C course or a C++ course? Is your lecturer socially challenged with a hate-boner for the standard library?

If your lecturer is so picky, I'd recommend not trying to be a smart-ass, just solving the task in a way which will please your lecturer, while also doing it your own, proper, way, but not showing it to him. Or showing, but after you receive your grade, like "I've been playing with alternate solutions, what do you think?", it will improve your reputation and won't affect your grades.

It's not about expense, but logical approach.
Let's look at real facebook, it has a share button. It adds extra functionality to your post, it's not a direct copy paste with your name on it.

He's a strict Cguy but does excellent C++ (trains personnel of several big companies).
His approach is to teach the basics and let us handle and discover (the need) of the rest ourselves.
Right so have the functionality but just avoid using it in my own specific algorithms?

sounds like he wants you to use C, rather then C++

Your lecturer sounds like a jackass. Why does he have you using C++ if you're not supposed to be using the most basic standard library features?

It's amusing to think that you'd be assaulted for using a vector. Just implement everything as explicitly cast char arrays.

He does, he hates C++ (especially past C++11).
Thing is, I am taking c++ 101 with him for the third time now and I literally want to pass this fucking class. I am not good enough for C++ it seems, let alone C.

He probably knows what he's doing and you are trying to run ahead of the course. Just stick to your notes and solve the problems that he sets. You should pass the course and that's it, not to win the contest for the best architecture in C++ 101 class.

Just forget about your facebook, I'm talking about general C++ behavior. You'd rather move a pointer than allocate a heavy class like a string if possible. Something like this

Box::Box(const Box & other) {
this->p = new HeavyResource(*(other.p)) ; // costly copying
}

Box::Box(Box && other) {
this->p = other.p ; // trivial stealing, part 1
other.p = nullptr ; // trivial stealing, part 2
}

which is a simplification of what a smart pointer does

of what moving does* which you can also do with a smart pointer

That's some pretty code. I got tired of this this-> though, and moved to naming convention for mMembers. I hope one day I'll have to write mLady a lot and laugh internally every time I do.

you could use std::exchange for the second one.
Box::Box(Box && other) {
p = std::exchange(other.p, nullptr);
}

What the hell is (Box && other), address of the address?
God damnit what the hell is going on anymore?

I can just use pointers, right?

Sure, just an example I found to demonstrate it.

Rvalue ref.

It's all about safely managing pointers. If you have a Post object you don't want to re-create it, you just want to move it to the vector.

Rvalue reference. Objects that you don't care about right at that moment. Right-of-=-sign. Temporary ones, moved ones.
int i = 42
42 is "rvalue". It's on the right part of the assignment. You don't care about "42" itself, it's temporary and will be put into "i", which you care about, which is lvalue - left of an assignment.
std::move(obj) produces rvalue reference of obj, signifying that you don't care about obj anymore and rvalue-reference-receiver can gut its internals out during moving.

What a fucking mess, I give up. Obviously, I am missing programming experience. I'll take this course next year too.
Thanks for the help, guys.

Attached: Untitled.png (717x423, 38K)

Try designing the data flow before writing actual code. Why not have Post be a POD type?

CHECKED

I plan on adding a virtual function "makeHTMLfile" later on, at the least. Post also has three inheritor classes.

it's for rvalue optimatization

>Post also has three inheritor classes.
For what purpose?

Well, in case you want to upload a picture, some text, or a link.
I'm sure I've got classmates creeping around waiting to copy any ideas, so I'll keep the memory leak minimal lol.

What kind of c++ 101 is this. What is the task that you have to solve?

How does that work with multiple attachments?
Maybe try going for composition over inheritance. Maybe something really basic like
struct Attachment {
Type t;
Data d;
};

struct Post {
string text;
vector a;
};

Make ""Facebook"":
>class System with CLI functionality which contains users, moderators, and an Admin
>everyone can make or remove their own posts (mods and admins have extra privileges)
>posts can be text, link, or pictures
>posts must create HTML files when accessed by other users
Pretty much it, the whole thing works in command line.
They probably want to see our OOP skills, my man.

OOP is not inheritance, and composition isn't antithetical to it. You don't want to inherit just for the sake of it when it doesn't make sense conceptually. Don't use bad design patterns.

Attached: Capture.jpg (695x679, 79K)

If they want your OOP skills, make attachments their own type, like:
enum class Role {User, Moderator, Admin};
class User { Role role }
class Attachment {}
class Picture : public Attachment {}
class Link : public Attachment {} // links can have previews, it is not merely a text, it is an object!
class Post { std::string text, Attachment*[] }
class Facebook { Post*[], void post(Post*), void remove(Post*) { if user.role == User) throw "look at u hacker a pathetic creature of meat and bone"; ...}
It will be much more impressive than fucking with constructors.

It doesn't stick to specification, though, it states "posts can be text, link, or pictures", not "text with arbitrary amount of links and pictures".

I can't do virtual methods with composition, I think? But why is inheritance bad?
Great, but what if I do Post[2] = Post[3]?

Why do you need to use virtual functions? Is polymorphism a requirement?

neethack.com/2017/04/Why-inheritance-is-bad/

>Great, but what if I do Post[2] = Post[3]?
Will this question be asked by your lecturer?

Absolutely. My lecturer goes very in-depth with everything. Even as far as to remove a random method entirely and ask what, why, and how was broken.
It's not stated it is, but I really don't want to smartass my last chance.

>Is it a good idea to ban methods in c++?
write in c

Not nearly good enough lol

>using char* in C++
>using char* in an online app
>using char* for the user-facing part of an online app
heh