Std:: или using namespace std;

@LVV · Регистрация: 15.02.2010

Студворк — интернет-сервис помощи студентам

Вопрос к профессионалам.
Меня давно интересуют такие вопросы:
1) Почему, многим, вроде бы не безграмотным С++-шникам, в консольных приложениях вместо одной строки :
using namespace std;
нравится везде перед cout, cin, endl, string и т.п. дописывать std:: ?
Это стиль такой пространно-корявый, или есть какое-то логическое объяснение?

2) Почему даже в несложных программах многие спецы предпочитают вместо коротких имён давать переменным пространные имена?

3) Почему многие спецы для несложных программ вместо необходимых заголовочных файлов используют библиотеки "на все случаи жизни"?

Утрируя, можно сказать, что простая программа сложения двух чисел:

C++
1
2
3
4
5
6
7
8
9
10
#include <iostream>
using namespace std;
int main()
{
    int a, b, c;
    cin >> a >> b;
    c = a + b;
    cout << c << endl;
    return 0;
}

написанная руками некоторых специалистов будет выглядеть примерно так:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
#include <iostream>
int main(int argc, char* argv[])
{
    int FirstNumericalValue, SecondNumericalValue, Result;
    std::cin >> FirstNumericalValue;
    std::cin >> SecondNumericalValue;
    Result = FirstNumericalValue + SecondNumericalValue;
    std::cout << Result << std::endl;
    return 0;
}

@GbaLog- · 01.11.2017, 12:46

Сообщение от LVV

Пример отсюда

а то, что это не с++, вас не смущает?

@COKPOWEHEU · 01.11.2017, 12:52

Сообщение от LVV

Пример отсюда: https://msdn.microsoft.com/ru-... 82216.aspx

Сообщение от LVV

microsoft

О да, эти любят вводить собственные длинные имена взамен стандартных. Причем ладно бы с пользой, так нет: какой смысл вводить HANDLE вместо void*? Если бы этот HANDLE использовался для чего-то конкретного, скажем, только дескриптор окна, или файла, или процесса, а для чего-то другого - другой тип, это можно было бы понять, но когда он используется вообще для всего?
Или введение LPCSTR вместо обычного char[], не говоря уж о всяких DWORDLONG, который на самом деле uint64_t
Ну и куда же без десятка параметров для простейшей функции вроде открытия файла.
В результате вызов одной функции растягивается на несколько строк без всякой надобности и с проблемами чтения.

Nishen · 01.11.2017, 14:20

Сообщение от COKPOWEHEU

LPCSTR

Ни читать, ни писать такое не удобно. :-(

@Valeryn · 02.11.2017, 08:52

Сообщение от COKPOWEHEU

Или введение LPCSTR вместо обычного char[], не говоря уж о всяких DWORDLONG, который на самом деле uint64_t

мне кажется, это наследство Си.
Все таки winAPI - это Си, а не С++.
Текст в верхнем регистре - видимо во избежания пересечения имен. Делали в своем стиле, что бы гарантированно минимизировать конфликты с чужим ПО.
Да и что делать, если после обновления стандарта, char станет 16 бит? или если я начну компилить свою прогу на компиляторе, у которого разрядность char иная? Для этого и нужен макрос. Он должен проверить компилятор и выставить нужный define

а вот LPCSTR или lpcstr - в обоих случаях, я считаю эту конструкцию не читабельную. Хотя как просил человек выше - она соотвествует нужной идеалогии.

C++
1
DWORDLONG

А у тебя есть гарантии, что unit64_t будет существовать/работать в 32 бит ОС?
Макрос для этого и делают. Что бы не менять код, в случае смены разрядности ОС.

Вот яркий пример из моей практики, на случай, если char будет не равен одному байту.

C++
1
2
3
4
5
#if CHAR_BIT_ == 8
#   define byte_ char
#else
/*...*/
#endif

Croessmah · 02.11.2017, 12:54

Сообщение от Valeryn

если char будет не равен одному байту.

char - всегда один байт.
Другое дело, что байт может быть не 8 бит.

@COKPOWEHEU · 02.11.2017, 13:08

Сообщение от Valeryn

Да и что делать, если после обновления стандарта, char станет 16 бит?

Разработчики стандарта не дураки так ломать совместимость. Если надо увеличить размер char введут новый тип вроде wchar.

Сообщение от Valeryn

А у тебя есть гарантии, что unit64_t будет существовать/работать в 32 бит ОС?

Он даже под 8-битные архитектуры существует. И, кажется, входит в стандарт. В отличие от.

Сообщение от Valeryn

Вот яркий пример из моей практики, на случай, если char будет не равен одному байту.

Лучше бы вы привели ситуацию, когда char не равен 1 байту, а не пример ее обхода.

@Valeryn · 02.11.2017, 15:23

Сообщение от COKPOWEHEU

Разработчики стандарта не дураки так ломать совместимость. Если надо увеличить размер char введут новый тип вроде wchar.

Сообщение от Croessmah

char - всегда один байт

Кстати да, но если память меня не подводит, то все звучит так, не?)
char <= short <= int <= long

Сообщение от COKPOWEHEU

Он даже под 8-битные архитектуры существует. И, кажется, входит в стандарт. В отличие от.

в С89 его нет. Появился он с С99 версии стандарта.
А Visual Studio только С89 поддерживает кстати

