Книга с полным и систематичным изложением современного С++?

[arseniiv]

bin в сообщении #928571 писал(а):

Станет очевидно, когда попробуете записать подобную формулу в TeX

Сначала вы говорили о читателях, теперь о наборе… Набор не в такой степени существенен, и чтобы не набирать одно и то же длинное имя, вполне разумно завести макрос. Странно только, что против длинных имён в программном коде вы такого аргумента не применяли — а разницы-то никакой.

bin в сообщении #928571 писал(а):

И функция выполняется ясно как.

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

bin в сообщении #928571 писал(а):

Коммерческий, успешный, широко используемый для коммерческих и успешных задач, пользующихся широким спросом. (Пример: упомянутый CUDA C)

Неплохое определение. Ещё бы все коммерческие продукты, содержащие парсер, писали о том, что они используют, да?

-- Вс ноя 09, 2014 22:51:16 --

В общем, уговаривать не буду. (Это будет развитием оффтопа. ) Не видите плюсов в подходе — и пожалуйста.

[Xaositect]

В openjdk сейчас вроде бы переписывают парсер с самописного на ANTLR.

[bin]

arseniiv в сообщении #928885 писал(а):

Сначала вы говорили о читателях, теперь о наборе… Набор не в такой степени существенен, и чтобы не набирать одно и то же длинное имя, вполне разумно завести макрос. Странно только, что против длинных имён в программном коде вы такого аргумента не применяли — а разницы-то никакой.

У всех редакций разные форматы, но все исходят из А4. Когда Вы распечатываете текст своей статьи на А4, мат. формулы, занимающие несколько строк, выглядят не всегда красиво. Понятно, что формулу можно ужать, но вот тут-то и начинаются проблемы "наборщика", т.е. автора - ужимать формулу с однобуквенными именами проще, чем с многобуквенными. Листинг другое дело, но обилие имен длиннее, чем 40 символов, в листингах утомляет.

arseniiv в сообщении #928885 писал(а):

но вы при желании прицепитесь в любом случае

А вот и не прицеплюся

arseniiv в сообщении #928885 писал(а):

Не видите плюсов в подходе — и пожалуйста.

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

[arseniiv]

bin в сообщении #929042 писал(а):

У всех редакций разные форматы, но все исходят из А4. Когда Вы распечатываете текст своей статьи на А4, мат. формулы, занимающие несколько строк, выглядят не всегда красиво. Понятно, что формулу можно ужать, но вот тут-то и начинаются проблемы "наборщика", т.е. автора - ужимать формулу с однобуквенными именами проще, чем с многобуквенными.

Не ожидал, что они окажутся длинными. Тогда да, хотя и не совсем…

bin в сообщении #929042 писал(а):

Вы зря обижаетесь

Ну что вы, где.

bin в сообщении #929042 писал(а):

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

Хм, а я про него что-то говорил? Ничем не хуже других циклов.

[warlock66613]

arseniiv в сообщении #929063 писал(а):

Хм, а я про него что-то говорил? Ничем не хуже других циклов.

Это я про него говорил:

warlock66613 в сообщении #928235 писал(а):

Для меня do-while в принципе не читаем

[Munin]

Чем практически не пользуются - то и воспринимается плохо. Например, тот же switch, или enum. Недавно слово auto было таким же почти ненужным, но ему придали новые функции (впрочем, старые - всё равно остались весьма периферийными конструкциями языка).

-- 10.11.2014 16:36:41 --

Кстати, тут как-то произносилось, что C++ не допускает вложенных функций. Допускает, просто мало кто этим пользуется, и вообще знает об этом:

Используется синтаксис C++

void f ()
{
    void g ()
    {}
    g ();
}

[venco]

Munin в сообщении #929183 писал(а):

Кстати, тут как-то произносилось, что C++ не допускает вложенных функций. Допускает, просто мало кто этим пользуется, и вообще знает об этом:

Используется синтаксис C++

