How do I make it better #include <iostream> #include <string>

Mongo + Express.js + Angular.js + Node.js

>>52857765
>How do I make it better

In what sense "better"?

But anyway, use using and endl for starters.

Node.js

>>52857883
>>52858053
SJW cancer
GTFO

>>52858011
Don't use 'using' but do use 'std::endl;'. 'using' puts you at risk for conflicts. It's a better practice in the long run.

>>52858794

Hmmm, maybe. But I never had a problem with using and conflicts myself. 15 years c++ experience.

>>52857765

#include <stdio.h>

int main(int argc, char *argv[])
{
    printf("Hello, world!\n");
    return EXIT_SUCCESS;
}

>>52858964
old school FTW

File: 1442618891558.png (651KB, 750x1334px) Image search: [Google]

651KB, 750x1334px

>>52858629
>being this much of a newfag

>>52858964
beautiful

>>52857765

#include <iostream>
#include <string>

using namespace std;

int main() // if you aren't expecting to use arguments in your program, don't write them in.
{
    string helloworld ("Hello, world!\n");
    cout << helloworld;
}

>>52858960
that's because it's an epic meme to get on programmers nerves
>>52857765
>>52858964
>>52860609

#include <stdio.h>
int main() { printf("Hello, world!\n"); return 0; }

>>52858794
the only libraries that would use the std namespace are libraries that you should not be using
what the fuck kind of library would have the audacity to use std as their namespace

>>52858794
What conflict exactly is going to happen when you put using std in your main.cpp? Give me one example. All other languages do just fine with importing namespaces, but in C++ you keep saying it's a bad practice.

>>52860628
you might want to be more explicit in C:

#include <stdio.h>
int main(void){ /* the main function may fail to run if you don't explicitly establish its parameters, or lack thereof */
printf("Hello, World!\n");
return 0;
}

>>52860609
says the guy who declares main as an int and doesn't return a value

>>52860680
The standard allows this.

>>52860680
welp, i guess every programmer except me has never made oversights.
time for me to give up

>>52860663
are you trolling
empty () always mean void
it's only your autism
there is no compiler that will let you do anything else

>>52860702
>empty () always mean void
The post you are quoting explicitly states he's using C so you are objectively wrong.

can you do

void main()

?

>>52860663
>that lack of indentation

>>52860696
I'm glad you understand now

>>52860725
in C++? yes.
in C? not the best idea.

>>52860695
The standard also allows putting the parameters and not using them

>>52860733
>being assraepd by Python feminazis

>>52860737
/g/: where snarky 1upsmanship trumps conceptual insight

>>52860725
No since C and its variants (along with most programming languages) return a value, not nothing (void)

>>52860752
Well, yes, but his point is not "be standards compliant", his point is "write less - don't write things you don't need".

>>52860759
It's disgusting to look at anon, you should know better.

>>52860748
o, wait, no.
the main function must always be non-void in both C & C++

>>52860807
well now that I think about it, yes.

File: Yal1xei.png (734KB, 646x610px) Image search: [Google]

734KB, 646x610px

>>52860776

>>52860810
Why wouldn't it work? int main() and void main() would produce the same symbol with same code.

What is the (int argc, char *argv[])?

>>52860824
i'm not sure on all the details, but i think it has something to do w/ external processes invoking the program & making sure the program actually works.
also, as far as computers are concerned, 0 is non-void, & void establishes the difference between a "function" & a "procedure"

>>52860859
it helps programmers write nuanced commands while invoking programs. e.g ls -la
in the example given, "ls" is the argument invoking the program, and "-la" is the argument that determine exactly what the program should do

>>52860859
>argc, char *argv
arguments, it's literally defined and named beginning with arg, count and an array

>>52860868

#include <stdio.h>

void main(){
    printf("test\n");
}

Compiles and works for me with GCC.
You're completely off with your assumptions. On all architectures I know (and that's ARM and x86/64), calling void function and calling int function are the same. compiled C code produces the same symbol to refer to void and to int function.

>>52860912
it's been my experience that in cases where it does compile, it's generally a practice that's seen by experts as playing w/ fire

>>52860912
I don't do much C but I imagine when you don't return specifically the program exits with a status code that is then returned (like EXIT_SUCCESS)

>>52860912
what error code do you get when you run this?

>>52860937
If it works on some architecture, it will work there forever.

The one thing worse than playing with fire is refusing to play with something at all because you think it might be fire.

>>52860912
>>52860937
>>52860949

using "int main" and returning 0 (or EXIT_SUCCESS from stdlib.h) is the best idea

unix operating systems use the return value from main as part of the status of the program. if you don't explicitly return a value then the actual value that appears to the operating system is "random"

>>52860949
>>52860950
I get zero with mingw gcc, but obviously if you do care about return code you should be specificity it.

>>52860976
EXIT_SUCCESS is always zero, it makes no sense because I have to use the ! operand to check if it was a success instead of making it pseudo bool with the value 1, but that's how it works.

>>52861011
It makes a lot of sense - at least made to unix devs. There is only one state of success, but plenty of reasons why the failure occurred. So success was chosen to be 0, a number unlike all others.

>>52861035
Yeah you're right anon I didn't think about it like that.

>>52857765
sorry it took me so long
i had to read a lot of documentation

