Здравствуйте, -n1l-, Вы писали:

N>А вот всякие гномы и кеды и остальные из мира опенсорса сделаны на инкрементированных сях.

afaik, GNOME — это прежде всего C.

Здравствуйте, matumba, Вы писали:

К>>Задумайся на досуге о том, что промышленность так и не выкинула си. Неспроста, наверное.

M>На, тоже задумайся:

M>

Этот график наглядно показывает, что с 2000 года, уже 14 лет, старый, добрый, процедурный Си не теряет популярности. И на данный момент самый популярный язык программирования.
Успех ябло-си с 2011 по 2013 год легко объяснить выходом новых телефонов и новизну тренда на разработку мобильных приложений.
Если посмотреть на шарп, то после 2012 года видно, что он немного теряет популярность, а си плюс плюс, после резкого спада еще держится в лидерах.

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

M>По всем остальным аспектам Си — г-но мамонта, безумно затягивающее разработку и до сих пор (напоминаю, 21 век!) подкладывает свинью в виде stack overflow, null pointer, range overwrite и.т.п. —
Ну это лол, а что в шарпе нет null reference exception, stack overflow и т.д.?




M>Те же, кто платили за Сипиписных монстров! Что в этом такого? Новый софт делался и будет делаться, весь вопрос лишь в том, хватит ли ума "боссам" не создавать очередной "быстробегущий труп", чтобы потом годами латать дыры и молиться, чтобы все оба "специалиста по указателям" не махнули из конторы. И в то же время есть громадный выбор C# спецов, знания которых на порядок ценнее, потому что это не знания о костылях языка, а высокоуровневая CS.

Опять же лол. А что, если я выбрал шарп, как язык для своего проекта, то он автоматически будет хорошо написан?
Нет, конечно, если я захочу просто заформошлепить веб/десктоп/<поставить по вкусу> морду на винде, то брать плюсы, как основной язык, будет глупо.
С другой стороны я бы раз 20 подумал, а стоит ли мне связываться с майкрософтом?
А если не связываться, то лучше графичкского интерфейса чем qt нет.
Java? Полностью, по всем параметрам проигрывает. делфи? Да-да, сейчас...

M>Легаси — оно и есть легаси, подумай насколько высоко прыгнула парадигма от жонглирования указателей в перделках на 1000 строк к облачным вычислениям, паттернам, модульным системам, ООП и прочее — да это небо и земля!
Ога, парадигма прыгнула настолько, что я могу сейчас просто привести любого такого же фанатика хаскеля и он обдристает ваш(наш) си-шарп, си++, java, со всеми паттерными и оопами и точно так же заявит, что все это — говно мамонта и не нужно. А уж как он залечит про алгебраические типы, о том, что потоки не нужны, о том, что хаскель — это язык будущего, а мы все — отстой... Ууу!
В нашем мире много языков программирования и это прекрасно.

Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>afaik, GNOME — это прежде всего C.

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

Здравствуйте, -n1l-, Вы писали:

N>Здравствуйте, DarkEld3r, Вы писали:
DE>>Лол что? Ни с чем не перепутал? Вообще-то Линус категорически не любит С++.
N>Линус кроме ядра линукса и гита ничем не занимается, в принципе.
N>А вот всякие гномы и кеды и остальные из мира опенсорса сделаны на инкрементированных сях.
Я как бы в курсе. Но речь шла про "бортовую радиолу", вот и предположил, что речь, в первую очередь, именно о ядре. Ну и разработчики гнома продвигают Vala, вроде.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Наверное только в одну сторону? То есть вот такое не получится: найти заданный символ в строке, и вывести N предыдущих в обратном порядке.

"Привет".findSplit("в")[0].retro().take(2).writeln();//выводит "ир"

Пользуясь случаем хочу спросить.
На чем в linux'e больше программируют(чистых сях или инкрементированных) и что(встраиваемые системы, десктопчики, мобилки, веб)?

Здравствуйте, alex_public, Вы писали:


EP>>Наверное только в одну сторону? То есть вот такое не получится: найти заданный символ в строке, и вывести N предыдущих в обратном порядке.
_>

_>"Привет".findSplit("в")[0].retro().take(2).writeln();//выводит "ир"
_>

Да там же читерство!

