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

[bin]

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

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

Да, по формуле Вирта: "Алгоритмы + структуры данных = программы" Разделы type и var не менее важны для понимания нетривиальной программы, чем раздел begin. Если говорить об ООП, то это прежде всего иерархия классов, а отдельные реализации свойств и методов м.б. простыми и не особо интересными для понимания программы в целом. В многопоточном программировании прежде всего интересуют общие блоки памяти, мьютексы и семафоры.

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

Объявление переменной в C++ не занимает отдельной строки.

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

int n; // число вершин исходного графа
int nn; // число вершин преобразованного графа
int m; // число ребер исходного графа
int mm;  // число ребер преобразованного графа
int w;  // индекс Винера исходного графа
int ww;  // индекс Винера преобразованного графа - используется только для отладки
int h; // индекс Хосойя исходного графа
int hh; // индекс Хосойя преобразованного графа - используется только для отладки

8 строчек на 8 переменных

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

вложенные функции паскаля - дурацкое излишество

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

Xaositect в сообщении #928277 писал(а):

Блок - это не только процедура. Цикл, например, часто быввает тоже обособленным блоком

Отлично. С циклами в С/С++ все в порядке - они могут быть вложенными, почему же процедурные блоки обидели?

[Pavia]

getnextchar в случае конца строки возвращает (short int)(-1), а не "\0" как думаю многие.
Результат getnextchar (short int) , а не char. Именно для этого. Что семантически вопиющее нарушение, но именно так можно отличить ANSI символ с кодом "\0" от конца строки.

Что касается вложенных процедур. То это не плюс и не минус.
А вот отсутствие namespace в паскале это большой минус.
Вообще как я вижу модули должны иметь зоны видимости как в паскале или объектном паскале. А также должны быть namespace.
Тогда вложенные процедуры будут ненужны.

А вот отсутствие модульной структуры вызывает долгую компиляцию. Это всего лишь гипотеза. Вопрос в количественной оценке насколько долго? Насколько мне известно публикаций на эту тему не было. Этот вопрос попросту не изучен должным образом.

А вот с объявлением переменной в цикле это вопрос интересный.
Аргумент то, что в Си это безопаснее думаю не является плюсом.
Кто не знает, что после цикла использовать переменную нельзя тот и в Си ошибется и в паскале. Кто знает уже не должен. Во-вторых есть понятия самодоккументированного кода. Поэтому если в функции есть несколько циклов, то лучше их вынести в отдельные процедуры.
Тем самым ошибки с повторным использованием переменной исключается.

[Xaositect]

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

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

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

Да, по формуле Вирта: "Алгоритмы + структуры данных = программы" Разделы type и var не менее важны для понимания нетривиальной программы, чем раздел begin. Если говорить об ООП, то это прежде всего иерархия классов, а отдельные реализации свойств и методов м.б. простыми и не особо интересными для понимания программы в целом. В многопоточном программировании прежде всего интересуют общие блоки памяти, мьютексы и семафоры.

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

Объявление переменной в C++ не занимает отдельной строки.

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

int n; // число вершин исходного графа
int nn; // число вершин преобразованного графа
int m; // число ребер исходного графа
int mm;  // число ребер преобразованного графа
int w;  // индекс Винера исходного графа
int ww;  // индекс Винера преобразованного графа - используется только для отладки
int h; // индекс Хосойя исходного графа
int hh; // индекс Хосойя преобразованного графа - используется только для отладки

8 строчек на 8 переменных

Интересно, почему же Вы не используете мудрость Вирта о структурах данных и не делаете, например, так:

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

struct GraphInfo
{
  int numVertices;
  int numEdges;
  int wienerIndex;
  int hosoyaIndex;
};

struct GraphInfo source, transformed;
 

-- Сб ноя 08, 2014 19:12:36 --

Pavia в сообщении #928337 писал(а):

getnextchar в случае конца строки возвращает (short int)(-1), а не "\0" как думаю многие.
Результат getnextchar (short int) , а не char. Именно для этого. Что семантически вопиющее нарушение, но именно так можно отличить ANSI символ с кодом "\0" от конца строки.

Это вы про стандартную getchar, а не про какую-то гипотетическую функцию nextgetchar из примера

-- Сб ноя 08, 2014 19:14:18 --

Pavia в сообщении #928337 писал(а):

Аргумент то, что в Си это безопаснее думаю не является плюсом.
Кто не знает, что после цикла использовать переменную нельзя тот и в Си ошибется и в паскале. Кто знает уже не должен

Это как раз самый распространенный вид ошибок - по невнимательности. В С++ если переменная объявлена в цикле, то вне цикла она просто не видна, так что использовать ее запретит компилятор.

