c++ New to C++, questions on the differences of C++

[DrJohnSmitherson]

I just started learning C++ but I am not new to programming. I am reading some tutorials online and I have noticed some differences in, I assume, different versions of C++ and I just need some help understanding them.

 

Online I noticed some tutorials use "cout" and others use "std::cout".  Is the std:: the newer version of the language? Does this effect backwards compatibility or different operating systems?

 

I am using the latest Visual Studio Express from Microsoft to code my applications. For C++ projects, I can create a CLR project or a win32 console application.  From what I've read online, CLR uses .NET. This would not make the program run on Linux and and Mac right? How can I compile code to run on Win,Linux, and Mac? Is it more difficult to do than just Win? And I don't mean changing the code to deal with file paths (for example), I mean in more compiler sense (If that makes sense).

 

When I compile my win32 console application, is it compiled in a way so that it will only run on Windows? (Even if I don't use any windows specific code. What if it was just a hello world application?)

 

std::cout << "Thanks for the help!";

[astropheed Veteran]

I'm not a C++ guy but I assume cout is just in the std namespace. Do the ones that just write cout include a import of std?

[DrJohnSmitherson]

This was the main tutorial I have been using to learn the syntax

https://github.com/jesyspa/linear-cpp

 

Here a a direct link to a Hello World program where std::cout is being used

https://github.com/jesyspa/linear-cpp/blob/master/Chapter%2001%20-%20Hello%20World/main.cpp

 

This is all that was included

#include <iostream>

[astropheed Veteran]

Have you tried running hello world without explicitly using std:: ?

I'm pretty sure std is part of the iostream and I'm also pretty sure :: is a namespace operator.

 

I should learn more about C++ before I make more assumptions to try and help you, lol.

[ensiform]

The only way you would do that is if you used this:

using namespace std;

Which most people frown upon.

 

The "std" prefix is the standard C++ library.  The fact that some tutorials omit it, is that they are using precisely the line above to shorten things, or just imply that it is being used simply to save typing up the tutorial.

[astropheed Veteran]

The only way you would do that is if you used this:

using namespace std;

Which most people frown upon.

 

Ah there you go. So I was incorrect about std being a part of iostream. Which logically makes sense and I don't know why I said it.

 

C++ makes you think crazy things.

 

I assume it's frowned upon because std is a massive library? Name collisions and such?

[DrJohnSmitherson]

The only way you would do that is if you used this:

using namespace std;

Which most people frown upon.

I having the following program and it will compile and run. (Running on Windows).  Is the std::, everywhere, including when using vectors, unnecessary?

#include <iostream>


int main(){

	std::cout << "hello world";


	return 0;
}

[ensiform]

cout is part of iostream.  And you included iostream.  All of the standard C++ library stuff is part of the `std` root namespace.  You just have to include it's header to use it.  It is still necessary unless you specify the using line.

 

http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice

[simplezz]

Online I noticed some tutorials use "cout" and others use "std::cout".  Is the std:: the newer version of the language? Does this effect backwards compatibility or different operating systems?

As Astropheed suggested, std is a namespace. It's merely a qualifier that's required if don't declare 'using namespace std;' at the top of the file. We use namespaces for brevity where repeatedly typing out long qualifiers is impracticable and time consuming. The same concept exists in Java and C# for example.

 

I am using the latest Visual Studio Express from Microsoft to code my applications. For C++ projects, I can create a CLR project or a win32 console application.  From what I've read online, CLR uses .NET. This would not make the program run on Linux and and Mac right? How can I compile code to run on Win,Linux, and Mac? Is it more difficult to do than just Win? And I don't mean changing the code to deal with file paths (for example), I mean in more compiler sense (If that makes sense).

If you want cross platform C/C++, I'd suggest using Cygwin. It takes care of paths and OS details for you. Write your app against Linux, then compile it in Cygwin on Windows, or use cross compilation and do it all in Linux ;)

 

When I compile my win32 console application, is it compiled in a way so that it will only run on Windows? (Even if I don't use any windows specific code. What if it was just a hello world application?)

 

std::cout << "Thanks for the help!";

The problem is that Windows doesn't support POSIX OOTB. Linux and OS X do. Microsoft likes to do things in a non-standard way unfortunately, everything from paths to textmode delimiters are different in Windows. I've had the same problems myself. It can be quite annoying.

In terms of running native executables, of course a Windows PE won't run OOTB on Linux because Linux uses a different executable format (ELF). Unless you use Wine, you won't be able to run it on that platform.

Alternatively, you could use a write once, run anywhere language like Java. It even has its own cross platform GUI toolkit (Swing).

[DrJohnSmitherson]

cout is part of iostream.  And you included iostream.  All of the standard C++ library stuff is part of the `std` root namespace.  You just have to include it's header to use it.  It is still necessary unless you specify the using line.

 

http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice

So I SHOULD keep the std:: to prevent conflicts?

[simplezz]

So I SHOULD keep the std:: to prevent conflicts?

Unless you plan on writing your own function called cout, I wouldn't bother. It's just more typing. An alternative if you're concerned about cluttering your scope or potential conflicts is to use it locally where you find yourself repeatedly typing std:: or another namespace.

[astropheed Veteran]

Unless you plan on writing your own function called cout, I wouldn't bother. It's just more typing.

 

Kind of defeats the point of a namespace though, doesn't it? Sure when you're writing Hello World apps there is little reason not to, but, when you write large apps there is great reason to, avoiding name collisions. Yet, in small apps there is little need to avoid using it since It'd be used so minimally.

 

Sure it's a bit superfluous, but I can't see much reason not to be. That's just me though. I pretty well explicitly call all methods from their fully qualified namespace location.

 

Also "std::cout" is more self documenting then "cout". What the heck is cout? Where did it come from? These are questions I may find myself asking.

[simplezz]

Kind of defeats the point of a namespace though, doesn't it? Sure when you're writing Hello World apps there is little reason not to, but, when you write large apps there is great reason to, avoiding name collisions. Yet, in small apps there is little need to avoid using it since It'd be used so minimally.

 

Sure it's a bit superfluous, but I can't see much reason not to be. That's just me though. I pretty well explicitly call all methods from their fully qualified namespace location.

I take your point. It does reduce collisions and global clutter, and makes the code more readable. If one limits it to local scope when it can increase brevity and reduce duplication, I suppose that would be a happy medium.

 

Also "std::cout" is more self documenting then "cout". What the heck is cout? Where did it come from? These are questions I may find myself asking.

I'd hope most C++ programmers would know what 'cout' does. Although I personally prefer C's 'fprintf ( stdout, ...)' or 'printf (...)'.

[+Majesticmerc MVC]

So I SHOULD keep the std:: to prevent conflicts?

Yes. For such simple applications, 'using namespace std;' is okay, but not a best practice. It's usually used in training manuals and text books in order to ease new programmers into the language.

However, once your applications start growing in size, "using namespace std;" can be an inconvenience. For example, if you start to make use of a library that defines it's own type of string class, you can get name conflicts.

Furthermore, putting "using namespace" with ANYTHING inside a header file is generally considered bad form, because anyone who uses that header file automatically imports the namespace as well, causing major headaches, especially if the header file is part of a third party library or something.

That said, "using namespace" has scope, so you can put it inside functions, which is fine (in my opinion). e.g.

 

#include <algorithm>
void my_function(const std::string &original)
{
    using namespace std;
    transform(original.begin(), original.end(), ::toupper);
}

Notice that because we used "using namespace std" inside the function, we don't have to use "std::" in front of the transform function. This way, you get all the benefits of removing namespace noise, without potentially breaking code elsewhere in your application.

In summary:

• "using namespace std;" inside a function, fine, go ahead.
• "using namespace std;" inside a .cpp file. Still probably fine, but could cause issues if you have name clashes.
• "using namespace std;" inside a header file. Bad form, don't do it.
• When in doubt, just use "std::" in front of your standard library functions and classes (e.g. std::vector, std::map, std::set, etc).

When I compile my win32 console application, is it compiled in a way so that it will only run on Windows? (Even if I don't use any windows specific code. What if it was just a hello world application?)

 

Yes. Because C/C++ programs are compiled in advance (as opposed to things like Java and C# which will compile at runtime/install time), they are built for their target environment. This means that Windows binaries are built using the Windows binary format, and Linux binaries are build using the Linux binary format.

 

However, if you write your code in a cross-platform way, you should be able to build the same code on Windows and Linux without issue, just beware that Visual C++ is generally more lenient than clang and gcc when it comes to standards compliance, so something that compiles in Windows might not compile on gcc.

[astropheed Veteran]

I'd hope most C++ programmers would know what 'cout' does. Although I personally prefer C's 'fprintf ( stdout, ...)' or 'printf (...)'.

 

I wasn't specifically speaking of cout even though I did say it, sorry. Pretend it's anything. The self documenting comes from the fact that the namespaces give you an idea of what it is. It's much easier to discern what Assets.Doors.Unlock() does than it would be to just see Unlock().

 

Geez, I'm not very good at examples.

[Andre S. Veteran]

Sure it's a bit superfluous, but I can't see much reason not to be. That's just me though. I pretty well explicitly call all methods from their fully qualified namespace location.

Perhaps it's fine when namespaces are three characters long, but I don't think anyone would write stuff like var list = new System.Collections.Generic.List<int>(); (in C#).

 

I don't see why using namespace declarations would be bad style in source files. Header files is another matter of course.

 

The std namespace in particular is not very large, so after a while you pretty much know it by heart anyway. I don't see any real possible confusion from using unqualified "cout" or "shared_ptr" etc.

[astropheed Veteran]

Perhaps it's fine when namespaces are three characters long, but I don't think anyone would write stuff like var list = new System.Collections.Generic.List<int>(); (in C#).

 

True, I definitely don't do that. Although in my defense Generics are imported by default on new VS projects.  :)

[DrJohnSmitherson]

 

 

Yes. Because C/C++ programs are compiled in advance (as opposed to things like Java and C# which will compile at runtime/install time), they are built for their target environment. This means that Windows binaries are built using the Windows binary format, and Linux binaries are build using the Linux binary format.

 

However, if you write your code in a cross-platform way, you should be able to build the same code on Windows and Linux without issue, just beware that Visual C++ is generally more lenient than clang and gcc when it comes to standards compliance, so something that compiles in Windows might not compile on gcc.

 

I see. I have some more questions in this area because there are still some things confusing me

 

-In Visual Studio I am creating a "win32 console application" though the code is just normal C++ code. When it's compiled, it will only work on Windows right? Is there any way in VS (either by default or downloadable extension) to also compile it to work for Linux? What if I used gcc? Would something compiled with gcc on Windows, work on Windows and Linux? Or does code always need to be compiled on the corresponding operating system?

 

-Why is it called "win32 console application"? Is there specific Windows code that I could add to my program that would never compile on Linux?

 

-Also I really like using VS. I have used Eclipse for yearrrrs and I find VS (though I havent used it much yet) to be just top of line. It's so slick and fast and I just really like it. Is it okay to continue using it? Is there some way for it to use clang or gcc? Would you suggest I switch IDEs?

 

 

 

Also, thanks for all the great information everyone :)

[Max Norris]

Is there any way in VS (either by default or downloadable extension) to also compile it to work for Linux? What if I used gcc? Would something compiled with gcc on Windows, work on Windows and Linux? Or does code always need to be compiled on the corresponding operating system?

Compiled "native" code isn't portable.. the binaries are quite different across different operating systems, the API's are radically different, etc. (Barring emulation or "helpers" of course like Wine.) That said, yes you can add other compilers to Visual Studio, even GCC (local or remote on a *Nix box). Still need to recompile for each platform though, makefiles can automate that.

If you use a platform like dotNET (Mono on the other devices/systems) or Java however, or something interpreted like Python or Ruby, that's portable, compile once (if that applies) and done, plus you got a wide variety of languages to pick from too, quite a few run on both dotNET and the JVM. Of course portability goes out the window with system specific stuff like trying to do COM on Linux or trying to enumerate hardware via /dev on Windows for example.. you'll want to check for what OS the program is running and take appropriate action in those cases. If the "write once run everywhere" thing is a high priority, may want to consider one of these, save yourself a lot of time and heachache in the long run.

As far as IDE's go *shrug* that's personal preference of course.. Visual Studio (even though it's very extendible) is obviously geared around the Microsoft toolchain, but you got a lot of options regardless of which platform you're on, you don't need Visual Studio to compile for anything from Microsoft, just need Notepad and a console.. but I do agree, it's the best IDE on any OS, bar none, although I'd probably consider something else if you were going to use a different compiler.

[Andre S. Veteran]

I see. I have some more questions in this area because there are still some things confusing me

 

-In Visual Studio I am creating a "win32 console application" though the code is just normal C++ code. When it's compiled, it will only work on Windows right? Is there any way in VS (either by default or downloadable extension) to also compile it to work for Linux? What if I used gcc? Would something compiled with gcc on Windows, work on Windows and Linux? Or does code always need to be compiled on the corresponding operating system?

 

-Why is it called "win32 console application"? Is there specific Windows code that I could add to my program that would never compile on Linux?

It's called a Win32 Console Application because it references Win32 headers and libs. That has no chance of being portable ever. If you're doing native C++ I would suggest create a Visual C++ -> General -> Empty Project and adding only the references you actually need by yourself. If the references are portable then the source code may be portable...

 

... but the binaries still aren't. Even without references to Windows-specific libraries, binaries compiled for Windows will not run on any other platform. In fact, binaries compiled with Visual Studio require Visual Studio-specific runtime dlls (the famous Visual C++ runtime redistributable every game on Steam asks you to install) that sit in your Windows/system32 folder. Every OS has its own way of providing native runtime dlls. It's usually easier to compile for an OS if you're on that OS, but cross-compiling is of course possible - that's how game developers compile for various consoles for instance. It's not something that Visual Studio provides out of the box though. I couldn't help you set that up as I have no experience doing that.

 

I am using the latest Visual Studio Express from Microsoft to code my applications. For C++ projects, I can create a CLR project or a win32 console application.  From what I've read online, CLR uses .NET. This would not make the program run on Linux and and Mac right?

 

If you select CLR then you are using C++/CLI which is another language based on C++ that compiles to a mix of managed and unmanaged code. Xamarin does not support it so you can only compile that on Visual Studio, and I'm not sure if the binaries are even compatible on Mono (I would assume not). Miguel de Icaza hates C++ so you can pretty much forget about it. The purpose of C++/CLI is mainly for creating interop layers between .NET and native code. You probably don't want to use it unless you're doing exactly that. There are much more pleasant alternatives both for managed and unmanaged code.

[DrJohnSmitherson]

 

... but the binaries still aren't. Even without references to Windows-specific libraries, binaries compiled for Windows will not run on any other platform. In fact, binaries compiled with Visual Studio require Visual Studio-specific runtime dlls (the famous Visual C++ runtime redistributable every game on Steam asks you to install) that sit in your Windows/system32 folder. Every OS has its own way of providing native runtime dlls. It's usually easier to compile for an OS if you're on that OS, but cross-compiling is of course possible - that's how game developers compile for various consoles for instance. It's not something that Visual Studio provides out of the box though. I couldn't help you set that up as I have no experience doing that.

 

Thank you for all this information.

 

Is it possible to compile my source code on a Windows machine and have it run on any other Windows machine without the Visual C++ runtime redistributable? (Could I code in the VS IDE then compile the code with another compiler?) If so, what would be the advantages and disadvantages of this?

[Andre S. Veteran]

You can do that if you link the runtime statically (/MT), if this is a simple executable no one will try to link with (otherwise you get into version clashes and hell ensues) AND you're not linking with other libraries that may have conflicting runtime linking properties. So it's an option but it's not often possible, also it inflates the size of your executable.

[DrJohnSmitherson]

You can do that if you link the runtime statically (/MT), if this is a simple executable no one will try to link with (otherwise you get into version clashes and hell ensues) AND you're not linking with other libraries that may have conflicting runtime linking properties. So it's an option but it's not often possible, also it inflates the size of your executable.

Thanks!

[DrJohnSmitherson]

 

If you want cross platform C/C++, I'd suggest using Cygwin. It takes care of paths and OS details for you. Write your app against Linux, then compile it in Cygwin on Windows, or use cross compilation and do it all in Linux ;)

 

So I could develop my application as if I wanted it to run on Linux, compile it on Linux with cygwin, then compile it on Windows with cygwin, it would work on both machines? (I assume there are Linux and Windows specific things I could add to my code, so I would NOT add them in this example scenario)

[simplezz]

So I could develop my application as if I wanted it to run on Linux, compile it on Linux with cygwin, then compile it on Windows with cygwin, it would work on both machines? (I assume there are Linux and Windows specific things I could add to my code, so I would NOT add them in this example scenario)

You don't need to compile it with cygwin/mingw on Linux unless you are cross-compiling for another platform. Just use GCC, Clang, or whatever you prefer when compiling on Linux/OS X. Then if you want to also compile the same code without modification against Windows, you can use Cygwin. It basically gives you Linux shell on Windows along with helpful functions like handling paths, etc. Even things like Unix signals work on Windows with Cygwin. It's a pretty good tool if you want to write against one platform and get the others for free.

 

Things like threading (pthreads), and lots of other *nix / POSIX functionality will then be available to you. That makes it an invaluable tool for cross platform development. Having to rewrite Windows specific stuff is time consuming. It's a shame that Microsoft doesn't follow the POSIX standard.

 

https://en.wikipedia.org/wiki/Posix

[DrJohnSmitherson]

You don't need to compile it with cygwin/mingw on Linux unless you are cross-compiling for another platform. Just use GCC, Clang, or whatever you prefer when compiling on Linux/OS X. Then if you want to also compile the same code without modification against Windows, you can use Cygwin. It basically gives you Linux shell on Windows along with helpful functions like handling paths, etc. Even things like Unix signals work on Windows with Cygwin. It's a pretty good tool if you want to write against one platform and get the others for free.

 

Things like threading (pthreads), and lots of other *nix / POSIX functionality will then be available to you. That makes it an invaluable tool for cross platform development. Having to rewrite Windows specific stuff is time consuming. It's a shame that Microsoft doesn't follow the POSIX standard.

 

https://en.wikipedia.org/wiki/Posix

Thanks!