auto findSplit(alias pred = "a == b", R1, R2)(R1 haystack, R2 needle)
if (isForwardRange!R1 && isForwardRange!R2)
{
    static if (isSomeString!R1 && isSomeString!R2
            || isRandomAccessRange!R1 && hasLength!R2)
    {
        auto balance = find!pred(haystack, needle);
        immutable pos1 = haystack.length - balance.length;
        immutable pos2 = balance.empty ? pos1 : pos1 + needle.length;
        return tuple(haystack[0 .. pos1],
                haystack[pos1 .. pos2],
                haystack[pos2 .. haystack.length]);
    }
    else
    {
        // ... [SKIPPED]
        return tuple(takeExactly(original, pos1),
                takeExactly(haystack, pos2 - pos1),
                h);
    }
}

а для обычных BidirectionalRange, незнакомых алгоритму — было бы takeExactly, у которого первый range — ForwardRange, и с середины назад уже не пройтись

Здравствуйте, alex_public, Вы писали:

_>

_>"Привет".findSplit("в")[0].retro().take(2).writeln();//выводит "ир"
_>

Кстати, у retro есть проверка на isRandomAccessRange — в этом случае также возвращается RandomAccessRange, а вот isSomeString уже нет.
То есть, по идее, вот такой код не скомпилируется:

"тевирП".retro().findSplit("в")[0].retro().take(2).writeln();

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>а для обычных BidirectionalRange, незнакомых алгоритму — было бы takeExactly, у которого первый range — ForwardRange, и с середины назад уже не пройтись

Эммм, так я же это и сказал чуть выше. Что для строк D (которые являются char[], т.е. RandomAccess) всё шоколадно. А вот BidirectionalRange — это действительно какая-то сомнительная хрень, которая похоже была введена для обобщения на двусвязные списки, но при этом в итоге испортила их же функциональность.

Ну точнее строки char[] и wchar[] (но не dchar[]) возвращают false на isRandomAccessRange, как раз из-за переменного размера символа... Но при этом по сути это всё равно сущности с произвольным доступом, просто не через диапазоны, а через срезы (т.е. побайтово). И у нас есть замечательная функция toUTFindex, т.е. написав например str[0..str.toUTFindex(10)], мы получим снова сущность с произвольным доступом из первых 10 символов. Это как бы на низком уровне и тут у строк в D никаких проблем. А на высоком уровне (когда играем с диапазонами) они действительно формально как BidirectionalRange проходят, но при этом произвольный доступ по байтам то остаётся и соответственно просто во всех функция библиотеки должна быть предусмотрена специальная обработка строк, раз уж это поддерживается на низком уровне.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Кстати, у retro есть проверка на isRandomAccessRange — в этом случае также возвращается RandomAccessRange, а вот isSomeString уже нет.
EP>То есть, по идее, вот такой код не скомпилируется:
EP>

EP>"тевирП".retro().findSplit("в")[0].retro().take(2).writeln();
EP>

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

"тевирП".retro().findSplit("в")[0].array.retro().take(2).writeln();

выдаёт правильный результат. Но это естественно не правильное решение, а костыль для демонстрации реального проблемного места в библиотеке.

Вообще там в библиотеке ещё много чего недоделанного и данный момент это вообще ерунда на фоне например того же странного DList и ещё кучи подобных мест.

Но хочу заметить один нюанс из практики. Лично я уже пробуя кое-что делать с D так ни разу и не залез в раздел Range. Массивы (фиксированные, динамические, ассоциативные) встроенные в язык с их срезами и тот факт, что функции из библиотеки работают с ними сохраняя их семантику, покрывают большинство потребностей. А всякие сложные структуры (типа списков, деревьев и т.п.) я всё равно привык обычно сам делать, уже не в виде контейнера. Т.е. могу ещё раз повторить свою начальную мысль тут: диапазоны в D — это совсем не так важно как итераторы в C++. В D скорее рулят срезы. )))

Здравствуйте, alex_public, Вы писали:

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