[warlock66613]

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

8 строчек на 8 переменных

Да, это хороший пример того, как не надо делать.

-- 08.11.2014, 20:34 --

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

Разделы type и var не менее важны для понимания нетривиальной программы, чем раздел begin.

Вот type - это и есть структуры данных, но никак не var.

-- 08.11.2014, 20:36 --

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

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

Общие блоки памяти, мьютексы и семафоры в локальных переменных? Да, если кодер неопытен в ООП и многопоточном программировании, то такое бывает.

[Yuri Gendelman]

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

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

8 строчек на 8 переменных

Да, это хороший пример того, как не надо делать.

Точнее, как не надо выбирать имена переменных.
А комментарии - вполне нормальные. Через полгода и сам автор может забыть назначение переменных.

[warlock66613]

Yuri Gendelman в сообщении #928366 писал(а):

Через полгода и сам автор может забыть назначение переменных.

Не забудет, если сделает так, как продемонстрировал Xaositect.

[bin]

Xaositect в сообщении #928344 писал(а):

Интересно, почему же Вы не используете мудрость Вирта о структурах данных

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

Yuri Gendelman в сообщении #928366 писал(а):

Точнее, как не надо выбирать имена переменных.
А комментарии - вполне нормальные. Через полгода и сам автор может забыть назначение переменных.

Про имена вопрос особый. Если разрабатываешь новый алгоритм и собираешься публиковать его в научном журнале, то в мат. формулах $\sum\limits _{i=1}^n... выглядит привычнее, чем $\sum\limits _{i=1}^{numVertices}... . Поэтому для нужных в формулах публикации переменных по возможности выбираю однобуквенные имена.

-- Сб ноя 08, 2014 21:09:49 --

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

Вот type - это и есть структуры данных, но никак не var.

Могу записать и так:

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

var A : array [1..maxN,1..maxN] of Boolean;

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

Общие блоки памяти, мьютексы и семафоры в локальных переменных

А где я сказал, что в локальных?

-- Сб ноя 08, 2014 21:38:32 --

Pavia в сообщении #928337 писал(а):

Кто не знает, что после цикла использовать переменную нельзя тот и в Си ошибется и в паскале.

Интересно, почему "Си", но "паскале" с маленькой буквы? В паскале не надо разбираться, надо разбираться в ПАСКАЛЕ По сути: ее можно понимать по-разному. Нпр:

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

const
 maxN = 12012; // буду работать с небольшими графами 
var 
  A,B: array [1..maxN,1..maxN] of Boolean; // матрицы смежности
  D : array [1..maxN] of integer;
  i,j : integer;
begin
// тут пропущен код заполнения матрицы А размера nxn
  for i:=1 to n do
    D[i] := 0; // обнуляю вектор
  writeln (i); // этой строчки писать не надо!
  for i:=1 to n do // повторно использую i? Не буду я десять разных переменных заказывать для всех 
                          // невложенных циклов
    for j:=1 to n do
     if A[i,j] then inc (D[i]); // вычисляю степени вершин графа
   for i:=1 to n do 
    for j:=1 to n do
     B[i,j]:= not A[i,j]; // вычисляю дополнительный граф
 // делаю что-то еще    
end;  //  вот и финиш! Ура !!!

[Xaositect]

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

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

Это, на мой взгляд, заблуждение. Структуры данных - это не только какие-нибудь списки и деревья. Типы-произведения (ака структуры в си, ака записи в паскале) - это простейшие структуры данных, которые служат для того, чтобы объединить в программе данные, логически связанные в предметной области, и использовать их надо сразу, как только появляются две пары переменных, связанных с однотипными объектами. Или пара-тройка переменных, связанных с каким-то объектом, и передающихся во все функции вместе.

[arseniiv]

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

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

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

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

Отлично. С циклами в С/С++ все в порядке - они могут быть вложенными, почему же процедурные блоки обидели?

Очевидно, семантика разная. Цикл — это исполняемый оператор, а процедура — это объявление. И даже код анонимной функции, где он есть, — это выражение.

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

Про имена вопрос особый. Если разрабатываешь новый алгоритм и собираешься публиковать его в научном журнале, то в мат. формулах $\sum\limits _{i=1}^n...$ выглядит привычнее, чем $\sum\limits _{i=1}^{numVertices}...$ . Поэтому для нужных в формулах публикации переменных по возможности выбираю однобуквенные имена.

Во-первых, кто вас заставляет использовать в формулах и коде одинаковые имена?

