Pharap & Drummyfish's Ramblings


#1

Coincidentally I’ve seen this yesterday here

http://harmful.cat-v.org/software/c++/

Beware: heavy C++/OOP bashing :slight_smile:


Hobbits are good programmers (quotes and advice about programming)
#2

90% of this stuff sounds like it was written by people who haven’t actually bothered to learn the language,
which would be like me saying “I hate Ruby” when I’ve never even attempted a single Ruby tutorial.
(For the record, I don’t hate Ruby, that was just the only example I could think of that I don’t know the general syntax of.)

what is a protected abstract virtual base pure virtual private destructor – Tom Cargill

Ask a silly question, get a silly answer:

class BaseClass
{
private:
	// pure virtual private destructor
	virtual ~BaseClass(void) = 0;
};

// protected abstract virtual base
class ChildClass : protected virtual BaseClass
{

};

I’d like to point out that nobody in their right mind would write this because it’s completely useless, even if it was legal and even if it wasn’t undefined behaviour.

It’s clear that Mr. Cargill decided to just string a bunch of buzzwords together in an attempt to be intentionally ambiguous and confusing.
The proper way to name it would be “the pure virtual private destructor of an abstract base class with protected virtual inheritance”.

But like I say, nobody in their right mind would write one because it’s more useless than a quine.
Not all legal code has to be useful code.


I’ll admit to agreeing with this one:

All new features added to C++ are intended to fix previously new features added to C++ – David Jameson

C++ would be a much better language if it hadn’t tried to be compatible with C.
I lose count of the number of times I explain something about C++, the other person says “that’s stupid” and then I say “yes it is, C++ inherited that ‘feature’ from C” or “they can’t do anything about it without breaking backwards compatibility”.


#3

I agree, actually I just read this part and thought it couldn’t be genuine, so I googled and found it wasn’t :slight_smile: Definitely no hard facts, but some are pretty funny.

However it’s true a lot of top hackers have problems with C++, e.g. Torvalds and RMS. That says at least something.

But then there is the real world that says C++ is what we want to use.

So is C++ good or bad? Is OOP good or bad?

Definitely no single answer, it simply depends. The minimal working solution will always win my heart, so I like C better, but then again, I end up using C++ most of the times. But to me the mere existence of that huge number of scary sounding keywords leaves a bit of a bitter taste.

Example of my C++ struggle from the current project: I keep jumping between structs and classes. You know, I want to use classes, but for that simple game, you can use simple structs with public members as data carriers so that you don’t have to write tons of setters/getters. But then the struct grows and I feel like changing it to a class, or the other way around. Then suddenly I have a mess of half-encapsulations, I have to keep refactoring etc. It’s unfortunate that both of these exist in C++ when there’s no clear distinction between when to use A and when B.

But I know C++ will lead me to succesfully finish the project.

So the point is, I guess, it’s important to know there is no such thing as a silver bullet (a lot of people think OOP is one). It’s neither C nor C++. Always depends on the problem at hand.


#4

I think this is going to be my last post on this thread for a while because I’ve written a text wall and people are probably getting bored with this dialogue.
Plus the thread was originally supposed to be to highlight some helpful advice, and it’s gone off-piste a bit.


Torvalds’ most famous anti-C++ rant consists mainly of ad hominem attacks (not just on the language, but on the people that use it too) rather than rational reasons.
It’s clear that he really hates abstraction and object orientation.

A lot of his reasons for hating it seems to stem from the fact that it does some things ‘behind the scenes’ (e.g. calling constructors and destructors, managing vtables) and Torvalds seems to want everything in the open, even if it means being horribly verbose.
That’s the opposite of what most people want - most people would rather not have to worry about that.
In fact C++'s RAII principle (see also this) is founded on not having to worry about cleanup.

Ultimately though, the main issue is that he spends most of his time writing kernel code, so really his only options are assembly, C and C++, anything more substantial wouldn’t really be suitable.
The reason he doesn’t spend his time shouting at Python or Ruby is because nobody is daft enough to suggest writing the Linux kernel with them.


