The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Утверждён стандарт C++17, opennews (ok), 08-Сен-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


11. "Утверждён стандарт C++17"  +1 +/–
Сообщение от Заморашка (?), 08-Сен-17, 02:06 
Поддержу. Пишу сейчас на Си+Python. Вот когда стал использовать Питон, ощутил всю ущербность плюсов, и лаконичную чистоту Си. Для Си нужно знасть только арифметику указателей и основы языка - всё остальное в твоих руах, и не надо копать в недра всяких там глубокомысленных терминов, без знания которых плюсы бесполезны. А оно надо, если то же самое можно сделать на Си, не задавая никому никаких вопросов. А для гуев и веба Питон - тоже чисты и простой - всегда в помощь.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

14. "Утверждён стандарт C++17"  +15 +/–
Сообщение от all_glory_to_the_hypnotoad (ok), 08-Сен-17, 02:12 
> Для Си нужно знасть только арифметику указателей и основы языка

О какой сказочный дурачок. Тебя ещё ждёт много удивительных открытий.

Ответить | Правка | Наверх | Cообщить модератору

15. "Утверждён стандарт C++17"  +/–
Сообщение от Аноним (-), 08-Сен-17, 02:13 
покажи ка, что ты там пишешь
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

17. "Утверждён стандарт C++17"  –1 +/–
Сообщение от Krozemail (ok), 08-Сен-17, 02:30 
Я Си уважаю, честно.

Но однажды, написав несложную программку (500-1000 строк), я решил, что, коль почти все функции могут вернуть ошибку, то неплохо бы ошибки таких функций корректно обрабатывать (логирование, корректный выход из вызывающей функции с ошибочным кодом возврата и т. п.). Даже если вероятность ошибки мала. Ну то есть для всех функций, даже для printf...

После этого я предпочитаю C++, а Си использую в разве что когда работаю с чужими исходниками.

Кто не понял что произошло, рекомендую повторить мой эксперимент.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

18. "Утверждён стандарт C++17"  +/–
Сообщение от saahriktu (ok), 08-Сен-17, 02:50 
Чрезмерное отслеживание ошибок далеко не всегда нужно. Важно чтобы сохранялась нужная логика программы. А не всякая ошибка на неё влияет. Например, printf() возвращает число напечатанных символов, и в случае ошибки вывода оно отрицательное. А откуда ошибка вывода? Ну, допустим, отвалился терминал. Ну и что? Если программа не просто ведёт диалог с юзером, а выполняет какую-то работу в фоне, то она спокойно может продолжать делать то, что нужно.

Если же отслеживание ошибок очень критично, то надо просто изначально разбивать программу рекурсивно. Написать процедуру вывода, которая тщательно отслеживает ошибки, и отовсюду обращаться к ней. И т.д. А выполнение одной и той же работы в сотнях мест исходника можно сравнить с написанией сотен операторов вместо использования for.

Ответить | Правка | Наверх | Cообщить модератору

30. "Утверждён стандарт C++17"  +3 +/–
Сообщение от Sw00p aka Jerom (?), 08-Сен-17, 04:30 
>>Чрезмерное отслеживание ошибок далеко не всегда нужно.

простите, не соглашусь - на ошибках учатся! - Просто автор выше хотел сказать, что нет в языке "удобной" (однозначной) так называемой "обработки ошибок" (практики, методологии), а как обычно принято ? из вашего утверждения следует - не нужны лишние проверки, свалится ПО, берите корку и с лупой под отладчиком. Не ленитесь даже "нормально" работающую программу под отладчиком пропускать не говорю уже о профайлере.

>>Важно чтобы сохранялась нужная логика программы.

х*як, х*як и в продакшен )) стол перевернулся


Ответить | Правка | Наверх | Cообщить модератору

55. "Утверждён стандарт C++17"  –3 +/–
Сообщение от saahriktu (ok), 08-Сен-17, 09:51 
Дебажить надо в первую очередь логику, а не вызовы библиотечных функций. Ошибка скорее всего будет именно в ней. А для этого на время отладки нужно подробнее исследовать те данные, которыми манипулирует программа. Можно отладчиком, можно через временно добавленные вызовы библиотечных функций ряда printf(), puts() и putchar().