#include <ecl/ecl.h>
int
main (int argc, char *argv[])
{
  cl_boot (argc, argv);
  cl_eval (ecl_read_from_cstring ("(format t \"Hello, world!~%\")"));
  cl_shutdown ();
  return 0;
}

File: zfyc6bK.gif (241KB, 200x193px) Image search: [Google]

241KB, 200x193px

console.log("Hello World")

>>52861431
and yet you still managed to get it wrong

>>52861444
No I didn't.

>>52861444

print("Potato pancakes in a sweet mustard sauce")

File: 1453772013972.gif (104KB, 300x136px) Image search: [Google]

104KB, 300x136px

>using printf without additional parameters

frog->REEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE()

>>52861444
What?

>>52861431
>>52861444
>>52861462
>>52861517
;

>>52861571
They are not required.

>>52861479
A smart compiler e.g gcc converts redundant calls like that to puts() anyway, check the assembly

#include <stdio.h>

int main(int argc, const char *argv[])
{
    printf("hello world!\n");
    return 0;
}

...
movl    %edi, -4(%rbp)
movq    %rsi, -16(%rbp)
movl    $.LC0, %edi
call    puts
movl    $0, %eax
leave

>>52860659
Namespaces are like separating different items into different drawers. What you're saying is basically that there's no issue putting forks and bowls all jumbled up together in the same drawer because there's no way you're going to mistake a fork for a bowl anyway.

>>52862125
Your analogy does not make your argument any stronger. Analogies are used to better explain something when one is ready to believe another without questioning. We are arguing -- I am opposed to your point of view. So analogies are meaningless. Bring an actual argument.

how's this my friends?

#include <stdio.h>

int main() {
    int i = 13;

    char phrase[i];
    phrase[12] = 'H';
    phrase[11] = 'e';
    phrase[10] = 'l';
    phrase[ 9] = 'l';
    phrase[ 8] = 'o';
    phrase[ 7] = ',';
    phrase[ 6] = ' ';
    phrase[ 5] = 'w';
    phrase[ 4] = 'o';
    phrase[ 3] = 'r';
    phrase[ 2] = 'l';
    phrase[ 1] = 'd';
    phrase[ 0] = '!';
    
    // while i slides down to 0
    while ( i --\
                 \
                  \
                   >= 0 ) {
        printf("%c", phrase[i]);
    }
    printf("\n");
}

>>52860659
Many different libraries implement containers with the same name, e.g. boost::container::vector - std::vector, irr::list - std::list

It's ok to import namespaces, but for the love of god do not import them in public headers

>>52862672
I explicitly mentioned I'm importing namespaces into cpp file in my original post.

>>52862686
And I mentioned what conflicts might come from doing so

>>52862705
I use exactly the stuff I imported. If there are conflicts, I'll resolve them when they arrive. Writing less every time and having to fix a conflict that appears once in million years is better than writing unnecessary text every time.

>>52860680
Main implicitly returns 0.

>>52862279
>Analogies are used to better explain something when one is ready to believe another without questioning
That's your opinion. The point of the analogy was to show you that avoiding conflicts is not the only purpose of namespaces. Importing entire namespaces is okay in simple or limited settings, but in larger applications namespaces serve to encapsulate which is the spirit of OOP. Hence, importing entire namespaces is considered bad practice.

>>52863099
>That's your opinion.
It is not my opinion but a fact that you are not allowed to use analogy as an argument.

I asked for a practical example. All you can come up with theoretical bullshit.

>>52862284
bumping for interest

>>52863138
>It is not my opinion but a fact that you are not allowed to use analogy as an argument.
Right, in which amendment to the constitution can I read this?

Theoretical bullshit and common practice are the foundations of programming languages. OOP, and C++ in particular is based on the idea that exceptions and errors should be taken care of before they arrive. Hence, encapsulation in the form of namespaces is preferable to simply correcting conflicts when they do pop up according to C++ practice. That's why people are going to say it's bad practice when you import entire namespaces.

Whether there are practical examples or not is irrelevant. You couldn't give practical examples of errors or conflicts that would occur due to inconsistent capitalization, but it's still considered bad practice.

>>52863308
nigga what the fuck dawg

>>52863308
>You couldn't give practical examples of errors or conflicts that would occur due to inconsistent capitalization

> Std::Cout << "Hello World!"
> does not compile

There.

Bad practices are bad practiced because they are actually bad, not because a bunch of dudes you chose to blindly trust say they are.

>Right, in which amendment to the constitution can I read this?
It's simple - no one will take you seriously if you try to use analogies as basis for your argument.

>>52862284
You're accessing phrase[-1] since i-- returns i before performing --.

>>52857765

#include <stdio.h>
void main() { printf("Hello, world!\n"); } 

>>52863337
When I said inconsistent capitalization I obviously meant as a naming convention of variables and such. The confusion that it causes may cause errors, but inconsistently capitalizing variables does not in itself cause errors.

>>52863406
Oh, I do know the piratical problem with that.

I will give it to you, and you will immediately throw it back at me.

Naming your variables inconsistently will confuse the maintainer.

Yes, the "using" also has the capacity of confusing the maintainer.

I was waiting for you to come up with this reasoning, but you can't even do that.

>>52863357
right, don't know how that happened

>>52863545
Because you have => instead of >. Consider i=0, then you have while(i-- >= 0), so it enters the loop since 0 >= 0, but has already decreased i to -1.