1. В примере выше произвольный доступ используется для обхода надуманных ограничений Range. Там нет никакого RandomAccess, индексы используются для взятия слайсов по границам до которых мы уже дотопали, в случае итераторов была бы просто комбинация [first, search(...)). То же std::search спокойно работает для всего начиная от ForwardIterator, без всякого дополнительного специального кода внутри.
2. Специальная обработка строк в алгоритмах библиотеки — это самый что ни на есть костыль, обходящий проблемы Range, да и то не везде подставленный.
3. Сама по себе такая категория range была бы интересна только при наличии возможности быстрого вычисления индекса. Если же индекс считается линейно, как в toUTFindex, то это ничем не лучше BidirectionalIterator, так как str.toUTFindex(10) — даёт тоже самое что и std::next(first, 10), только в менее удобном виде.
И реализация у toUTFindex такая же как и у std::next, со специальной обработкой random access.

Здравствуйте, alex_public, Вы писали:

_>Да, не скомпилируется, но совершенно по другой причине. Например вот так
_>

_>"тевирП".retro().findSplit("в")[0].array.retro().take(2).writeln();
_>

_>выдаёт правильный результат.

Как раз по этой причине: первый retro возвращает BidirectionalRange, который уже не isSomeString, поэтому первый range в результате findSplit — это то, что выдал takeExactly, который возвращает ForwardRange. Вот из этого Forward как раз и не получается взять retro — поэтому ты и скопировал его в array перед .retro().

_> Т.е. могу ещё раз повторить свою начальную мысль тут: диапазоны в D — это совсем не так важно как итераторы в C++. В D скорее рулят срезы. )))

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

Здравствуйте, alex_public, Вы писали:

_>Массивы (фиксированные, динамические, ассоциативные) встроенные в язык с их срезами...
Кстати, правильно ли я понимаю, что свой аналог хеш-таблицы (ассоциативного массива) с таким же синтаксисом, как встроенные (ValueType [KeyType]), сделать нельзя?

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>1. В примере выше произвольный доступ используется для обхода надуманных ограничений Range. Там нет никакого RandomAccess, индексы используются для взятия слайсов по границам до которых мы уже дотопали, в случае итераторов была бы просто комбинация [first, search(...)). То же std::search спокойно работает для всего начиная от ForwardIterator, без всякого дополнительного специального кода внутри.

Ну так для Forward и в D всё отлично. Кривым выглядит именно Bidirectional.

EP>2. Специальная обработка строк в алгоритмах библиотеки — это самый что ни на есть костыль, обходящий проблемы Range, да и то не везде подставленный.

Строки то не простые, а utf8/utf16. Скажем если будем сравнивать с C++, то там в стандартной библиотеке нет вообще никакой поддержки подобного.

Далее, в большинстве случаев эти костыли сводятся не к написанию новой ветки алгоритма, а к добавлению строк в static if для ветки RandomAccess. Ну и т.к. это всё во время компиляции, то никакого оверхеда не приносит. Т.е. вне зависимости от того хорошие Range или плохие, идея делать алгоритмы в несколько веток (и соответственно каждая ветка более оптимизированная) под разные тип данных прослеживается много где в D и не кажется мне плохой. Кстати, благодаря перегрузке по типу шаблонного параметра, это ещё и частенько реализуется в виде отдельных функций. Т.е. наглядно и расширяемо.

EP>3. Сама по себе такая категория range была бы интересна только при наличии возможности быстрого вычисления индекса. Если же индекс считается линейно, как в toUTFindex, то это ничем не лучше BidirectionalIterator, так как str.toUTFindex(10) — даёт тоже самое что и std::next(first, 10), только в менее удобном виде.
EP>И реализация у toUTFindex такая же как и у std::next, со специальной обработкой random access.

Ну естественно, чудес то не бывает. Если мы хотим посимвольную итерацию по utf8/utf16 строкам, то по любому где-то необходим этот код.

Да, кстати, а вот лично я предпочитаю (что в C++, что в D) работать внутри программы с широкими строками, у которых нет всех этих проблем. А utf8 использовать исключительно для хранения данных где-то снаружи программы.

Здравствуйте, DarkEld3r, Вы писали:

DE>Кстати, правильно ли я понимаю, что свой аналог хеш-таблицы (ассоциативного массива) с таким же синтаксисом, как встроенные (ValueType [KeyType]), сделать нельзя?

По идее, ничто не мешает — описываешь структуру/класс с оператором обращения по индексу и вперед.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Как раз по этой причине: первый retro возвращает BidirectionalRange, который уже не isSomeString, поэтому первый range в результате findSplit — это то, что выдал takeExactly, который возвращает ForwardRange. Вот из этого Forward как раз и не получается взять retro — поэтому ты и скопировал его в array перед .retro().