As for RMS, he stopped writing code in 2008 (by his own admission), which was pre C++11, so I’d argue that his complains are only valid for C++03 and C++98 code.

RMS even says “The flaws of C++, as I recall from when I studied the matter around 1990” and “I suspect that I would find plenty of ugliness in the template library, but I don’t know. That was added to C++ after I studied it.”.
So I think it’s safe to say his views are going to be a bit out-of-touch with modern C++.


A number of the keywords could be scrapped if it weren’t for backwards compatibility issues.
As of C++17, register is effectively meaningless.
bitand, bitor, compl, and, and_eq, or, or_eq, xor and xor_eq are all redundant on modern computers, but they’re kept for backwards compatability reasons.

To be honest, I’d rather have more keywords if it meant existing keywords having fewer meanings.
class has about 4 different meanings depending on the context because of historical reluctance to introduce new key words.

I can tell from the context that you’re meaning these two things as different concepts, but just in case you (or anyone else reading this) doesn’t know:
in C++ the struct keyword and the class keyword essentially do the same thing.
From the compiler’s point of view, the only difference between a class and a struct is that members of a class are private by default and members of a struct are public by default.

If you’re the only one working on it and it’s reasonably small, there’s no pressure to use getters and setters, you can just keep your member variables public.

The point of setters is to validate the value being assigned.
For example, in languages like Java and C#, a setter would be used to check that someone doesn’t try to assign a null reference to something that can’t be null.
(In C++ you don’t have to worry about that if you use references instead of pointers.)

Some people even believe that getters and setters are evil.
There’s no one right philosophy, but the important thing isn’t the ‘what’ it’s the ‘why’.
Whenever there’s a mantra about what you should be doing, a lot of people forget to remember the reason for doing it that way.

Personally when I write C++ code I tend to use a lot of getters, but hardly ever use setters.
I.e. a lot of my objects are either immutable, or the member variables are only altered by specific member functions.

Sometimes I’ll make the member variables public.
The most common case of this is when I write a mathematical object like a Point or a Vector.
Sometimes I just do it out of laziness/simplicity, like with RigidBody (applyForce is a good example of giving an object functionality instead of treating it like a bag of data).

Although I don’t completely agree with everything, one article I like for tearing down the ‘getters and setters’ paradigm is this article which illustrates two of the alternatives: immutable data injected at the constructor and ‘operational methods’ over setters.

It depends on the use case.
Sometimes

C++ isn’t alone in this though.
Take any OOP language that provides access modifiers and you have the same conundrum.
Java, C#,


While I think of it, I’d like to attack a common misconception people have when approaching OOP.
Many people when writing a game start by trying to make something like this:

class Entity
{
public:
	virtual void update(void);
	virtual void render(void);
};

And really I can’t blame them, because that’s what a lot of OOP advocates have historically said people should be aiming for.
But we’ve moved on since then and realised that actually, that’s not really a good design.
It would suffice for many simple games, but it doesn’t scale well.

You make one concrete class for the player that responds to button input and then one for a wizard enemy that attacks with spells, and then one for an elf enemy that attacks with a bow, and then you realise you want an elf wizard that attacks with magic and arrows and you suddenly realise you’ve discovered the diamond problem:

Nowadays in a game you’re more likely to see something like this:

class Entity
{
public:
	void move(Vector movement);
};

class EntityController
{
public:
	virtual void update(Entity & entity);
};

class EntityRenderer
{
public:
	virtual void render(Entity & entity);
};

Here the Entity is essentially a block of data that provides member functions for manipulating its own data, but on its own it doesn’t interact with the environment at all.

Instead, the other classes are responsible for its interactions.
A concrete implementation of EntityController handles its interraction with the world and a concrete implementation of EntityRenderer decides how it’s drawn.

This way you can mix and match different behaviours, and even come up with ways to combine them.
Also, the backend for the behaviour can be nearly anything: a behaviour tree, controller input, data sent over a network, even movement data recorded in a file.

To sum this all up, I think the real thing people get wrong about OOP is that they hear ‘object’ and imagine a real world object, and sometimes people even teach it that way “imagine a car”, “imagine a dog, and that dog is a mammal…”.
That’s not the way to think about classes.
Classes aren’t supposed to represent real objects, they’re supposed to represent ‘concepts’.