Хоть и имеет stdint.h

Все эти макросы не по приколу придуманные)
В том де Qt в qglobal.h много подобного.

C++ (Qt)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#if defined(QT_COORD_TYPE)
typedef QT_COORD_TYPE qreal;
#elif defined(QT_NO_FPU) || defined(QT_ARCH_ARM) || defined(QT_ARCH_WINDOWSCE) || defined(QT_ARCH_SYMBIAN)
typedef float qreal;
#else
typedef double qreal;
#endif
#if defined(Q_OS_WIN) && !defined(Q_CC_GNU) && !defined(Q_CC_MWERKS)
#  define Q_INT64_C(c) c ## i64    /* signed 64 bit constant */
#  define Q_UINT64_C(c) c ## ui64   /* unsigned 64 bit constant */
typedef __int64 qint64;            /* 64 bit signed */
typedef unsigned __int64 quint64;  /* 64 bit unsigned */
#else
#  define Q_INT64_C(c) static_cast<long long>(c ## LL)     /* signed 64 bit constant */
#  define Q_UINT64_C(c) static_cast<unsigned long long>(c ## ULL) /* unsigned 64 bit constant */
typedef long long qint64;           /* 64 bit signed */
typedef unsigned long long quint64; /* 64 bit unsigned */
#endif

@COKPOWEHEU · 02.11.2017, 22:07

Сообщение от Valeryn

А Visual Studio только С89 поддерживает кстати Хоть и имеет stdint.h

Если так уж хочется поддерживать совместимость со всякой древностью, можно и переопределить эти типы.

Сообщение от Valeryn

В том де Qt в qglobal.h много подобного.

А еще в OpenGL есть glint, glfloat и прочие. Но это кроссплатформенные системы, вынужденные поддерживать совместимость с разнообразными компиляторами и стандартами. Да и сами имена в них ненамного длиннее стандартных (если вспомнить с чего началась дискуссия).

Croessmah · 02.11.2017, 22:33

COKPOWEHEU, типы intN_t/uintN_t являются необязательными к реализации в C99 (C11 под рукой нет).
В C++11/14 типы intN_t/uintN_t также являются опциональными.

@Valeryn · 03.11.2017, 15:33

Сообщение от COKPOWEHEU

Если так уж хочется поддерживать совместимость со всякой древностью, можно и переопределить эти типы.

Это я все к тому веду, что специальные типы майкрософт не по приколу ввела, а как раз таки для переопределения его и обратной совместимости.

Ведь где гарантии, что твое ПО через N версий будет совместимо с dll виндой, из за того что за место DWORD ты юзал uint64_t в winAPI? В итоге придется перелопачивать весь код.
Конечно это мало вероятно, что размер слова внезапно вырастит или уменьшиться, но все же.

Сообщение от COKPOWEHEU

(если вспомнить с чего началась дискуссия).

Я начал по поводу своего не согласия с твоим высказыванием

LPCSTR вместо обычного char[], не говоря уж о всяких DWORDLONG, который на самом деле uint64_t

@COKPOWEHEU · 03.11.2017, 16:08

Сообщение от Valeryn

Ведь где гарантии, что твое ПО через N версий будет совместимо с dll виндой, из за того что за место DWORD ты юзал uint64_t в winAPI? В итоге придется перелопачивать весь код.

Только платформо-зависимую часть, которая в хороших программах вынесена отдельно как раз для таких случаев. А там да, придется либо городить костыли, либо переделывать отдельные модули.
И, между прочим, это лучше, чем переделывать всю остальную, платформо-независимую, часть только из-за того что DWORD изменился.

Сообщение от Valeryn

Я начал по поводу своего не согласия с твоим высказыванием

LPCSTR вместо обычного char[], не говоря уж о всяких DWORDLONG, который на самом деле uint64_t

...которое было примером неоправданно длинных названий. Или будешь утверждать что нельзя было назвать покороче? Хотя бы u64, которое тоже нестандартное, но короткое и ясное.

Добавлено через 15 секунд

Сообщение от Valeryn

Ведь где гарантии, что твое ПО через N версий будет совместимо с dll виндой, из за того что за место DWORD ты юзал uint64_t в winAPI? В итоге придется перелопачивать весь код.

Только платформо-зависимую часть, которая в хороших программах вынесена отдельно как раз для таких случаев. А там да, придется либо городить костыли, либо переделывать отдельные модули.
И, между прочим, это лучше, чем переделывать всю остальную, платформо-независимую, часть только из-за того что DWORD изменился.

Сообщение от Valeryn

Я начал по поводу своего не согласия с твоим высказыванием

LPCSTR вместо обычного char[], не говоря уж о всяких DWORDLONG, который на самом деле uint64_t

...которое было примером неоправданно длинных названий. Или будешь утверждать что нельзя было назвать покороче? Хотя бы u64, которое тоже нестандартное, но короткое и ясное.

Новые блоги и статьи Все статьи Все блоги /
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .
Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .

Croessmah Неэпический 18144 / 10728 / 2066 Регистрация: 27.09.2012 Сообщений: 27,026 Записей в блоге: 1
	02.11.2017, 22:33
	COKPOWEHEU, типы intN_t/uintN_t являются необязательными к реализации в C99 (C11 под рукой нет). В C++11/14 типы intN_t/uintN_t также являются опциональными. 0