Можно, конечно, наезжать на грабли как следствие некорректных данных. И многие проверки, особенно в случаях библиотечных функций, связаны именно с этим. Однако, можно и не наезжать. Программы, юзеры и наборы входных данных бывают разные. Можно, конечно, писать такой софт, который у любого юзера на любых данных будет надёжным как танк. А можно и дисциплинировать юзеров. Ввёл некорректные данные - ССЗБ, надо было думать что вводишь. Защита от дурака нужна только когда есть этот самый дурак. А если писать софт для аудитории из грамотных и внимательных юзеров, то многие проверки можно опустить. В общем, подходы бывают разные.

Ну и, да, многое зависит ещё от того, какой именно это софт.

Ответить | Правка | Наверх | Cообщить модератору

88. "Утверждён стандарт C++17"  +1 +/–
Сообщение от Sw00p aka Jerom (?), 08-Сен-17, 13:07 
>>Можно, конечно, писать такой софт, который у любого юзера на любых данных будет надёжным как танк.

Не можно, а нужно! Как по вашему, можно ли писать код для адронного коллайдера исходя из вашей логики (выше приведённого утверждения о не обязательности написания абсолютно безошибочного кода)?

>>А можно и дисциплинировать юзеров. Ввёл некорректные данные - ССЗБ, надо было думать что вводишь.

в программировании понятие "предположить" для меня лично не приемлемо, нельзя и не нужно предполагать, что данные не кривые, что руки у юзера нормальные, что сторонняя библиотечная функция работает безошибочно и всё такое (не говорю ещё про безопасность).

>>А если писать софт для аудитории из грамотных и внимательных юзеров, то многие проверки можно опустить. В общем, подходы бывают разные.

"Нормальных" нет, действовать нуно от противного, скептически ко всему относится. Говоря о подходе приведу не совсем удачный пример по этому поводу. Представьте себе такую картину - вызов библиотечных функция открыть, прочитать/записать, закрыть. Исходя из моей логики код будет выглядеть на подобии этого:

1) переменная1 = открыть(что-то)
2) проверить открыт ли "что-то"
3) записать/прочитать(переменная1, что-то)
4) проверить записалось/прочиталось "что-то"
5) закрыть(переменная1) "что-то" (от случая - ещё проверить открыто что-либо или нет)

исходя из вашей же логики будет так:

1) переменная1 = открыть(что-то)
2) записать/прочитать(переменная1, что-то)
3) закрыть(переменная1) "что-то"

а вот пример как избежать обоих вариантов:

1) записать/прочитать_туда-то_что-то(туда-то, что-то)
2) проверить результат

но как видно это банальный враппер на выше перечисленные отдельные функции, всё равно даже внутри этого враппера нам необходимо проверить все три условия (открытия, записи/чтения, закрытия) - что и требовалось доказать.

Ответить | Правка | Наверх | Cообщить модератору

94. "Утверждён стандарт C++17"  –2 +/–
Сообщение от saahriktu (ok), 08-Сен-17, 13:37 
Кто говорил про полное отсутствие проверок? Я говорю о том, что аудитории софта бывают разные, и про это даже учат в ВУЗах. Один из преподавателй того ВУЗа, где я учился, как положительный пример приводил программиста, который для себя писал программы из десятка строк, в которых кроме него никто ничего не понимал. Ну так вот. Не со всяким софтом взаимодействуют сотни и тысячи юзеров. Не всякий софт работает часами без остановки. Есть локальные аудитории юзеров из 3,5 штук. Есть фильтры командной строки. И т.д.

Можно, конечно, писать так
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
        long int a2, al;
        char *buf;
        if (argc < 4) {
                printf("usage: leftpad string width char\n");
                return 1;
        }
        a2 = atol(argv[2]);
        al = a2 - strlen(argv[1]);
        if (al < 1) {
                printf("%s\n", argv[1]);
                return 0;
        }
        buf = (char *)malloc(a2 + 1);
        if (buf == NULL)
                return 1;
        memset(buf, argv[3][0], al);
        buf[al] = '\0';
        printf("%s\n", strcat(buf, argv[1]));
        free(buf);
        return 0;
}

Но, можно и так, исходя из предпосылки, что возникновение любой внештатной ситуации уже само по себе "всё, приехали" (например, откуда внезапно закончится оперативка если на машине её 8 гигов и за пределы сотни-другой мегабайт её использование обычно не выходит?):
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

char *buf;