My favourite example is C#'s Stream class.
It’s an abstract class that represents a data stream.
The implementation could be a file, or a chunk of RAM or a network connection, or it could even be an intermediary that performs some kind of processing like encryption or compression.


I like the phrase “there’s no silver bullet” because it implies that the problem that needs to be solved is actually a werewolf.

In all seriousness though, there is indeed no definite solution to every problem.

In most cases though every general purpose programming language is capable of implementing a solution of some kind.
The reason for choosing a particular language over another usually boils down to constraints, familiarity, available libraries, how quickly each language can solve the problem and how robust the solution is.

OOP isn’t a silver bullet, but it isn’t the enemy either.
OOP isn’t inherantly bad, but there are a lot of people who abuse it or take every mantra as gospel without considering the reason behind the rule.
Every programming rule of thumb has an exception.

Sometimes I opt for Haskell to solve my problems if my problems require mathematics and/or data processing or would be easier with sum types (e.g. compilers are often easier to write in Haskell than languages without sum types).

Honestly I don’t think I’d ever opt for C unless C++ wasn’t available and I needed something fast/low level.
I could just about work without classes and templates, but I’d desperately miss the simple things like references, function overloading, type inference and enum classes.


#5

@Pharap of course I know structs and classes are basically the same, but they’re just confusing. (Besides two things doing the same thing is usually bad). The same goes for pointers vs references, templates vs defines, … There’s no clear direction here, just as one of the quotes said, if there’s a problem and multiple proposed solutions, they go for all of them :slight_smile: I agree it’s usually caused by insisting to keep the C compatibility. This is really, really bad. It’s a big burden. Sometimes you need to scrap the old and make the design new from the start. Maybe like Rust? (Sorry, I actually don’t know anything about it, just heard people love it. Have to go take a look at it.)

Basically to me C vs C++ is something like Arduboy/Pokitto vs PC programming. One is small, simple, basic, brings happiness. The other is big, complicated, powerful but brings a lot of head ache.

So yeah, better leave this for off-topic :slight_smile:


#6

I don’t want to derail the thread, but I have to reply to this to assert the differences between these things.
Some differences are more subtle, but every pair you listed has some important differences.

I’m not sure what’s confusing about them.

There’s more than one way to declare a variable but that’s not necessarily a bad thing.
Sometimes it makes sense to declare in full, sometimes it makes sense to use auto, it depends on the intent.

Usually people use struct as a signal that it’s supposed to be a ‘plain old data’ type, or it gets used for template types designed to act as traits (e.g. the type_traits header or char_traits types).

Besides, if struct and class behaved differently, what would the difference be?
Would structs not permit inheritance or member functions?

Arguably you don’t need the << and >> operators, you can just use division and multiplication.
The reason they’re useful is the same as why having both struct and class is useful - it’s easier to express the intent of the programmer.
Did you mean to multiply or do you just want to shift the bits?
Did you mean to create a ‘bag of data’ or did you mean to create a class?

In both cases the end result can be the same, but the approach used gives off different signals.

Pointers and references aren’t the same, there’s some big differences between the two.

References can’t be null and they must always refer to an existing object.
They eradicate the need for null pointer checking and the need for dereferencing.
They don’t have to be implemented with pointers either - that’s a common misconception.

Sometimes the compiler will replace a reference with the object its referring to at compile time, which means that object can live in a register.
If a pointer was used, the object would have to exist in RAM to have its address taken.

References are a better choice a lot of the time, so they should be the preferred option.
Pointers should only be used when references aren’t suitable.

Templates are type-safe, are parsed by the compiler, adhere to many of the language rules, are generally more powerful and can usually be better optimised.

There was a case where I was writing some code for the Arduboy and I discovered that replacing the use of Arduino’s abs macro with a template function absT (I couldn’t name it abs because of macro poisoning) actually saved memory because the compiler could better optimise the operation.

Macros are just glorified text substitution.
In all cases where templates could achieve the same effect, templates should be preferred.


