Я искал этот сайт, и люди говорят, что вы должны избегать использования using namespace std
, Я полностью согласен. Тем не менее, как насчет using std::cin
а также using std::string
? Следует ли этого избегать или поощрять?
Я всегда знаю тип std::cin
это самый безопасный выбор, но набирать их снова и снова очень утомительно.
Тем не менее, когда вы печатаете using std::cin
и т. д. в начале файла, кажется, очень много. Например, эта простая программа для чтения и расчета оценки ученика, перед ней есть Очень много using std::
Это выглядит очень неудобно.
#include <iostream>
#include <ios>
#include <iomanip>
#include <stdexcept>
#include <vector>
using std::cin; using std::cout;
using std::istream; using std::vector;
using std::setprecision; using std::domain_error;
using std::string; using std::getline;
using std::streamsize;
istream& read_hw(istream& in, vector<double>& homework);
double grade(double mid_exam, double final_exam, \
const vector<double>& homework);
int main() {
std::string name;
std::getline(std::cin, name);
std::cout << "Hello, " + name + "!" << std::endl;
double mid_exam, final_exam;
std::cin >> mid_exam >> final_exam;
std::vector<double> homework;
read_hw(std::cin, homework);
try {
double final_grade = grade(mid_exam, final_exam, homework);
std::streamsize prec = std::cout.precision();
std::cout << "your final grade is:" << std::setprecision(3)
<< final_grade << std::setprecision(prec) << std::endl;
}
catch(std::domain_error) {
std::cout << std::endl << "No homework entered!" << std::endl;
return 1;
}
return 0;
}
std::istream& read_hw(std::istream& in, std::vector<double>& homework) {
if(in) {
homework.clear();
double x;
while(in >> x) {
homework.push_back(x);
}
}
in.clear();
return in;
}
double grade(double mid_exam, double final_exam, \
const std::vector<double>& homework) {
std::vector<double>::size_type i, size;
size = homework.size();
if(size ==0) {
throw std::domain_error("no homework grade entered!");
}
double sum = 0;
double average = 0;
for(i = 0; i < size; ++i) {
sum += homework[i];
}
average = sum/size;
return mid_exam*0.3 + final_exam*0.3 + average*0.4;
}
В учебник по питону, это говорит:
Помните, что нет ничего плохого в использовании
from Package import
! На самом деле, это рекомендуемые обозначения, если
specific_submodule
импортирующий модуль должен использовать субмодули с тем же именем из
разные пакеты.
Я хочу знать, что я должен делать в программах на С ++.
Никогда использование using namespace std;
или подобное в заголовочный файл поскольку это может вызвать всевозможные проблемы неоднозначности, которые возникают из-за пространства имен загрязнение. Если вы будете подчиняться этому правилу, то люди, которые будут включать ваши заголовки, будут вам благодарны за это. Я бы также избежал любого using std::...
в заголовках по аналогичным причинам. Учись любить больше многословия std::
нотации.
То, что вы делаете в исходном файле, в значительной степени зависит от вас. Любые рекомендации здесь в основном основаны на мнении, но лично я никогда использование using
просто для того, чтобы сохранить типизацию, а не в тех случаях, когда это неизбежно, например, возвращение затененных функций обратно в пространство имен и в метапрограммировании шаблонов.
Имхо этот вопрос скорее основан на мнении. Тем не менее, это мое мнение:
Не используйте:
using std::cin;
using std::cout;
using std::string;
или т.п. Мой аргумент довольно прост и лучше демонстрируется
using std::sort;
using std::vector;
Представьте, что у вас есть код, содержащий ошибку, и теперь вы должны ее найти. Любой используемый объект или функция, которая имеет std::
впереди очень, очень маловероятно, чтобы содержать ошибку. Таким образом, я всегда предпочитаю видеть
std::vector<double> x;
std::sort(x);
вместо
vector<double> x;
sort(x);
потому что последний требует от меня, чтобы посмотреть, что vector
а также sort
на самом деле (помните, что мы говорим на C ++, то есть это может быть буквально что угодно), просто чтобы узнать, что это std::vector
а также std::sort
, Вывод: время, которое я трачу на написание std::
каждый раз экономит мне вдвое или больше времени на отладку.
Чтобы сделать это немного менее основанным на мнении: определенный компромисс, который вы должны сделать, — удобочитаемость по сравнению с меньшим набором текста. Мнение основано на том, что вы цените больше ….