void f ()
{
    void g ()
    {}
    g ();
}

Эмм... А можно узнать ваш компилятор?
Насколько я знаю, в стандарте C++ этого нет. Даже в последнем.

-- Пн ноя 10, 2014 10:50:53 --

Munin, возможно, вы имеете в виду нестандартное расширение gcc, которое работает только в режиме C.

[Munin]

venco в сообщении #929250 писал(а):

Насколько я знаю, в стандарте C++ этого нет. Даже в последнем.

Это даже в ARM-е было.

[EtCetera]

bin

bin в сообщении #928129 писал(а):

EtCetera в сообщении #928111 писал(а):

Ссылка, которую я привел, одинаково справедлива как для C, так и для C++.

Вот именно! И везде тоже самое. Поэтому C++ воспринимается как расширение С, а не как другой язык.

Далеко не везде, в том-то и дело.

bin в сообщении #928129 писал(а):

OO Pascal

Такой язык мне не знаком.

bin в сообщении #928129 писал(а):

EtCetera в сообщении #928111 писал(а):

Какое отношение имеет неправильное задание размера во втором параметре cudaMalloc к sizeof(int**) != sizeof(void**)? Внимательно прочитайте, пожалуйста, текст по вышеприведенной ссылке.

Прежде всего, где в CUDA-примерах Вы нашли, чтобы размер в cudaMalloc задавался через sizeof(void**)?

Нигде не находил.
Видимо, необходимо повторить, что проблема с функцией cudaMalloc никак не связана ни с неправильным заданием размера выделяемой памяти во втором параметре, ни с некорректной/неполной обработкой ошибок, ни с выделением памяти на GPU.

bin в сообщении #928129 писал(а):

А текст не только прочел, но частично и процитирую:

Честно говоря, незаметно, что Вы его прочли.

bin в сообщении #928129 писал(а):

BTW мне не ответили:

bin в сообщении #927812 писал(а):

Всегда ли перед делением нужно проверять, что делитель не ноль?

bin в сообщении #928023 писал(а):

Почему в C/C++ допустимо while (i=j)

Я не вижу, какое отношение эти вопросы имеют к обсуждаемой теме.

Munin, venco

venco в сообщении #929250 писал(а):

Munin, возможно, вы имеете в виду нестандартное расширение gcc, которое работает только в режиме C.

Да, это расширение gcc:

Документация по gcc писал(а):

A nested function is a function defined inside another function. Nested functions are supported as an extension in GNU C, but are not supported by GNU C++.

Чтобы это ощутить, можно воспользоваться ключом -pedantic-errors:

Вывод gcc писал(а):

source_file.c: In function ‘f’:
source_file.c:3:5: error: ISO C forbids nested functions [-Wpedantic]
     void g ()
     ^

Вообще, если иметь дело с gcc и clang без -Wall -Wextra -Werror -pedantic-errors (с указанием нужного стандарта) к спорным моментам лучше не подходить.
Впрочем, в C++ вложенные функции легко имитируются с помощью статического метода или operator() локального класса. В C++11 добавились лямбды, которые позволяют (через список захвата) непринужденно использовать переменные функции(-ий) верхнего уровня. В C++14 появились generic lambdas, которые являются уже аналогами локальных шаблонов.

[bin]

EtCetera в сообщении #929500 писал(а):

Такой язык мне не знаком.

Object-Oriented Extensions to Pascal, Technical Committee X3J9, Programming Language Pascal, http://pascal-central.com/OOE-stds.html

EtCetera в сообщении #929500 писал(а):

Видимо, необходимо повторить, что проблема с функцией cudaMalloc никак не связана

А с чем связана?

EtCetera в сообщении #929500 писал(а):

Честно говоря, незаметно, что Вы его прочли.

И мне незаметно, что Вы его прочли.

EtCetera в сообщении #929500 писал(а):

Я не вижу, какое отношение эти вопросы имеют к обсуждаемой теме.

