Looking at C++: int a = 1 vs int a{1}

[ElektroQuark]

First steps with C++ and  I see different options like:

"int a = 1"
 or
"int a{1}"

Any thoughts or preferences?

[tggzzz]

There are hints in the FQA at http://yosefk.com/c++fqa/picture.html#fqa-6.16

But read the entire document so you can start thinking about more important points.

(I'm particularly fond of the "const correstness" sub-section)

[ataradov]

Any thoughts or preferences?

The first one, of course. Where did the second one even come from?

[AntiProtonBoy]

The first one, of course. Where did the second one even come from?

It's called the aggregate initialisation syntax. For basic POD and built-in types, i generally use assignment initialisation, but for classes and structs i do lean towards aggregate initialisation.

edit:

There are hints in the FQA at http://yosefk.com/c++fqa/picture.html#fqa-6.16

That FAQ is pretty much obsolete. C++ Core Guidelines supersedes that.

[ElektroQuark]

Quote from: ataradov on Today at 08:58:17>Quote from: EdoNork on Today at 08:32:45

Any thoughts or preferences?

The first one, of course. Where did the second one even come from?



From a course from Microsoft HERE

[tggzzz]

Any thoughts or preferences?

The first one, of course. Where did the second one even come from?

That's one of the beautiful things about C++: it provides duplicate ways of doing simple things, so that you can write code in whatever subset of the language you personally feel like.

[John Coloccia]

Makes more sense if you see it in this form:

int a[3] = {1, 2, 3};

or

Code: [Select]

struct s
{
   int a;
   float b;
   char c[10];
};

s myStruct = {1, 1.23, "john"}; 

Please don't ever do:

int a{1};

If for no other reason than it's ugly.

Honestly, I don't really like this form of initialization at all, at least when doing it by hand. I think it can be very confusing and error prone because the meaning changes just by changing around the ordering of variables in a struct.    But that said, I do find that it's very convenient for auto-generated code. Stuff like this comes up all the time when you're working with embedded controls and things like this. You have all sorts of utilities that spit out tables, maps and things like that, and this is a nice, easy way to format the output.

[Brumby]

Makes more sense if you see it in this form:

int a[3] = {1, 2, 3};

Thank you for an example that is useful.

[AntiProtonBoy]

I think it can be very confusing and error prone because the meaning changes just by changing around the ordering of variables in a struct.

Compilers are getting pretty good with alleviating errors. Also, I think you should probably get used to it, because this kind of initialisation (and related aggregate syntax) will be more common once structured bindings is introduced in C++17.

[John Coloccia]

I think it can be very confusing and error prone because the meaning changes just by changing around the ordering of variables in a struct.

Compilers are getting pretty good with alleviating errors. Also, I think you should probably get used to it, because this kind of initialisation (and related aggregate syntax) will be more common once structured bindings is introduced in C++17.

Get used to it? It's been part of C forever.

[VK3DRB]

Any thoughts or preferences?

The first one, of course. Where did the second one even come from?

That's one of the beautiful things about C++: it provides duplicate ways of doing simple things, so that you can write code in whatever subset of the language you personally feel like.

For amateurs, maybe. But in a professional environment, there is only one way to code: To that which is dictated by the company's coding standards.

[helius]

But in a professional environment, there is only one way to code: To that which is dictated by the company's coding standards.

What an elegantly obscure way to enshrine Not-Invented-Here syndrome into every project!

[John Coloccia]

But in a professional environment, there is only one way to code: To that which is dictated by the company's coding standards.

What an elegantly obscure way to enshrine Not-Invented-Here syndrome into every project!

I'm assuming you're not a software engineer, and the above statement perfectly illustrates why people who don't understand software should not be managing software. I suppose when you design a board at your company you just toss it together randomly and don't follow any standards, best practices or guidelines, right?

[Brumby]

I'm assuming you're not a software engineer, and the above statement perfectly illustrates why people who don't understand software should not be managing software. I suppose when you design a board at your company you just toss it together randomly and don't follow any standards, best practices or guidelines, right?

I was thinking the same.

Standards are put in place so that when you have 10 people work on a program over the years that when no. 11 opens up the source, they have some chance of following it.  It also helps with site specific parameters.

[John Coloccia]

I'm assuming you're not a software engineer, and the above statement perfectly illustrates why people who don't understand software should not be managing software. I suppose when you design a board at your company you just toss it together randomly and don't follow any standards, best practices or guidelines, right?

I was thinking the same.

Standards are put in place so that when you have 10 people work on a program over the years that when no. 11 opens up the source, they have some chance of following it.  It also helps with site specific parameters.

Yeah, exactly. Software is difficult enough as it is. Clarity and consistency are orders of magnitude more important than using every possible language feature, especially when you're dealing with a crazy, disjointed language like C++.

[tggzzz]

But in a professional environment, there is only one way to code: To that which is dictated by the company's coding standards.

What an elegantly obscure way to enshrine Not-Invented-Here syndrome into every project!

I'm assuming you're not a software engineer, and the above statement perfectly illustrates why people who don't understand software should not be managing software. I suppose when you design a board at your company you just toss it together randomly and don't follow any standards, best practices or guidelines, right?

I've worked at one company where the software was thrown together (the Rational ClearCase product tree showed a clear case of enzyme disorders), and which had a coding standard for the different languages in use.

For C/C++ they mandated the use of the "register" keyword, even though the compiler they were using had ignored it for at least two decades.

For Java, they also mandated use of the "register" keyword. 'nuff said.

But yes, coding styles are helpful, especially for those languages that have to be subsetted if there is to be a hope of maintainability.

[John Coloccia]

I've worked at one company where the software was thrown together (the Rational ClearCase product tree showed a clear case of enzyme disorders), and which had a coding standard for the different languages in use.

For C/C++ they mandated the use of the "register" keyword, even though the compiler they were using had ignored it for at least two decades.

For Java, they also mandated use of the "register" keyword. 'nuff said.

But yes, coding styles are helpful, especially for those languages that have to be subsetted if there is to be a hope of maintainability.

Stuff like this drives me crazy. Stupid rules are worse than no rules. Then no one respects any of the rules because you can't tell what's real and what's neurotic. Grrrrr...

[AntiProtonBoy]

Kinda amusing, because the register keyword is getting removed from newer versions of standard as well. It will be unused and reserved.

[AG6QR]

For amateurs, maybe. But in a professional environment, there is only one way to code: To that which is dictated by the company's coding standards.

Unless you work in a company that grows, and acquires others, and has a history.  Software can often last longer than coding standards.  When the standards change, it's rarely feasible to go back and re-write all the code to match the latest standard.  When you acquire software that was developed elsewhere, to different standards, it rarely pays to rewrite it to meet your standards.

I've worked on more than one project where the policy was: Use your project's standard for writing new code, but when modifying old code, use the "when in Rome, do as the Romans do" model.  As you browsed through source code for a large product, you could clearly see that different areas were developed with different standards.

That's one thing in favor of Python.  The language itself enforces some standards (like indentation) and many others are commonly enforced by an automated tool like PEP8. 

Standards really do help code readability, and since most lines of code are written only once but read many times, it pays long-term dividends to write for readability.  But my experience is that, with a large product and large team, if standards aren't enforced by software, it's a rare team that will strictly stick with them over the long haul. 

[Ampera]

Leaning back and drinking my Java here, eating some NetBeans from a tin.

[donotdespisethesnake]

Coding standards are a waste of time. I've never seen a bug prevented by a coding standard.

OTOH, coders who don't recognize valid syntax like "int a{1}" because "it is not in the company standard" are probably great at following rules but terrible at coding.

You can't write good code by following rules, nice idea but doesn't work.

[Lukas]

To my surprise, no one mentioned that the {} initializer's got new semantics. "Assignment initialisation" does silent type narrowing, i.e. a float gets truncated to an integer.
The {} initializer OTOH will bark at you when it does type narrowing.

[tatus1969]

my answer would be
- use a=1 if you want your code to be easily readable by everybody. I for example know C from the early days, but only stumbled upon the second flavor some years ago. Took me a minute to understand what it meant.
- use a{1} otherwise :-)