#7

It’s getting out of hand :innocent: I have a file ready with some replies to this and also to the “templates” discussion we had over at Arduboy forums so that I can move it to offtopic one day. Today is probably not that day though.

I only hope no one brings up the best IDE or Linux distro questions :slight_smile:


#8

We can move to PM if you want to keep going and nobody else is interested in our conversation :P

I don’t think that many people here use Linux.
I’m only aware of three.

As for the best IDE, now we have PlatformIO support it doesn’t really matter because for Pokitto, PlatformIO is now the best option.
(Code::Blocks is possibly second best. Admittedly I still haven’t got round to trying FManga’s modified setup.)

I think IDE is more of a personal preference issue than language.
If two people work on one project, generally they have to agree on which language the project will be written in, but they’re usually free to use different IDEs.
OS might not matter either, depending on the language and how standard the libraries are.


#9

No, I don’t want the result of this mental effort to stay burried somewhere in PMs :smiley: Honestly I don’t expect any of us to significantly change our minds… the way I see these debates is they’re kind of like a book we’re writing, it should be public. You know, maybe someone comes and wants to decide whether to go C or C++ and this will show them multiple views on it, practical experiences etc. That’s the point I see here.

Not bad actually!

From my experience people will argue about personal preferences to death just as well. Don’t forget I come from the land where there are only two text editors, that are as old as the Unix time itself. It’s religion we’re talking here :slight_smile:


#10

That’s a fair point.

If someone reads my comment about references, decides to investigate them and it leads to them using references more often then my job is done.

Though it’s only useful if someone actually reads it.

As far as I’m aware nobody’s actually written a Pokitto program in C.

You wouldn’t be able to use the Pokitto library if you did use C because the Pokitto library is written in C++ and none of the functions are marked extern "C".
For that matter you wouldn’t be able to use any of the mbed functionality as far as I’m aware, because that’s also C++ oriented.

(It’s a similar story with the Arduboy.)

I intend to give Linux a go some day when I can justify it.
At the moment I can’t really justify it because it would be a lot of extra effort.
More so than learning a new programming language.

Do people really care that much about IDEs though?

I probably have half a dozen IDEs installed.
I have a favourite for each task/language, but overall it’s not a massive issue for me.

As long as there’s syntax highlighting, a find-replace tool, proper tabs, one-click compiling and a colour scheme that’s not too terrible then I’m happy.

Vim and Emacs?


#11

Yeah, technically you’re always writing C++, but you can keep you code “basically C” except for the Pokitto/Arduboy calls - I kind of do this with my current project - I keep the game logic separated from the IO so that it’s easy to port.

In the land of Unix where I come from (have I used this sentence already? :smiley: ) we have exactly one program for every thing and it only does that one thing and nothing else (and it does it the best). So half a dozen IDEs is very much against that philosophy. The idea is to have one ultimate IDE/editor that you configure exactly to your needs and learn to work with it in such a way that it’s just your second nature, the text simply flows as you think. Then you use nothing else than that one editor.

So naturally people are very emotional about their editor, which is basically Vim or Emacs as you say, because they know it very well and have put a lot of work into learning it, finding the right set of plugins and making the perfect config file.

Clicking is also frowned upon because it makes you slower - the goal of the sport is to only use keyboard.

I am actually not that hardcore, I click sometimes, but compiling is very frequent so that one I have bound to a key of course. I use mouse e.g. when I need to copy text from a browser. But many people operate even the browser and OS (typically tiling window managers) only with keyboard, they simply hate touching the mouse. (Then there are some that despise any GUI in general and only use command line environment, they use CLI web browsers, email clients, CLI games, even image viewers and all that stuff - I haven’t gotten that far yet, but I usually prefer command line.)


#12

I don’t think I’d get on well with that. I like having different options.
For example, I like to do sprite art in paint,
but for more advanced image manipulation I tend to use GIMP.

As you said earlier, there’s no silver bullet.
Every tool has good points and bad points.

My brain always runs faster than my fingers, so until they invent a psychic keyboard the text will never flow as fast as I think.