Ну да. Я неправильно понял ту твою фразу)

А вообще, как я уже писал в предыдущем сообщение, в реальности у меня скорее был бы код вида

"тевирП"d.retro().findSplit("в")[0].retro().take(2).writeln();

который позволяет полностью забыть о BidirectionalRange, как о кошмарном сне. )))

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

EP>Это уже другой вопрос — во многих языках (стандартных библиотеках) кроме SinglePass и Arrays, вообще ничего не предлагается. И многие функции высшего порядка возвращают только SinglePass, что приводит к излишним копиям. Но как-то же получается обходится.

Я всё немного про другое.

Вот смотри, что нам даёт голый C++ (без STL и т.п.) в этом смысле? По сути голые указатели, плюс сахар в виде обращения к ним через оператор индекса. И в общем то всё. Очевидно, что этого абсолютно недостаточно для нормального написания софта. Т.е. если бы STL и аналогов не было, то всё равно каждая команда писала бы себе в начале свой маленький вариант STL и работала только через него.

Теперь посмотри что даёт нам голый D. Удобные массивы со срезами, итерациями, контролем памяти. Плюс ещё ассоциативные массивы. Это покрывает огромное множество задач. Т.е. я думаю что вполне возможно довольно долго работать на D, вообще не заглядывая в те разделы библиотеки.

Здравствуйте, DarkEld3r, Вы писали:

DE>Кстати, правильно ли я понимаю, что свой аналог хеш-таблицы (ассоциативного массива) с таким же синтаксисом, как встроенные (ValueType [KeyType]), сделать нельзя?

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

Здравствуйте, alex_public, Вы писали:

_>А вообще, как я уже писал в предыдущем сообщение, в реальности у меня скорее был бы код вида
_>

_>"тевирП"d.retro().findSplit("в")[0].retro().take(2).writeln();
_>

который позволяет полностью забыть о BidirectionalRange, как о кошмарном сне. )))

А вот если у тебя такая задача, каким бы был идиоматичный код на D?

Есть массив целых чисел, нужно найти искомое число, потом отсчитать вниз 2 четных числа, а потом наверх 5 нечетных.
Т.е. для массива 1,2,3,4,5,6,7,8,9,10,11,12 мы находим 5, потом отсчитываем 2 четных числа вниз (4,2), потом 5 нечетных вверх (3,5,7,9,11) — ответ 11.

Мне вот не приходит в голову, как такую задачу решать на диапазонах. А на итераторах все естественно.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, alex_public, Вы писали:

EP>>То же std::search спокойно работает для всего начиная от ForwardIterator, без всякого дополнительного специального кода внутри.
_>Ну так для Forward и в D всё отлично. Кривым выглядит именно Bidirectional.

Я о том, что код у std::search может содержать реализацию только для ForwardIterator, и для всего остального будет работать без дополнительных движений. Без всяких isSomeString и isRandomAccessRange, и при этом даже будет быстрее, так как не имеет лишних операций.

EP>>2. Специальная обработка строк в алгоритмах библиотеки — это самый что ни на есть костыль, обходящий проблемы Range, да и то не везде подставленный.
_>Строки то не простые, а utf8/utf16. Скажем если будем сравнивать с C++, то там в стандартной библиотеке нет вообще никакой поддержки подобного.

Есть литералы UTF-8/16/32, итераторов в стандартной библиотеке пока нет, но есть во внешних.

_>Далее, в большинстве случаев эти костыли сводятся не к написанию новой ветки алгоритма, а к добавлению строк в static if для ветки RandomAccess. Ну и т.к. это всё во время компиляции, то никакого оверхеда не приносит. Т.е. вне зависимости от того хорошие Range или плохие, идея делать алгоритмы в несколько веток (и соответственно каждая ветка более оптимизированная) под разные тип данных прослеживается много где в D и не кажется мне плохой. Кстати, благодаря перегрузке по типу шаблонного параметра, это ещё и частенько реализуется в виде отдельных функций. Т.е. наглядно и расширяемо.

Эта идея естественно хорошая, и применяется в стандартном C++ начиная с первой его версии — C++98. Как раз концепции помогут делать перегрузки ещё проще и элегантней.
Другое дело когда эти ветки приходится писать не для оптимизации, а для получения хоть чего-то полезного.