char *leftpad(char *str, unsigned int len, char ch){
        unsigned int i;
        buf = (char *) malloc ((len + 1 + strlen(str)) * (sizeof(char));
        for(i = 0; i < len; i++) buf[i] = ch;
        return strcat(buf, str);
}

int main(int argc, char **argv){
        if(argc < 4){
                printf("usage: leftpad string length char\n");
                return 1;
        }
        unsigned int al = (unsigned int) atol(argv[2]);
        printf("%s\n", leftpad(argv[1], al, argv[3][0]));
        free(buf);
        return 0;
}

Про более простые случаи вообще молчу.
#include <stdio.h>

char bcharz[] = " !@$^&*|=()[]\\:;\"\'<>,?{}";

int main(){
        char c, bci;
        while((c = getchar()) != EOF){
                for(bci=0; bci < 24 ; bci++) if (bcharz[bci] == c) putchar ('\\');
                putchar(c);
        }
}

Ответить | Правка | Наверх | Cообщить модератору

109. "Утверждён стандарт C++17"  +/–
Сообщение от angra (ok), 08-Сен-17, 17:44 
> Один из преподавателй того ВУЗа, где я учился, как положительный пример приводил
> программиста, который для себя писал программы из десятка строк, в которых
> кроме него никто ничего не понимал.

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

> Ну так вот. Не со всяким софтом взаимодействуют сотни и тысячи юзеров. Не всякий софт работает часами без остановки. Есть локальные аудитории юзеров из 3,5 штук.

Это называется не софт, а костыли. Используют их, когда нужно временное грубое решение или вообще предполагается однократный запуск. Крайний, но очень часто использумый вариант - однострочник на perl. Если же костыль продолжает регулярно использоваться, то умные люди его со временем заменяют на нормальное решение. Ну а дураки создают и лелеют десятилетиями системы из костылей и подпорок. Вот только пример дураков это как НЕ надо делать.

Ответить | Правка | Наверх | Cообщить модератору

114. "Утверждён стандарт C++17"  –3 +/–
Сообщение от Sw00p aka Jerom (?), 08-Сен-17, 18:06 
>> Ну а дураки создают и лелеют десятилетиями системы из костылей и подпорок.

ну а вся причина в чём ? в том, что в среде Си программистов оч мало бест практисов, оч много небезопасных функций и тд, если в стандартной библиотеке Си не проверяют длину массива или строки, то что ждать от обычного новичка изучающий этот язык ? Вот в С++ немного не так, там есть более-менее нормальный еррор хендлинг, всякие траи с катчами и эксцепшенами есть какойта бест практис в виде шаблонов проектирования а в С всего этого нет, вот и появляются такие утверждения, что всё подряд проверять не нужно. Отсюда и такие программисты, думаю во многом большое влияние на мышление программисты играет именно используемый язык, Си-шнику дайте какой нить Erlang (функциональщина) у него он вызовет отторжение, потомучто мышление сформированно под С. (хотя девиз ирленга - лет ит креш - типа пусть падает если есть ошибка - https://ru.hexlet.io/courses/erlang_101/lessons/practical_er...

Ответить | Правка | Наверх | Cообщить модератору

118. "Утверждён стандарт C++17"  –1 +/–
Сообщение от saahriktu (ok), 08-Сен-17, 18:50 
нет, преподавателю непонравился уровень сложности моей программы, и он начал говорить, что совсем необязательно так всё усложнять, вон, люди софт в десятки строк пишут.

Следует различать софтовые комбайны, которые молотят байты под высокой нагрузкой, и всё остальное. А обычный режим юзания софта, про который я говорю, такой: юзеру понадобилось решить какую-то задачу, он "дёрнул за верёвочку", запустился конвейер бинарников и скриптов, который всё обработал и выплюнул ему результат, а затем завершился. Всё. Можно рассматривать и другие режимы юзания софта, например, десктопный, где юзер запустил рано утром какой-нибудь CAD или офисный пакет, и сидит там целый день без большой нагрузки на систему. Но, это уже другое.

Ещё раз повторяю, что я говорил даже не про десктопные комбайны, и не про то, что 365 дней в году молотит байты или следит за датчиками. Это, конечно, нужно дебажить, и очень-очень тщательно.

Но, этим ничего ни разу не ограничивается. Есть юниксвей и куча маленьких бинарников, которые склеиваются в конвейеры, которые вызываются при необходимости, пайпами. И тут уже совсем не обязательно перехватывать ошибки библиотечных функций как при ядерной войне.

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

144. "Утверждён стандарт C++17"  +/–
Сообщение от Orduemail (ok), 10-Сен-17, 05:28 
> Один из преподавателй того ВУЗа, где я учился, как положительный пример приводил
> программиста, который для себя писал программы из десятка строк, в которых
> кроме него никто ничего не понимал.
> нет, преподавателю непонравился уровень сложности моей программы, и он начал говорить, что совсем необязательно так всё усложнять, вон, люди софт в десятки строк пишут.

Эмм... Правильно ли я понял: препод посмотрел на переусложнённую программу, и начал распинаться о том, что есть "умельцы", которые из программы в десять строк могут сделать нечитаемое г-но? Если так, то по-моему, это как раз пример того, как не надо. Собственно ты можешь проверить это моё предположение, порывшись в своей памяти. Если я прав, препод обязательно должен был пройтись по тому, насколько эти программы в десять строк неудобны для других. Ещё, вероятно, если он препод с опытом программирования, он мог упомянуть о том, что программист через месяц становится _другим_, в том смысле что он смотрит на свою программу как баран на новые ворота, и никак не может понять, что это за нелепые буквы вообще и какой идиот их написал.
Нужно неоднократно столкнуться с этой ситуацией, для того чтобы обрести скилл, позволяющий программисту писать программы, которые будут поняты ему через месяц. Это умение писать программы, которые проще понять, чем написать заново.

Ответить | Правка | Наверх | Cообщить модератору

33. "Утверждён стандарт C++17"  +3 +/–
Сообщение от Аноним (-), 08-Сен-17, 06:27 
> Чрезмерное отслеживание ошибок далеко не всегда нужно
> Все символы UTF-8 далеко не всегда нужны, можно и КОИ8-Р
> Физика далеко не всегда нужна, можно и ОБЖ ограничиться
> Крыша над головой далеко не всегда нужна, можно и на голой земле спать
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

51. "Утверждён стандарт C++17"  +3 +/–
Сообщение от EHLO (?), 08-Сен-17, 09:24 
> Крыша над головой далеко не всегда нужна, можно и на голой земле спать

Ты что?! Крыша всегда нужна. Выходя из дома, обязательно возьми с собой крышу.

Ответить | Правка | Наверх | Cообщить модератору

113. "Утверждён стандарт C++17"  –2 +/–
Сообщение от Анонимный Алкоголик (??), 08-Сен-17, 18:04 
> А выполнение одной и той же
> работы в сотнях мест исходника можно сравнить с написанией сотен операторов
> вместо использования for.

Вот это к сожалению и происходит в C.
Когда по ходу выясняется, что практически каждая функция может закончиться ошибкой. В итоге любая операция (хуже всего что и встроенные - сложения, умножения (и в C++ это тоже)), вызов функции - это заодно и очередной часто нетривиальный кусок кода проверки ошибки.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

149. "Утверждён стандарт C++17"  +/–
Сообщение от Аноним (-), 11-Сен-17, 11:11 
А потом ругают си , что память течет и дыры
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

45. "Утверждён стандарт C++17"  +/–
Сообщение от Аноним (-), 08-Сен-17, 09:09 
> Но однажды, написав несложную программку (500-1000 строк), я решил, что, коль почти
> все функции могут вернуть ошибку, то неплохо бы ошибки таких функций
> корректно обрабатывать

Это называется на "написал" а "слепил по-быстрому прототип".

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

63. "Утверждён стандарт C++17"  –1 +/–
Сообщение от pripolz (?), 08-Сен-17, 11:09 
Обработка ошибок нужна всегда.

> неплохо бы ошибки таких функций корректно обрабатывать (логирование, корректный выход из вызывающей функции с ошибочным кодом возврата и т. п.).

В макрос обернул, и всё. CHK( my_func() == ok , MY_FUNK_FAILED )
Один макрос на все проекты.
С++ ники такие тоже используют кстати, просто вместо goto error внутри пишут throw.

-----------

теперь представь картину: вот смотришь ты на кусок кода. В нём вызывается 10 функций, а ещё выделяется память. Ты понимаешь, что любая из функций может бросить эксепшн, что потенциально приведёт к утечке памяти, если только это не отслеживать исключительно внимательно, изворачиваясь с дополнительными конструкциями кода.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

21. "Утверждён стандарт C++17"  –1 +/–
Сообщение от volodjaemail (?), 08-Сен-17, 02:54 
> Поддержу. Пишу сейчас на Си+Python. Вот когда стал использовать Питон, ощутил всю
> ущербность плюсов, и лаконичную чистоту Си. Для Си нужно знасть только
> арифметику указателей и основы языка - всё остальное в твоих руах,
> и не надо копать в недра всяких там глубокомысленных терминов, без
> знания которых плюсы бесполезны. А оно надо, если то же самое
> можно сделать на Си, не задавая никому никаких вопросов. А для
> гуев и веба Питон - тоже чисты и простой - всегда
> в помощь.

пока другие изобретают новый язык в с++ просто апдейтят стандарт и все снова пишут на плюсах )))

