int main()
{
cout<<"hello world";
return 0;
}
I know that replace cout with std::cout will solve this problem. but if I don't want to use std:: ? ( because it's longer than cout)
I can change something in tool/complier option, and this program will run.
do you know another way?
thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, but I use Dev C++ just for ACM/ICPC regional contest. I am studying basic C++, so I use gnu C++ compiler(because it's small, free, and fast, c++ express is free, but bigger, and slower). In future, may be VS C++.NET will be my choice. May be yes, may be no. It depend on my jobs, on software..etc..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bad code, bad advice. Use of deprecated header, inappropriate include delimiters, and the namspace is there for a reason, moving it all to the global namespace is bad practice and will bite you unexpectedly.
The following is much cleaner.
//////////////////////////////////
include <iostream>
using std::cout ;
int main()
{
cout<<"hello world";
return 0;
}
//////////////////////////////////
> ( because it's longer than cout)
Frankly, that is just lazy. Learn to type, it will take you less time than debugging the subtle errors you can get from Dick's suggestion. For example, the following code fails to compile:
//////////////////////////////////
include <algorithm>
using namespace std ;
static int count ;
int main()
{
count++ ;
}
//////////////////////////////////
You tell me why!? Yes the example is contrived, but I have seen examples of this in real code, posted to this forum, more than once.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> But will using namespace make program slow down? I using Dev
> C++ in ACM/ ICPC contest, so time is a big problem
The name resolution occurs at compile time not run time, so it makes no difference at all.
Looking at the competition, I reckon that you are sweating the small stuff. It is about speed and clarity of thought and precision, not how fast you can enter code, or even how fast that code runs. Unfortunately it does not appear to make any assessment of good practice, so you may indeed benefit from sloppy standards. However you might only have to encounter one bug like the example I posted earlier to scupper your chances entirely.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you
I'm quite good at algorithm, but I'm new to Dev C++( gnu C++ compiler), so I don't know some tech...
with program
//////
include <algorithm>
using namespace std ;
static int count ;
int main()
{
count++ ;
}
///////////
just move static int count ; to int main(), and problem will be solved:
//////////
include <algorithm>
using namespace std ;
int main()
{
static int count ;
count++ ;
}
////////
about this, I read from a book about C++
Static local variables
The default storage class of variables declared within a function is auto. This means that
their scope is confined to the block in which they are declared, and also that their lifetime
is the same as that of the block. If a variable declared within a function is initialised with
e.g.
int local = 1;
Then the initial value of local will be 1 for every activation of that function. If it is not
initialised, then its initial value is undefined.
A local variable given the storage class static still has local scope, but retains its value
between successive activations of the block in which it is declared.
void fun1()
{
static int staticlocal = 1;
...
staticlocal++;
}
On the very first occasion that fun1 is called, the value of staticlocal will be 1. But for
subsequent calls staticlocal will have the value that it was last given in the body of fun1
e.g. 2 on entry at the second call, 3, 4 etc. in the above example. In other words,
staticlocal retains its value across activations of fun1 and occupies storage for the whole of
the program's execution.
Static global variables
The effect of giving a global variable or function the storage class static is to make it
inaccessible to any program unit (i.e. file) other than the one in which it is defined. In
other words, it can be accessed by any function in the file in which it is declared, but may
not be accessed from any other file, even if an external referencing declaration is given in
the other file.
The effect of static definitions at the global level in source files that have no function main
is to give the programmer of these implementation modules the ability to control the
export of both variables and functions. This is a standard requirement of a programming
language that supports the separate compilation of modules. A function of storage class
static would typically be a support function called by other functions in the same module
but required not to be accessible from another module. A global variable would be given
the storage class static to prevent access to it from any module other than the one in which
is it declared. This is known as data hiding. Items which are explictly made visible (by
declaring them in a header file) are said to be exported from the module. Note that this
mechanism could be used to prevent access to the stack and its top-of-stack indicator if the
char stack in the previous chapter were to be implemented in a separate file.
////////
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well the issue you encountered will occur in any ISO C++ compiler it is not GNU specific.
The "and problem will be solved" statement is debatable. If "count" could always have had function-local scope, then it should have. It does not solve the situation where you actually need a file scoped variable. For that simply choose a more sensible name - the broader the scope of a variable, the more specific and unique its name should be.
However, if you think at any time you need a global or function-scope variable, you should consider your design. It is probably flawed. Prefer class-scoped private member variables instead, with any necessary access functions.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BTW, I have no idea why you chose to quote a long passage from a book. My "You tell me why!? " comment was purely rhetorical, and did not demand an answer.
However if you do reference a book, it is always helpful to tell us its title/author/edition.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In first page of my book:
Department of Computing Science
Faculty of Computing & Engineering
Software Engineering
using C++
Lecture Notes
Prepared by Terry Chapman
September 1999
///////
I download this ebook from http://www.docstoc.com/docs/1950480/Software-Engineering-using-C
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not bad for free maybe, but consider the date - 1999. The ISO standard for C++ was ratified in 1998 and most compilers and literature were not even nearly 100% compliant in 1999.
Moreover Turbo C++ 3.0 which you said in another thread you had used previously was released in 1991!
Things have moved on a little since then. Since the language is now very stable, it is worth getting a new book perhaps. Bear in mind however that a new C++ standard (known currently as C++0x) will be released in 2009 (and be called C++09 presumably). Expect most of the significant changes to be in the library however rather than the language, and strong backward compatibility. Also Microsoft ar standardising C++/CLI - their extended C++ for use with the .NET framework and Common Language Runtime. Much of what C++09 will contain is already available in the Boost library.
Also, in my opinion, when learning programming, a good debugger is invaluable. Unfortunately this makes Dev-C++ a particularly poor tool to use. Which is unfortunate, because a debugger is invaluable for experienced developers too, which makes you wonder rather what it is good for! I would there fore recommend http://www.microsoft.com/express/vc/ (although many would object to my suggesting it on this forum; but it is kind of quiet around here of late!)
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
with dev C++ 4.9.9.2, this program can not run:
include "iostream.h"
int main()
{
cout<<"hello world";
return 0;
}
I know that replace cout with std::cout will solve this problem. but if I don't want to use std:: ? ( because it's longer than cout)
I can change something in tool/complier option, and this program will run.
do you know another way?
thanks
Thanks, but I use Dev C++ just for ACM/ICPC regional contest. I am studying basic C++, so I use gnu C++ compiler(because it's small, free, and fast, c++ express is free, but bigger, and slower). In future, may be VS C++.NET will be my choice. May be yes, may be no. It depend on my jobs, on software..etc..
after #include <iostream.h> and before int main(), you can add the line
using namespace std
there are advantages to specifying std::cout, without invoking the entire namespace.
Dick
using namspace std; (don't forget the semicolon) sorry
Oh, thank you, it's really simple.
But will using namespace make program slow down? I using Dev C++ in ACM/ ICPC contest, so time is a big problem
I doubt it will have any speed impact, it just raises the risk of conflicts in variables.
Wayne
Bad code, bad advice. Use of deprecated header, inappropriate include delimiters, and the namspace is there for a reason, moving it all to the global namespace is bad practice and will bite you unexpectedly.
The following is much cleaner.
//////////////////////////////////
include <iostream>
using std::cout ;
int main()
{
cout<<"hello world";
return 0;
}
//////////////////////////////////
> ( because it's longer than cout)
Frankly, that is just lazy. Learn to type, it will take you less time than debugging the subtle errors you can get from Dick's suggestion. For example, the following code fails to compile:
//////////////////////////////////
include <algorithm>
using namespace std ;
static int count ;
int main()
{
count++ ;
}
//////////////////////////////////
You tell me why!? Yes the example is contrived, but I have seen examples of this in real code, posted to this forum, more than once.
Clifford
> But will using namespace make program slow down? I using Dev
> C++ in ACM/ ICPC contest, so time is a big problem
The name resolution occurs at compile time not run time, so it makes no difference at all.
Looking at the competition, I reckon that you are sweating the small stuff. It is about speed and clarity of thought and precision, not how fast you can enter code, or even how fast that code runs. Unfortunately it does not appear to make any assessment of good practice, so you may indeed benefit from sloppy standards. However you might only have to encounter one bug like the example I posted earlier to scupper your chances entirely.
Clifford
Thank you
I'm quite good at algorithm, but I'm new to Dev C++( gnu C++ compiler), so I don't know some tech...
with program
//////
include <algorithm>
using namespace std ;
static int count ;
int main()
{
count++ ;
}
///////////
just move static int count ; to int main(), and problem will be solved:
//////////
include <algorithm>
using namespace std ;
int main()
{
static int count ;
count++ ;
}
////////
about this, I read from a book about C++
The default storage class of variables declared within a function is auto. This means that
their scope is confined to the block in which they are declared, and also that their lifetime
is the same as that of the block. If a variable declared within a function is initialised with
e.g.
int local = 1;
Then the initial value of local will be 1 for every activation of that function. If it is not
initialised, then its initial value is undefined.
A local variable given the storage class static still has local scope, but retains its value
between successive activations of the block in which it is declared.
void fun1()
{
static int staticlocal = 1;
...
staticlocal++;
}
On the very first occasion that fun1 is called, the value of staticlocal will be 1. But for
subsequent calls staticlocal will have the value that it was last given in the body of fun1
e.g. 2 on entry at the second call, 3, 4 etc. in the above example. In other words,
staticlocal retains its value across activations of fun1 and occupies storage for the whole of
the program's execution.
The effect of giving a global variable or function the storage class static is to make it
inaccessible to any program unit (i.e. file) other than the one in which it is defined. In
other words, it can be accessed by any function in the file in which it is declared, but may
not be accessed from any other file, even if an external referencing declaration is given in
the other file.
The effect of static definitions at the global level in source files that have no function main
is to give the programmer of these implementation modules the ability to control the
export of both variables and functions. This is a standard requirement of a programming
language that supports the separate compilation of modules. A function of storage class
static would typically be a support function called by other functions in the same module
but required not to be accessible from another module. A global variable would be given
the storage class static to prevent access to it from any module other than the one in which
is it declared. This is known as data hiding. Items which are explictly made visible (by
declaring them in a header file) are said to be exported from the module. Note that this
mechanism could be used to prevent access to the stack and its top-of-stack indicator if the
char stack in the previous chapter were to be implemented in a separate file.
////////
>> I'm new to Dev C++( gnu C++ compiler),
Well the issue you encountered will occur in any ISO C++ compiler it is not GNU specific.
The "and problem will be solved" statement is debatable. If "count" could always have had function-local scope, then it should have. It does not solve the situation where you actually need a file scoped variable. For that simply choose a more sensible name - the broader the scope of a variable, the more specific and unique its name should be.
However, if you think at any time you need a global or function-scope variable, you should consider your design. It is probably flawed. Prefer class-scoped private member variables instead, with any necessary access functions.
Clifford
BTW, I have no idea why you chose to quote a long passage from a book. My "You tell me why!? " comment was purely rhetorical, and did not demand an answer.
However if you do reference a book, it is always helpful to tell us its title/author/edition.
Clifford
In first page of my book:
Department of Computing Science
Faculty of Computing & Engineering
Software Engineering
using C++
Lecture Notes
Prepared by Terry Chapman
September 1999
///////
I download this ebook from http://www.docstoc.com/docs/1950480/Software-Engineering-using-C
Not bad for free maybe, but consider the date - 1999. The ISO standard for C++ was ratified in 1998 and most compilers and literature were not even nearly 100% compliant in 1999.
Moreover Turbo C++ 3.0 which you said in another thread you had used previously was released in 1991!
Things have moved on a little since then. Since the language is now very stable, it is worth getting a new book perhaps. Bear in mind however that a new C++ standard (known currently as C++0x) will be released in 2009 (and be called C++09 presumably). Expect most of the significant changes to be in the library however rather than the language, and strong backward compatibility. Also Microsoft ar standardising C++/CLI - their extended C++ for use with the .NET framework and Common Language Runtime. Much of what C++09 will contain is already available in the Boost library.
Consider: http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html for example, or depending upon your level:
http://www.cplusplus.com/doc/tutorial/
http://www.cprogramming.com/tutorial.html
Also, in my opinion, when learning programming, a good debugger is invaluable. Unfortunately this makes Dev-C++ a particularly poor tool to use. Which is unfortunate, because a debugger is invaluable for experienced developers too, which makes you wonder rather what it is good for! I would there fore recommend http://www.microsoft.com/express/vc/ (although many would object to my suggesting it on this forum; but it is kind of quiet around here of late!)
Clifford