Самое прямое.

[EtCetera]

bin

bin в сообщении #929782 писал(а):

EtCetera в сообщении #929500 писал(а):

Видимо, необходимо повторить, что проблема с функцией cudaMalloc никак не связана

А с чем связана?

Я уже писал, с чем. И по приведенной мной ссылке все тоже хорошо расписано.

bin в сообщении #928129 писал(а):

Тут функция incme изменяет значение переменной, находящейся по указанной ссылке, а cudaMalloc всего лишь выделяет заказанный объем памяти на устройстве. В этом принципиальная разница.

Только выделяет и ничего не изменяет? Как же тогда программа может использовать выделенную память?

bin в сообщении #929782 писал(а):

EtCetera в сообщении #929500 писал(а):

Честно говоря, незаметно, что Вы его прочли.

И мне незаметно, что Вы его прочли.

Я не стал бы ссылаться на него, если бы не прочел.

bin в сообщении #929782 писал(а):

EtCetera в сообщении #929500 писал(а):

Я не вижу, какое отношение эти вопросы имеют к обсуждаемой теме.

Самое прямое.

Не могли бы Вы конкретизировать этот момент?

[bin]

EtCetera в сообщении #929860 писал(а):

Не могли бы Вы конкретизировать этот момент?

Конкретизирую. Я открыл эту тему, т.к. обнаружил, что даже в книге Страуструпа прописаны далеко не все детали, очень важные для понимания философии С/С++. В ходе обсуждения добавилось еще деталей, совершенно для меня неожиданных. Например, никогда не думал, что допустимо

a=b=c;

и в книгах такого не видел, также не нашел в книгах, зачем нужно

while (i=j)

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

EtCetera в сообщении #929860 писал(а):

уже писал, с чем. И по приведенной мной ссылке все тоже хорошо расписано.

Выше я уже отметил, что по приведенной ссылке, на мой взгляд, иная ситуация, чем с cudaMalloc. Похоже, Вы видите общий момент, где я его не увидел - в ссылке как раз говорится: "which probably have different sizes and certainly have different representations", Вы же утверждаете

EtCetera в сообщении #929500 писал(а):

проблема с функцией cudaMalloc никак не связана ни с неправильным заданием размера выделяемой памяти во втором параметре

Я-то вообще не вижу проблемы cudaMalloc - объясните, пожалуйста, подробнее, в чем Вы видите проблему, если можете.

EtCetera в сообщении #929860 писал(а):

Только выделяет и ничего не изменяет? Как же тогда программа может использовать выделенную память?

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

[EtCetera]

bin

bin в сообщении #929927 писал(а):

В ходе обсуждения добавилось еще деталей, совершенно для меня неожиданных.

Подброшу еще одну неожиданную конструкцию: while (int i = j).

bin в сообщении #929927 писал(а):

надеюсь, мне укажут книги, в которых необходимость этих конструкций хорошо обоснована

Сомневаюсь, что такие книги существуют.
Есть $\text{---}$ и спасибо, в хозяйстве пригодятся.

bin в сообщении #929927 писал(а):

Надеюсь, я достаточно конкретизировал

Вполне.

bin в сообщении #929927 писал(а):

Опять не понял, с какой радости, выделяя память, нужно менять ее содержимое?!

Я ничего не говорил про изменение выделяемой памяти. Но чтобы программа могла использовать выделенную память, cudaMalloc должна каким-то образом вернуть указатель на выделенную память. Обычно функции выделения памяти возвращают указатель на выделенную память (возможно, в виде void*). Это вполне безопасно. Однако в Nvidia для унификации API функция cudaMalloc возвращает код ошибки. Поэтому указатель на выделенную память "возвращается" через параметр типа "указатель на указатель". Т.е. cudaMalloc изменяет переменную типа void* через указатель на нее. До этого места все хорошо. Но проблема в том, что практически никто (в т.ч. сами разработчики из Nvidia, которые пишут программы-примеры) не заботится о том, чтобы завести эту вспомогательную переменную типа void* и приводят указатель на какой-нибудь int* (т.е. int**) к указателю на void* (т.е. void**). Но int* и void* $\text{---}$ это два разных типа, и попытка изменить значение переменной одного типа через указатель на другой тип равносильна изменению значения типа int через указатель на double, как это делается в приведенной Вами цитате из comp.lang.c.