кстате щас пишу свой фреймворк на котором можно будет легко (100-500 строк) сделать web 2.0 страницу (webassembly, socket server c10k)

щас с++ уже почти как ява по синтаксису без рефлексии только быстрей )

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

29. "Утверждён стандарт C++17"  +3 +/–
Сообщение от Онаним (?), 08-Сен-17, 03:37 
А нормальный полноценный юникодный строковый тип в С/С++ уже изобрели?
Ответить | Правка | Наверх | Cообщить модератору

32. "Утверждён стандарт C++17"  –3 +/–
Сообщение от volodjaemail (?), 08-Сен-17, 05:26 
> А нормальный полноценный юникодный строковый тип в С/С++ уже изобрели?

)) да вроде давно уже std::string, std::wstring

Ответить | Правка | Наверх | Cообщить модератору

56. "Утверждён стандарт C++17"  +3 +/–
Сообщение от Andrey Mitrofanov (?), 08-Сен-17, 10:00 
>> А нормальный полноценный юникодный строковый тип
> )) да вроде давно уже std::string, std::wstring

Это же _два_ типа??

Ответить | Правка | Наверх | Cообщить модератору

81. "Утверждён стандарт C++17"  +/–
Сообщение от Аноним (-), 08-Сен-17, 12:21 
В С++ никак не определятся с тем, что они хотят слепить.