Again, I couldn’t get on with that.
I like my mouse and clicking, even if it’s slower sometimes.
For a lot of things it feels more natural, and for some things it’s faster, like switching tabs in a browser.

In terms of how I work, speed and efficiency are rarely my goal.
I spend more time thinking and mulling things over than I do typing.

If I tried to rush my projects I’d end up writing messy code, making bad decisions and having to reimplement things because I’d end up thinking of a better way later.

As do I on 90% of my IDEs, but I put up with clicking on the Arduino IDE and I didn’t find it to be that much of an issue.

Engelbart would be upset to hear that.
I can’t think of a reason why anyone would hate using a mouse unless they had RSI.

They’re missing out on Skyrim and cat videos.
(And Jonne’s .gifs.)


#13

I do all manual raster editing with GIMP - it looks like it’s for photos only, but you can set it up for pixel art too. But in practice the Unix philosophy usually strictly applies only to programmer tools or small programs. GIMP is trying to be kind of all in one for normal users, like Photoshop.

The Unix philosophy is very much about minimalism and is tight to the hacker culture, free software, free culture and similar things. For curious readers I provide a list of some of my favorite documents on related topics :slight_smile:

Interesting, I always found the bottleneck to be the brain in me :worried: Anyway you can get pretty close to typing at the speed of thought, many people can type at the speed of speech, which is probably similar.

I have it the same, I do these things mostly for comfort of my hands, but once you get a bit into it you notice the speed gain is very nice (besides looking like a real movie hacker :sunglasses: ). I definitely understand why people want to get good at this, it kind of makes you more “one with the machine”. It’s also very nice for people who work while travelling, using touch pad is a real pain.

I love the mouse too for what it’s good at - painting and games. It’s probably not really bad for switching tabs in a browser either, because your hand is at the mouse all the time, but in the code editor you mostly have both your hands on the keyboard and don’t want them to go jumping to the mouse and back. That really is several times slower than pressing 1/2/3 keys right under your fingers, plus you have to keep readjusting your hand on the keyboard and mouse all the time, sometimes you also have to look at your hands to do this => no comfort, or even RSI.

Skyrim was a good game :slight_smile:


#14

I hope you two don’t mind my intrusion, but I’d like to chime in a few points, even if I’m a bit late to some of it.

Two things doing the same thing is probably more common than you think. Can you imagine having to write x += ~0 instead of x-- because the decrement operators are technically redundant for literals?

As @pharap said, programming in anything higher-level than assembly is all about abstractions for expressing intent. If you use a struct, you’re defining a data structure. This is very different from classes which are about responsibilities, not data per se. Even if they’re the same thing to the compiler, using one thing when you should be using the other is just as weird as using an addition to subtract.

Emacs is obviously superior! :wink:

The initial effort is probably the main drawback to Linux and Vi/Emacs. To make a parallel with programming languages: IDEs, Windows/MacOS are to Basic like Vi/Emacs/Linux are to C++. At first you don’t see the point and think “Why would anyone use this?” After a few weeks of breaking old habits and developing new ones, going back feels really limiting.

Using the keyboard instead of the mouse in the IDE is like switching from a gamepad to mouse+keyboard in FPS games. Sure, you can use a gamepad to aim, walk and shoot… but it’s really clumsy in comparison.


#15

Sorry, that argument was really dumb from me, I worded it very wrong, I agree of course.

What I meant was more of a: there are two ways to do it - neither is right or wrong - but the mixture, the emerging inconsistency and blurred border between the two are wrong. No such problems emerge when you mix x++ with ++x. It’s kind of like metric vs imperial units - actually not a good example either, because here you can simply decide for one of these units. You can probably come up with rules to prevent the inconsistencies, such as when it has a member function, it has to be a class, otherwise it has to be a struct… or something like that - but that should be the language’s responsibility to define.

You know, people often think the more options the better, right? Actually no, clarity is especially important with abstractions.

The fact that @Pharap thinks of the two as basically the same (which they are) and you see a fundamental difference (which there is) confirms there is a confusion. You need to set up extra policies to deal with this. It’s an extra friction, as Jonathan Blow says (I think he bashes C++ too).