[John Coloccia]

Coding standards are a waste of time. I've never seen a bug prevented by a coding standard.

OTOH, coders who don't recognize valid syntax like "int a{1}" because "it is not in the company standard" are probably great at following rules but terrible at coding.

You can't write good code by following rules, nice idea but doesn't work.

With due respect, this sounds like the voice of inexperience. One of the most important things you can do when leading a software project is to have basic standards and conventions, enforce them, and have a strict process that includes a real code review and 2 eyes on everything approach. That only works efficiently if everyone does things the same way. Having one cohesive coding style means that no matter where you go in the code, and no matter who wrote it, everyone on the team can look at any piece of code and work on it very efficiently. And yes, if you go off on your own and don't follow the conventions, you will fail code review and you'll be rewriting the code.

And yes, it prevents countless bugs, because countless bugs are found in code review when everyone is immediately comfortable with every piece of code they look at.

It's things like this that separate the groups that seem to always produce buggy, unstable garbage and take forever to get something working from the superstars that seem to always have a rock solid code base. The former is why software is usually seen as a necessary evil and a liability as opposed to a revenue generator.

I have a feeling that most people have simply never worked with a software group that's run properly so they don't really know the levels of reliability and efficiency that's possible.

[John Coloccia]

For amateurs, maybe. But in a professional environment, there is only one way to code: To that which is dictated by the company's coding standards.

Unless you work in a company that grows, and acquires others, and has a history.  Software can often last longer than coding standards.  When the standards change, it's rarely feasible to go back and re-write all the code to match the latest standard.  When you acquire software that was developed elsewhere, to different standards, it rarely pays to rewrite it to meet your standards.

I've worked on more than one project where the policy was: Use your project's standard for writing new code, but when modifying old code, use the "when in Rome, do as the Romans do" model.  As you browsed through source code for a large product, you could clearly see that different areas were developed with different standards.

That's one thing in favor of Python.  The language itself enforces some standards (like indentation) and many others are commonly enforced by an automated tool like PEP8. 

Standards really do help code readability, and since most lines of code are written only once but read many times, it pays long-term dividends to write for readability.  But my experience is that, with a large product and large team, if standards aren't enforced by software, it's a rare team that will strictly stick with them over the long haul.

Or taking over a pile of garbage code base! I've had to do that several times. The way I ran it was simple. All new code is done to the standard. Minor bug fixes in the old code stays the same. Major bug fixes, where you're spending weeks on it anyway, get reformatted/renamed/whatever to bring it up to snuff wherever it's practical and low risk. Eventually, a large chunk of the code base gets to be pretty good and easy to maintain, though you always end up with some old pieces of code that everyone's afraid to touch because it's so nightmarishly poorly written and fragile. For stuff like that, I usually have a wish list kicking around of little tasks that maybe take a day or two to knock off, that breaks the job up into little, manageable chunks, and it happens as a side task/branch. When things are slow and someone's looking for something to do, I'll give them one. Eventually it gets to the point that we can consider replacing that offending code the next time we go in there, and it's all been so well tested by this point that it's very low risk.

It's really a thing of beauty when you have a software group that operates at high level of efficiency and it suddenly becomes an asset instead of a liability.