С одной стороны наследуют идею Си что это надстройка над асмом. С другой - пытаются внедрить функционал интерпритаторов.

Для первых характерно явное управление типами и размерами переменных в памяти. Для вторых - свобода творчества вроде отрицательных индексов в массивах и обращения по индексу больше, чем размер массива без ошибки (массив расширяется или зацикливается).

Ответить | Правка | Наверх | Cообщить модератору

96. "Утверждён стандарт C++17"  –2 +/–
Сообщение от Аноним (-), 08-Сен-17, 14:10 
> В С++ никак не определятся с тем, что они хотят слепить.

А вы, конечно, давно определись с тем что вы "лепите" (см. ниже).

> С одной стороны наследуют идею Си что это надстройка над асмом.

В соседней новости по LLVM про "надстройку над асмом" тоже вы писали?

> С другой - пытаются внедрить функционал интерпритаторов.

Что в вашем понимании "характерно" для интерпрИтаторов, вы написали ниже, а вот интересно, как вы понимаете "функционал интерпрИтаторов"?

> Для первых характерно явное управление типами и размерами переменных в памяти.

То есть характерность "надстроек над асмом" вы понимаете именно так.
И что по-вашему означает "управление типами"?

Интересно, а как по-вашему будет выглядеть "не-надстройка над асмом"?
А, ну да - интерпрИтатор.

> Для вторых - свобода творчества вроде отрицательных индексов в массивах и обращения по индексу больше,

По-вашему это характерно исключительно для интерпрИтаторов

> чем размер массива без ошибки (массив расширяется или зацикливается).

Да что вы говорите! ИнтерпрИтаторы даже такое умеют! И вам удалось понять, как массивы не только расширяются, но и зацикливаются! Интересно, а как "зацикленный" массив существует по-вашему в памяти?

Ответить | Правка | Наверх | Cообщить модератору

98. "Утверждён стандарт C++17"  +/–
Сообщение от Аноним (-), 08-Сен-17, 14:40 
Последняя фраза единственная на которую стоит ответить, потому что она объясняет всё остальное.