Anyway…

Emacs is obviously superior! :wink:

It has to already be clear I go with vim :slight_smile:

Using the keyboard instead of the mouse in the IDE is like switching from a gamepad to mouse+keyboard

+1

Have you actually never really used it for anything or just not in a serious way? Try dual boot for start.

A running joke is that Emacs is an operating system. So you can just decide to install Emacs as an abstraction layer and be free of any underlying OS :slight_smile:


#16

Not at all, we agree:

Same thing, different words. To the compiler, structs and classes are the same thing, to the programmer they convey meaning. What that meaning actually is isn’t part of the C++ language. The language has latitude for you to have a “dialect” or “accent” (drawing a parallel with spoken languages): a way of expressing ideas that makes the most sense to your specific situation/team. This is intentionally subjective. If we were only concerned about what has meaning to the compiler, we wouldn’t use variable names, just A, B, C, D…

In a talk Bjarne Stroustroup complained about people who try to define what C++ code should look like. Instead, he purposely avoids doing so, since what makes sense in his shoes might not make sense in others’. His goal was that the language should facilitate a diverse set of styles.

To use your wording, C++ doesn’t have blurred borders. It aims to have no borders. You set the borders that make sense to your particular situation.

I started using Emacs because of this. I have to edit files on Linux, Windows, occasionally MacOS, and in a terminal over SSH. I got tired of switching IDEs every time I had to switch to a different environment/language. XCode was the final straw. The only only editors that I could expect to use for everything/everywhere were Vim and Emacs. I spent a week on each to see what “stuck”.
Emacs won for me, though I consider it and Vim equivalent.


#17

You can. I tried it. I didn’t get on with it so I went back to paint.

I partly agree with some of the Unix philosophy.

For one thing I regularly write ‘throwaway’ programs, usually to calculate something for me or process some data or sometimes as a proof of concept.

I like the idea of making pipable programs, but the problem is that the idea that ‘text streams are a universal interface’ doesn’t always hold true in the real world.

Those text streams have to have conventions about what they contain, and they don’t always contain the same information, so you end up needing to transform it or filter it.

I don’t know if I type faster than I speak or speak faster than I type,
but I know that I think faster than I speak or type because I’m usually thinking several words ahead of what I’m typing and often have to slow down to stop myself skipping words or making mistakes.

I’d say that’s possibly less of an issue with code than with words/speech though.

I admit I find typing easier than speaking though.
I often type text walls but ironically I’m quite a quiet person.

Also most people think in terms of symbols and diagrams as well as words and text, and those are hard to convey with just typing.
A state diagram is usually a better expression of a state system than some code implementing a state system, which is one of the reasons why documentation is so important.

I used to play TF2 with a touch-pad.

That said, even if I still had a usable laptop I rarely travel far and I’ve never attempted to work while in motion, so I can’t really say either way.
Though I think one of the modern touch-screen laptops would make that a darn sight easier.
(You’d probably struggle to find the room to use a laptop on most British trains anyway.)

I’ve suddenly realised the irony of those people only wanting keyboards when there are lots of the people who like using tablets, which are pretty much all mouse and very little keyboard.

Like I say, I’m not usually in a hurry to type my code.

Though even then I usually find it’s quicker to grab the mouse and click where I want the cursor to go than to keep tapping or holding the arrow keys.

Also I’ll usually flick to a different process at some point (web browser, file browser, steam, music player etc) anyway, or remove one hand so I can have a sip of my drink.

I find that I don’t always need to see what I’m typing to know what I’m typing.
Sometimes I stare at my hands on the keyboard rather than the screen.
Sometimes I just have my eyes closed or looking elsewhere.

I have no comfort issues using a mouse. I find my mouse just as comfortable as a keyboard as long as I’m not using it for hours at a time.

It still is :P


Not at all.

Even certain variations of assembly have abstractions.
Some kinds of assembly have aliases (e.g. LSH x for ADD x, x) or some kind of pre-increment/post-decrement syntax for alternate versions of instructions (e.g. the MOS6502 and its different addressing modes).