Во-вторых, действительно, $\sum\limits_{i=1}^{\mathrm{numVertices}}$ будет выглядеть лучше. А ещё лучше будет выглядеть $\sum\limits_{v\in V}$. Индексы должны быть обоснованны.

[bin]

Xaositect в сообщении #928476 писал(а):

Это, на мой взгляд, заблуждение.

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

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

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

procedure readGraph (adjList : string; var adjMat : TAdjMatrix; var n : integer);
// по списку смежности  adjList строит nxn матрицу смежности adjMat

function hos (graph : TAdjMatrix; vNum : integer) : integer;
// возвращает индекс Хосойя

function win (A : TAdjMatrix; vn : integer) : integer;
// возвращает индекс Винера
 

- нужно их объединить, чтобы проверить некую теорию. Конечно же, если теория окажется верной, в релизе должно быть:

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

type

TGraph = record
                adjMatrix :     TAdjMatrix;
                vertexNum,
                hosIndex, 
                winIndex  : integer;
          end;

procedure readGraph (adjList : string; var graph : TGraph);
function hos (graph : TGraph) : integer;
function win (graph : TGraph) : integer;

Поменять имена - рутина, но если идея окажется неверной, это будут лишние трудозатраты. А рабочее время надо беречь!

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

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

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

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

Очевидно, семантика разная. Цикл — это исполняемый оператор, а процедура — это объявление.

Не вижу разницы в контексте данного обсуждения.

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

Во-первых, кто вас заставляет использовать в формулах и коде одинаковые имена?

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

[Xaositect]

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

Если я правильно понял, Вы говорите не только про ООП, но и про обычные записи Паскаля. В теории я с Вами согласен. На практике в процессе работы наведение красот может быть преждевременным.

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

[arseniiv]

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

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

А что такое «неигрушечный компилятор»?

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

Не вижу разницы в контексте данного обсуждения.

В данном случае контекст обсуждения никак не влияет на разницу. Цикл выполняется ясно как, а «выполнению» определения функции (которое в языке типа C++ всё равно не нужно) можно придать только смысл присваивания имени функции замыкания, образованного из тела функции. Тело функции всё равно не будет выполняться так же как цикл. Вложенные функции à la Pascal потому не аналогичны вложенным циклам, и выразимы через не вложенные. А уровень доступа можно отрегулировать пространствами имён или структурами/классами.

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

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

Сами понимаете качество этого аргумента.

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

Если даже в формуле всего десять имен.

Если в формуле «всего десять» имён, и имена не общераспространённые, а определялись выше в статье, то совершенно неочевидно, будут понятнее в такой формуле читателю более длинные или короткие имена.

[bin]

Xaositect в сообщении #928543 писал(а):

Не знаю, я как раз на практике сначала пишу типы и интерфейсы, а потом уже сами функции.

А если эти функции от Ваших сослуживцев, из сети, из литературы, из тех, что десять лет назад Вы сами написали - везде разные имена, и стоит ли сразу их причесывать под одну гребенку, может ведь и не оправдаться?

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

А что такое «неигрушечный компилятор»?

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

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

Цикл выполняется ясно как

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

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

Сами понимаете качество этого аргумента.

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

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

Если в формуле «всего десять» имён, и имена не общераспространённые, а определялись выше в статье, то совершенно неочевидно, будут понятнее в такой формуле читателю более длинные или короткие имена.

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

[Pavia]

По поводу длинной переменной "vertexNum".
Если читали Макконела то vertexNum - не есть правильное имя. Должно быть просто Count, но для более красивого оформления потребуется ООП, так что нет ничего страшного. В данном имени, тем более:
Есть понятие внешнее представление и внутреннее. Так вот внутреннее должно быть удобным.А в данном случае это внешнее представление.
Поэтому изменение имени переменной это нормально.
Просто в коде пишется

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

N:=vertexNum;

Или

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

procedure F(N:Integer);
...
begin
F(vertexNum);
end;
 

По поводу того что на Yacc не пишется профессиональные компиляторы. Пишутся
но сейчас это не в моде. Вот пример пожалуйста Brooсk+ написан на Flex(Yacc).
Написана специалистами из ATI при участие специалистов NVidia.
http://sourceforge.net/projects/brookplus/
и его предшедствинник.
http://sourceforge.net/projects/brook/

PS. Интернет тормозит - поэтому до конца проверить факты не получается. Пишу по памяти.

[bin]

Pavia в сообщении #928620 писал(а):

Вот пример пожалуйста Brooсk+ написан на Flex(Yacc).

В TIOBE programming community index я Brooсk+ не нашел М.б. со временем он станет популярным...