[Pphantom]

bin в сообщении #929927 писал(а):

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

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

[bin]

EtCetera в сообщении #929994 писал(а):

Сомневаюсь, что такие книги существуют.
Есть $\text{---}$ и спасибо, в хозяйстве пригодятся.

Pphantom в сообщении #930020 писал(а):

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

Это подтверждает мои подозрения, что некоторые языки (в том числе С/С++) бедно обоснованы. В стандартах, отвечающих требованию полноты, подобные возможности рассматривать необязательно, и в книгах не приходится, т.к. "можно сделать и без них". И т.к. "некоторым это нравится", возрастают недопонимание и угроза труднообнаружимых багов. Не слишком ли увлекаются короткими записями создатели языков? Они думают, что если вместо begin/end ставить фигурные скобки, то кодер за единицу времени напишет больше кода? Но тогда нужно быть последовательными и сокращать не только integer до int, но и while до wh

Самая ожиданная конструкция это опечатка:

Используется синтаксис C

if (i=j)

EtCetera в сообщении #929994 писал(а):

До этого места все хорошо. Но проблема в том, что практически никто (в т.ч. сами разработчики из Nvidia, которые пишут программы-примеры) не заботится о том, чтобы завести эту вспомогательную переменную типа void* и приводят указатель на какой-нибудь int* (т.е. int**) к указателю на void* (т.е. void**). Но int* и void* $\text{---}$ это два разных типа, и попытка изменить значение переменной одного типа через указатель на другой тип равносильна изменению значения типа int через указатель на double, как это делается в приведенной Вами цитате из comp.lang.c.

В CUDA значения переменных меняются обращением к ядру, там контроль за типами в порядке и нет такого, как в цитате из comp.lang.c:

Используется синтаксис C

int i = 1;
incme((double *)&i);    /* WRONG */
 

Выше я приводил пример ядра:

Используется синтаксис C

__device__ int addem( int a, int b ) {
    return a + b;
}

Полагаю, тут претензий быть не может. Что касается cudaMalloc, то она используется совместно с cudaMemcpy для клонирования пары переменных одного типа (нпр., с и dev_c ). И только так. Никакой опасности такая передача параметров не содержит. Не только С/С++ используют нетипизированные переменные, но и многие другие языки. Так, Delphi во многом унаследовал строгую типизацию Pascal, но и в Delphi широко применяются механизмы, подобные cudaMalloc. Например, есть нетипизированные файлы и есть процедуры для работы с ними:

Используется синтаксис Delphi

procedure blockRead(var f:file; var Buf; count: integer);

Эта процедура читает из файла f в буфер (Buf) count байт. А как будут интерпретированы эти прочитанные байты - как целые числа или как символы или как еще - решать приходится целиком программисту, и компилятор никакой ответственности за это не несет. Это единственная возможность для решения широкого круга элементарных типовых задач. В ранних стандартах Паскаля, нпр., пользовательских нетипизаций не допускалось. Хотя и там пришлось сделать исключения для библиотечных read и write. В результате на практике приходилось прибегать к трюкам:

Используется синтаксис Pascal

 
MyType = record 
                  case Boolean of
                   false: (a : type1);
                   true: (b: type2);
                 end;

Но такие трюки не помогали, когда нужно было перемножать $n\times n$ матрицы с заранее неизвестным $n$. Нетипизированные переменные - это не какое-то отступление от принципов защитного программирования, а просто другой уровень абстракции. Нпр., чтобы скопировать файл, совсем не нужно знать, какой тип у записей этого файла.