How can be concentrated multiple lines of C++ code in only one?

[tubar]

How can be concentrated multiple lines of C++ code in only one?

I want to concentrate my C++ code in smaller space.

Example 1: I want to put the following 2 lines into 1 line:

float a[n][n+1], x[n];
double eps, err, errmax, ratio;

Example 2: I want to put the following 4 lines into 1 line:

#include<iostream>
#include<iomanip>
#include<cmath>
using namespace std;

[Repeater]

float a[n][n+1], x[n]; double eps, err, errmax, ratio;
This is a terrible idea. Code is written and formatted for humans to read.

#include<iostream>
#include<iomanip>
#include<cmath> 

These are instructions to the preprocessor, and trying to move them all onto one line is a very bad idea.

You could them all in one file:

myIncludes.h

#include<iostream>
#include<iomanip>
#include<cmath> 

and then use

#include "myIncludes.h"
This may or may not be a terrible idea. It's certainly hiding information from the reader.

[dhayden]

How can be concentrated multiple lines of C++ code in only one?

The answer is almost always "badly."

The examples you give should be on separate lines.

Where you can save space is in the code itself by cuddling the { on the line with the other code:

if (condition) {
} else {
}

for (i=0; i<10; ++i) {
}

void foo(int param) {
}

[jonnin]

c++ does not pay any attention to end of lines; I think the only exceptions are string literals and macros, and you should not use macros in most code. Both of these cases are triggered when you do line breaks, eg
cout << " hello
world"
is no good due to string break across lines. you can overcome this with the special line continue marker \ but again, its not recommended to do this.
but
int main(){cout << "hello world";} //all on one line is fine, but horrible practice.

mismatched brackets does save space but its difficult to read.
you can also combine small things, like simple conditions:
if (something) x = 3;
else if(other) x = 5;

things like that look ok.

what is your purpose here? If writing a book, the better answer is to simplify your examples, and keep the condense things to a minimum only where they do not make a mess.

[tubar]

I tried the following alternative variants that didn't work:


#include<iostream> && #include<iomanip> && #include<cmath>
using namespace std;

also

#include<iostream> ; #include<iomanip> ; #include<cmath>
using namespace std;

also

#include<iostream> || #include<iomanip> || #include<cmath>
using namespace std;

also

#include<iostream> << #include<iomanip> << #include<cmath>
using namespace std;

also

#include<iostream> <<endl; #include<iomanip> <<endl; #include<cmath>
using namespace std;

also

#include<iostream> / #include<iomanip> / #include<cmath>
using namespace std;

And I dont know why C++ dont have such capability. Especially for SINGLE or ISOLATED instructions .

For example for the instruction COUT it is possble:

cout <<"Numarul iteratiei: " <<k <<" a=" <<a <<" b=" <<b <<" c_ant="<<c_ant;
cout <<" c("<<k<<")=" <<c<<" eroarea=" <<fabs(c-c_ant)<<endl;

Its stupid not to be capable if I want to concatenate two lines of code into only one. Those eggheads that design those tools do not let the freedom to the programmer... And C++ is famous for his flexibility !

[dutch]

Those eggheads that design those tools do not let the freedom to the programmer.

Alternatively, you are a braindead retard.

[Ganado]

This is such a stupid hill to die on. Preprocessor commands require their own line. Get over it, and write legible code instead of densely packed code.

[Albatross]

As stated above, if you're optimizing for code length by trying to stuff as much into single lines as possible, you're either doing something wrong, or trying to compete in some code brevity competition using a language not designed for it.

Repeater provided the best solution to your particular issue: move your includes to a separate header and include that.

I'll leave you with a philosophical thought: excessive programmer freedom in the absence of widely-accepted best practices guidelines results in dialects within programming languages, which makes it harder for programmers using the same language to collaborate, and oftentimes provides limited tangible benefits. Consider that programmers still occasionally fight over the best brace style.

-Albatross

[Repeater]

Those eggheads that design those tools do not let the freedom to the programmer...

Alternatively, they set things up so that you would spend ZERO time on this. So that you would not waste your time on something that makes no difference, and you would spend your time actually programming and solving problems.

And you've somehow STILL managed to waste your time on this, even thought they tried so hard to guide you into doing something useful.

[dhayden]

#include is a preprocessor directive. #include "foo" basically says "copy / paste the contents of file foo here."'

Given that, it should be clear why #include <iostream> && #include <iomanip> can't work. It would result in a bunch of declarations separated by a random &&.

I suppose that #include <file1> <file2> "file3" might make sense, but there's probably some obscure reason why you can't do it. Or maybe the C++ committee simply figures it isn't worth the trouble.

My personal pet peeve is that we can't do this:
using std::cin std::cout std::endl // etc.

Again, there's probably some reason for it.

[Ganado]

At least, you can do using std::cin, std::cout, std::endl; // etc. in C++17.
But the C preprocessor really hasn't changed since... C.

[tubar]

If the redaction of the Code follows a logical order I don't know why would not allow more ways of presenting the script.

I think remained residual the OLD CONCEPT of ECONOMIZING COMPUTING RESOURCES by writing each time SHORT lines of instructions. It remained an old school concept :).

