D vs C++ , почти сурковская пропаганда: не пора ли C++ потихоньку готовиться к пенсии?

Цитата MyNameIsIgor @ 25.10.15, 13:41

И почему её надо передавать именно параметром шаблона?

Чтобы не обрабатывать названия полей run-time для тех полей, для которых название известно compile-time, что бывает чуть менее, чем всегда.

Цитата MyNameIsIgor @ 25.10.15, 13:41

Ценность это фичи вообще не могу оценить. В чём смысл, если компилятор всё равно ничего проверить не в состоянии?

А что нужно проверять компилятору? Он просто инстанцирует шаблон и генерит функцию для парсинга соответствующего поля json-объекта. Естественно это можно сделать только если имя поля известно уже на стадии компиляции:

json.myJsonField -> json.opDispatch!"myJsonField"

Цитата MyNameIsIgor @ 25.10.15, 13:41

И что делать, если мне надо обратиться по имени свойства, полученному во время исполнения?

К такому свойству обратиться как свойству структуры не получится. Тогда используется какой-нибудь opIndex (аналог operator[]), где название поля передаётся уже run-time. Но насколько я знаю в обсуждаемом парсере это не реализовано.

Цитата applegame @ 25.10.15, 16:33

Чтобы не обрабатывать названия полей run-time для тех полей, для которых название известно compile-time, что бывает чуть менее, чем всегда.

А что входит в понятие "обрабатывать"?

Цитата applegame @ 25.10.15, 16:33

А что нужно проверять компилятору?

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

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

Цитата MyNameIsIgor @ 25.10.15, 20:25

А что входит в понятие "обрабатывать"?

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

Цитата MyNameIsIgor @ 25.10.15, 20:25

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

Ну я бы так не сказал. Обычно оно применяется для различного рода врапперов, что-то вроде operator-> на стероидах. А так да, синтаксическая фишка, так же как и operator->.

Цитата amk @ 25.10.15, 21:40

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

Нет, compile-time - это если код выполняется на стадии компиляции. И совершенно без разницы написан ли код программистом или сгенерен компилятором.

Что касается возможности передавать строки compile-time вообще, то это сильно помогает в работе с рефлексией. Я в свое время написал автоматические генераторы классов, для RPC (remote proсedure call) через сеть. Грубо говоря мы описываем интерфейс с функциями с параметрами и возвращаемымми значениями, а либа генерит классы для RPC-клиента и RPC-сервера унаследованные от этого интерфейса и реализующие его функции. Заняло примерно 150 строк не считая сериализатора и либы для работы с сетью. Возможность работы со строками в compile-time - это однозначный вин, не понимаю, как можно не понимать этого.

Сообщение отредактировано: applegame - 26.10.15, 08:15

Помню, писал утилитку, собирающую из трёх Word-овых, одного Excel-ного документов, содержащий требования, шаблоны для итогов и выявленные несоответствия, и результатов запуска тестов с пасс/фэйлами и покрытием, два других Word-овых документа с итогами, требующимися для сертификационных органов. Писал через ActiveX-интерфейсы к MS Office, для лицензионной чистоты на MS Studio Express, поэтому на чистом IDispatch, без библиотек и TLB. Танунафик эту динамическую типизацию с run-time рефлексией.

Цитата Qraizer @ 26.10.15, 09:07

Танунафик эту динамическую типизацию с run-time рефлексией.

Дык в D статическая типизация со статической же рефлексией.

Цитата Qraizer @ 26.10.15, 09:07

поэтому на чистом IDispatch, без библиотек и TLB.

Цитата applegame @ 26.10.15, 08:04

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

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

Цитата applegame @ 26.10.15, 08:04

Что касается возможности передавать строки compile-time вообще, то это сильно помогает в работе с рефлексией.

Что мне не понравилось в D - так это засилье строк. А правильно работать с AST как в Lisp или Nemerle.

Я знаю, applegame.
Зато бесплатно, jack128. У меня все внутренние продукты написаны на Стандартных Плюсах, чтобы компилилось и работало и на WinAPI, и на POSIX, ежели вдруг придётся переползти исключительно в unix-way. Фирма не тратит деньги на лицензии, если этого можно не делать, т.к. всякие там RTRT и LDRA и так стоят дофига, ещё Студий не хватало.

Прикреплённая картинка

Троллить пытаешься, Shaggy? Напрасно, у нас практически все target execution environment построены на POSIX.

Эммм... Народ, чёт я не догоняю. Когда я пишу в C++: someStruct.field = node["field"].asString(); (ну или как-то так) я тоже знаю имя поля в compile-time. В чём профит то?

Цитата MyNameIsIgor @ 26.10.15, 13:19

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

Да, я тоже надеялся. Он (парсер) достаточно примитивен, хз как ему удалось обогнать RapidJSON.

Цитата MyNameIsIgor @ 26.10.15, 13:19

Что мне не понравилось в D - так это засилье строк. А правильно работать с AST как в Lisp или Nemerle.

Это да, строковые миксины невероятно уродливы, но таки лучше чем ничего. Есть драфт с претензией на приличные макросы и даже ключевое слово macro зарезервировано, но так как это далеко не самое ужасное в D, то запил его отложен на неведомые времена.

Цитата Flex Ferrum @ 26.10.15, 19:41

Эммм... Народ, чёт я не догоняю. Когда я пишу в C++: someStruct.field = node["field"].asString(); (ну или как-то так) я тоже знаю имя поля в compile-time. В чём профит то?

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

Сообщение отредактировано: applegame - 27.10.15, 06:53

Цитата applegame @ 27.10.15, 06:53

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

Ну ты же понимаешь, что при желании всё это можно сделать и на C++.

Цитата Flex Ferrum @ 27.10.15, 08:19

Ну ты же понимаешь, что при желании всё это можно сделать и на C++.

Интересно как можно compile-time посчитать длину строки передаваемой как параметр функции, которая парсит соответствующий json-объект?