В ЯВУ программист не занимается управлением памятью. Сравни типы данных и угадай ЯП:
- целое длиной 1 байт
- целое длиной 2 байта
- целое длиной 4 байта
- дробное длиной 4 байта
- дробное длиной 8 байт

А теперь сравни с этим ЯП:
- число
- строка

В этом суть. Не нужно читать книги в духе "1001 способ создать пустую юникод строку" или "100 способов найти длину строки". Он один. Простым вещам простые решения. Мозгоклюям - С++.

Ответить | Правка | Наверх | Cообщить модератору

132. "Утверждён стандарт C++17"  –1 +/–
Сообщение от Аноним (-), 09-Сен-17, 10:10 
А теперь перечитайте диалог с начала, и сами попытайтесь понять, что вы хотели сказать.
Особенно, в чем по-вашему проблема с С++, кроме вашей проблемы, что вы его не знаете, и пытаетесь найти эму оправдаение.
)))

Ну нравятся вам "интерпрИтаторы", так кто вам мешает?

И многие из тех, кто владеют С++, обычно умеют сочетать его с каким-либо из тех ЯП, в области которых вы тут попытались блеснуть познаниями.

Другое дело, что вы не знаете ни С++, ни о других языках без ошибок рассуждать не можете, путаетесь в понятиях и терминологии.

Ответить | Правка | Наверх | Cообщить модератору

142. "Утверждён стандарт C++17"  +/–
Сообщение от Димон (??), 09-Сен-17, 21:50 
>[оверквотинг удален]
> - целое длиной 2 байта
> - целое длиной 4 байта
> - дробное длиной 4 байта
> - дробное длиной 8 байт
> А теперь сравни с этим ЯП:
> - число
> - строка
> В этом суть. Не нужно читать книги в духе "1001 способ создать
> пустую юникод строку" или "100 способов найти длину строки". Он один.
> Простым вещам простые решения. Мозгоклюям - С++.

А на си и плюсах это

целое длиной хз сколько байт (где байт хз сколько бит)
целое 2 длиной хз сколько байт
целое 3 длиной хз сколько байт
знаковое целое неизвестного формата длиной хз сколько байт с пачкой UB на базовых операциях
знаковое целое 2 неизвестного формата длиной хз сколько байт с пачкой UB на базовых операциях
знаковое целое 3 неизвестного формата длиной хз сколько байт с пачкой UB на базовых операциях

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

143. "Утверждён стандарт C++17"  +/–
Сообщение от Аноним (-), 09-Сен-17, 23:22 
> А теперь сравни с этим ЯП:
> - число
> - строка

Что-то не припомню я ни одного ЯП, в котором можно было работать с подобными типами, совсем не задумываясь об их внутреннем представлении. Если целые хранятся иначе, чем числа с плавающей точкой, при операциях над ними может потребоваться преобразование. Если используются только числа с плавающей точкой, то есть ограничения на точность. Если ширина целых чисел фиксирована, то возможно переполнение. И так далее.

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

154. "Утверждён стандарт C++17"  +1 +/–
Сообщение от Анонйм (?), 13-Сен-17, 06:27 
Про строки - это да, но целые и дробные определённых длин (а ещё точные дробные (decimal) и куча других типов) есть и в Java, и в C#, и в Python, например. Что-то вообще даже не знаю в каком это языке только один числовой тип. Bash какой-нибудь что ли?

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

129. "Утверждён стандарт C++17"  –2 +/–
Сообщение от volodjaemail (?), 09-Сен-17, 05:26 
> В С++ никак не определятся с тем, что они хотят слепить.
> С одной стороны наследуют идею Си что это надстройка над асмом. С
> другой - пытаются внедрить функционал интерпритаторов.
> Для первых характерно явное управление типами и размерами переменных в памяти. Для
> вторых - свобода творчества вроде отрицательных индексов в массивах и обращения
> по индексу больше, чем размер массива без ошибки (массив расширяется или
> зацикливается).

я думаю исходят из простых практических соображений поэтому язык мультипарадигменный
вот думаю что с массивами действительно было бы не плохо сделать зацикливание индексов как в питоне, но для этого и не надо ничего менять можно просто класс написать c++, с размерами переменных то же самое хочешь управляй (std типы), хочешь не управляй (типы компилятора)

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