Today the PC's are much more powerful, the memory does not restrain much today the programmer.

[doug4]

header1.h:

// This is a header
void foo();
// The last line is a comment without a new line 

header2.h

void bar();

main.cpp

#include "header1.h" "header2.h"
int main() {foo(); bar();}

Supposing for a moment that there were ANY value to writing short code, how would the above work?

Because #included files are pasted into the source files, the declaration of bar would be appended to the end of the first file included, effectively putting it at the end of the single-line comment. There would be no declaration of bar(), and the code would not compile.

Writing obfuscated code is what was done 40 years ago. Back then, storage was expensive and compiler optimizations were poor. Tricks to shorten code were encouraged.

But now it is accepted that verbose code with lots of appropriate white space, formatting and good comments is easier to maintain and cheaper and better in the long run.

There are old books of obfuscated code samples that are essentially puzzles: "what does this do?" They are amusements but should never be used in live code because, when reviewing it-or worse, when maintaining it-the time to figure out what the code does is longer that the time it would have taken to write it cleanly and verbosely in the first place.

So, why again are individual lines of #includes so vile that you need to combine them into 1?

[tubar]

And how work those instructions like std::cin, std::cout, std::endl;


Give working examples, pls. I want to note all the possibilities to compact the code lines.

Another example:
for(k=1; k<=n; k++){
flag = A[ k ][ j ];
for(l=1; l<=n+1; l++)
if(k != i){
A[k][l]= (A[k][l]) - flag * (A[i][l]);
mul++;
sub++;
}
}

Is tolerable to put the last too brackets in the same row to economize space like below?
.........
mul++;
sub++;
} }

C++ runs the code also in this way, but I ask if it is a blasphemy this practice by Programmer point of view.

[salem c]

This kind of nonsense belongs here -> https://www.ioccc.org/

There is zero (let me repeat ZERO) benefit to compressing code and using meaningless variable names.

Turning what should be comprehensible in seconds to the average programmer into something that takes minutes is of no use to anyone. In fact, what most people would do would be to drop it in an editor and start formatting and renaming before doing anything else. Forcing people to do that will just make them hate you as a programmer.

It has absolutely NO impact on the run-time performance of the code.

If you write code like this in any professional or team setting, expect it to get thrown right back at you the first time you do it, or expect to be looking for alternative employment if you persist.

[dhayden]

Is tolerable to put the last too brackets in the same row

There's a guy at work who does this. It's not my preferred coding style, so I guess to each his own.

However, there are far more important things that need to get fixed in this example. The lesson here is that the code matters most.

// Code MUST be indented.
for(k=1; k<=n; k++){            // 1 to n or 0 to n-1??
flag = A[ k ][ j ];
for(l=1; l<=n+1; l++)           // NEVER use l as a variable. Too easy to confuse with 1. Also, 1 to n+1?
if(k != i){
A[k][l]= (A[k][l]) - flag * (A[i][l]); // use -= instead
mul++;                                 // not used inside the loop, so pull it out
sub++;                                 // ditto
}
}

So in a code review, I'd have questions or changes for 5 of the 7 lines of code, plus a general comment to indent it. By then, I wouldn't even care about the closing braces.

[tubar]

mull++ is serving for finding partial results of each iteration. There is only a fragment of code.

So, I can put the brackets } } only into a line? I try to avoid long codes on a lot of Word pages so that to make space economy of 10-20 %.javascript:editbox1.editSend()

[mbozzi]

So, I can put the brackets } } only into a line?

The clarity of properly indented code doesn't depend on the placement of braces.

for (k = 1; k <= n; ++k) {
  flag = A[k][j];
  for (l = 1; l <= n + 1; ++l)
    if (k != i) {
      A[k][l] -= flag * A[i][l]; 
      ++mul; 
      ++sub; }}

The C++ community will find this bracing style highly unconventional and hard to maintain, but it does not impede understanding.

Compact, general, and brief notations can aid comprehension, it is true. If you want short code, choose better notations. Do not focus on removing white-space, because it is unrelated to the notation. You're wasting time compressing text.

The number of bytes your source code uses has literally no effect on your end product. Stop wasting time and fix some bugs.

[Ganado]

> I try to avoid long codes on a lot of Word pages
Word? Like Microsoft Word? Are you not using an IDE or at least programming-oriented text editor like Notepad++, Sublime, etc.?

[helios]

The C++ community will find this bracing style highly unconventional and hard to maintain, but it does not impede understanding.

I disagree with this statement. While the code may indeed be correct and the programmer may be correctly understanding it, using a very unconventional style like that makes it more difficult to tell at a glance if the code is structured properly or whether the person reading it has missed a critical piece of syntax that changes the meaning.