Yup, x - y == x + -y.

In fairness, if you’re thinking in terms of group theory then the addition of an additive inverse isn’t all that weird,
but most programmers aren’t thinking in terms of group theory when writing programs :P

I see the point for some people who really do have a lot of things they want to pipe and automate and the like, but for me I think that would be a bit of a waste.
I can’t even begin to think what I’d possibly do with it.

I do actually use my %PATH% on Windows and I have got things like GHC and git set to be usable from the command line, but I find that I rarely use them.
In the case of git I use the GitHub UI far more often, even though I know there are certain things that are harder to do with the UI (like undoing the last commit to master when it’s tragically incorrect :P).

Even if only using the mouse and not using the keyboard sped up my programming process considerably,
I don’t think the saved time would make me more productive.
(If anything I’d just spend that time procrastinating more. :P)

Also part of using the mouse is a matter of comfort/laziness.
I know that I can use Alt+1,2,3 etc to switch tabs in some of my editors, but it feels more clumbsy to me than using the mouse, and I have to spend mental effort figuring out the number of the tab I want instead of lazily pointing at it.

What sort of inconsistency?

To use these as an example:

++x increments x and the result of the expression is the incremented value of x
x++ creates a termporary variable (let’s call it x2), increments x and the result of the expression is x2.
Otherwise they’re exactly the same, if you treat them both as a statement rather than an expression then they both have the effect of incrementing x, and which one you choose to use is a matter of preference.

I opt to use ++x in every case where I could use either, whereas a lot of other people opt to use x++ when they could use either.
There’s actually less of a consensus on this than when to use class/struct.

struct creates a product type, but all members are public by default.
class creates a product type, but all member are private by default.
If you use explicit access modifers all the time then they both have the same effect of declaring a product type, and which one you choose to use is a matter of preference.

So it’s essentially the same conundrum, but with a more common consensus of ‘use struct for traits and plain-old-data types, use class for more complex types’.

You can choose to stick to just using class or just using struct.
I believe most of my code uses class almost all of the time.
The only time I purposely opt for struct is when creating traits-like classes or metatemplate utilities.

I beg to differ.

The Go programming language has decided to try to end the brace war by forcing people into using a certain brace style rather than allowing programmers to use the brace style that suits them.
The language is worse because of it.

Sometimes it’s better to just let the programmer choose rather than forcing them to do something a single way.
That’s one of the reasons Perl’s mantra is “there’s more than one way to do it”.

True, but whether the type says class or struct at the start has so little bearing on what comes next that it’s usually negligable.
It’s like opting for auto n = 5 over int n = 5.

In terms of the language they are technically the same apart from the default access modifer which is fundamentally different.

How people choose to use them is a much bigger difference.
People have their own conventions for what extra meaning gets assigned to them, and like I said earlier the convention is usually ’struct for C-style bags of data, class for proper classes’.

It’s as much of a convention as opting to avoid this-> for accessing members or naming members with an m_ prefix.

I’ve tried it briefly on other people’s laptops and I’ve seen several variants in action.
Nothing has really gripped my interest enough to think of it as anything more than “something I’ll give a try someday”.

Too much hassle.
Partitioning the harddrive, installing, finding software to put on it, getting used to the new software etc.
All that stuff takes time, and I can’t really see what benefit it would give me.

Like I said earlier, if it made my day-to-day process more efficient then I’d just end up wasting the saved time.
I’m not aiming to be more efficient.

If I wanted to be more efficient and to produce more code, I’d start by spending less time on forums, which by far eats more of my time than time spent using a mouse. :P


#18

I suddenly remembered:
although a lot of people are used to using these terms because that’s what they’re called in a lot of common media,
these are both outdated/incorrect.

America doesn’t use the Imperial system, it uses US customary units.

Also the ‘metric system’ is now technically the ‘International System of Units’ (or ‘Système international (d’unités)’, shortened to SI units).

Just for the sake of technicality. :P


#19

I see your points on classes vs structs - I don’t know how else to express the essence of my dissatisfaction with these - it probably goes into the Unix philosophy again. For example the:

Everything is a file.

rule - it’s a nice rule. A lot of OOP languages try to be purely OOP and the result is similar: everything is an object. But not in C++: something is an object, something’s not, it depends and sometimes you may as well toss a coin.

However it’s weird because for example Python is multiparadigm too and I don’t have such problems with it (I have some though)… So thinking about it, it’s probably because in Python it makes sense and is more elegant, designed this way from the start: You have a spectrum of structures covering all your needs evenly, whereas in C++ you basically only have these two native structures, which are very similar and exist only for historical reasons. Two is a very weird number - it’s not many, but it’s also not all the way to the “everything is X” philosophy. The rest is somehow filled in with the STLs, but that’s awkward because not always you have the standard library at hand.

So it’s just inelegant. C++ is a working solution, but ugly.

A lot of documentation is text only though. I think all these graphical representations are overrated too - at this level (small teams). The UML probably makes some sense as a communication tool in a corporate environment between a large number of people of different educations/languages etc. A lot of projects with a core team of a few people live happily with just text. Anyway, matter of taste probably.

You know, a lot of programmers say a good code is its own best documentation - not to be taken too seriously of course, but there’s a bit of truth. Just an inspirational quote from John Blow again:

Comments are code that never runs and code that never runs is a code that has bugs.

Just food for thought :slight_smile:

Nice graphical documentation is always nice, but not always necessary (<- I can never spell this word correclty :frowning: ).

Oh man, I hate these, it’s like mouse–.

Probably, but I refuse to play it now :slight_smile:

(I used to be the biggest fan though, played all the games and DLCs, read all the books etc. I am contributing to OpenMW nowadays.)

Well, using one vs the other. Another example: exception handling… to what extent should I use exceptions vs the good old returned codes? I think I’ve never seen anyone use these consistently. There are some obvious cases where a lot of people feel like they have to use exceptions, then in the rest of the code they simply check return codes because it’s easier, and then there are places where they abuse the hell out of exception (catch all) - this can cause more damage than good. Then you have situations like when you have library A that is designed with exceptions and library B that isn’t and you have to somehow deal with it.

Weird syntax reminds me of Lisp… any experience with that? :slight_smile: I still have it on my list of things to learn. Looks like a very nice language. Basically the closer something is to functional, the more appealing it seems to me… also the less I really use it in practice though.

Any opinions on why Haskell hasn’t taken over the world yet when everyone seems to love it? There was a recent article that explained this by the fact that basically what sells a language is IO. Actually implementing algorithms isn’t that difficult once you have IO sorted out. (Thinking about it it’s what brings me to C++ usually - the streams and standard strings.)

Actually I am very thankful that the most skilled programmers in this community take a bit of their time to talk to me :slight_smile: If anyone else reads this, feel free to join in.


#20

Since we have the split thread now, let me paste the rest of my rant:

  • Multiple meanings of the same keywords: const, static, … <- This is a symptom of an underlying problem:
    many rule. Many rules make complicated systems with many ifelses prone to bugs, forcing users to remember unnecessary amount of information etc. C++ is such system. It inevitably has to manifest itself as

    • a big number of different keywords (also kind of the case), or
    • keywords with different meaning (case here)
  • related to OOP in general:

    • Setters/getter are real bad: basically whenever you want to add or delete a member variable, you have to do three things. Setters/getters are meant to validate/process data when accessed, but most data don’t need this. So all this usually encourages me to use structs when I should use classes (or make public member classes).
    • Inheritance leads to problems (circle-ellipse problem etc.), people and many design patterns usually resort to composition… but that’s basically what you do in C.
  • Templates: it’s an extra language within an already complex language - actually with the standard C preprocessor you now have three different-syntax languages in one, operating on different stages (runtime vs compile time). Again, this is many new rules you have to keep in mind - yes, you can do it, but it’s a mental burden, wasted brain capacity that could be used on solving actual problems, a potential for errors, and an additional thing for the compiler to implement. It’s kind of a similar case as with webdev nowadays - people try to replace PHP with JS and use JS for everything, since mixing all these languages makes no good.