145. "Утверждён стандарт C++17"  –1 +/–
Сообщение от Аноним (-), 10-Сен-17, 07:07 
Посмотри путь ЯП:
- асм
- язык Си - ускоренное программирование с простым синтаксисом
- С++ - добавили классы

И стоп-игра. Почему???

То, что можно лопатой вскопать 10 га не означает что не нужен трактор. Он нужен, это квантовый скачок, который сразу переводит тебя на новый уровень.

Новый уровень (уже старый и давно всеми пройденный) - это отказ от управления памятью. Это юникод, сетевые технологии и параллельные вычисления.

А сегодняшние вызовы - это библиотека графических примитивов. Не printf для вывода в консоль (шёл 21 век!!!!!!), а оконные интерфейсы. Я не говорю что это просто, но кому-то придётся стандартизировать этот зоопарк API в ОС. Это возможность выполнения кода в разных ОС и на разных платформах без перекомпиляции.

И не нужно после этого удивляться популярности java и net. Они взяли синтаксис и уверено идут вперёд. А С++ везут в гробу на кладбище истории чтобы зак-пать рядом с ассемблером.

PS: слово "зак-пал" в списке матерных???? Я что-то пропустил?

Ответить | Правка | Наверх | Cообщить модератору

146. "Утверждён стандарт C++17"  –1 +/–
Сообщение от volodjaemail (?), 10-Сен-17, 15:33 
>[оверквотинг удален]
> управления памятью. Это юникод, сетевые технологии и параллельные вычисления.
> А сегодняшние вызовы - это библиотека графических примитивов. Не printf для вывода
> в консоль (шёл 21 век!!!!!!), а оконные интерфейсы. Я не говорю
> что это просто, но кому-то придётся стандартизировать этот зоопарк API в
> ОС. Это возможность выполнения кода в разных ОС и на разных
> платформах без перекомпиляции.
> И не нужно после этого удивляться популярности java и net. Они взяли
> синтаксис и уверено идут вперёд. А С++ везут в гробу на
> кладбище истории чтобы зак-пать рядом с ассемблером.
> PS: слово "зак-пал" в списке матерных???? Я что-то пропустил?

посмотри современный с++ код ))) удивишься, там управления памятью по минимому да и принтф давно уже не используется в нормальных проектах, есть конечно нюансы но не критичные
к нормальному авто управлению памяти без потери скорости не возможно прийти поэтому в с++ его нет, но если очень хочется с большой вероятностью можно написать фреймворк который из с++ делает яву
только это не нужно никому ))

Ответить | Правка | Наверх | Cообщить модератору

48. "Утверждён стандарт C++17"  –4 +/–
Сообщение от bOOster (ok), 08-Сен-17, 09:17 
> Поддержу. Пишу сейчас на Си+Python. Вот когда стал использовать Питон, ощутил всю
> ущербность плюсов, и лаконичную чистоту Си. Для Си нужно знасть только
> арифметику указателей и основы языка - всё остальное в твоих руах,
> и не надо копать в недра всяких там глубокомысленных терминов, без
> знания которых плюсы бесполезны. А оно надо, если то же самое
> можно сделать на Си, не задавая никому никаких вопросов. А для
> гуев и веба Питон - тоже чисты и простой - всегда
> в помощь.

Ну шаблоны "узколобым" даются весьма с трудом :)

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

126. "Утверждён стандарт C++17"  +/–
Сообщение от pripolz (?), 09-Сен-17, 00:37 
> Ну шаблоны "узколобым" даются весьма с трудом :)

А ты сам-то, достаточно подробно знаешь "шаблоны" ?

Ответить | Правка | Наверх | Cообщить модератору

137. "Утверждён стандарт C++17"  +1 +/–
Сообщение от Аноним (-), 09-Сен-17, 15:51 
Про шаблоны достаточно знает только Страуструп. А все остальные вообще не знают C++.
Ответить | Правка | Наверх | Cообщить модератору

151. "Утверждён стандарт C++17"  –1 +/–
Сообщение от bOOster (ok), 11-Сен-17, 16:24 
Александреску неплохо пишет про шаблоны.

В реализациях языка Страуструпа шаблоны были весьма ущербными.

Ответить | Правка | Наверх | Cообщить модератору

155. "Утверждён стандарт C++17"  –1 +/–
Сообщение от Антонин (?), 13-Сен-17, 08:12 
Страус труп в гробу переворачивается со всего этого
Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру