EP>>>Да, но используются они совершенно по-разному.
EP>>>В C++ создавая вектор N объектов конкретного класса происходит ровно одна аллокация (не учитывая внутренние под-объекты в куче). В C# же, а уж тем более в Java, будет N+1 аллокация — одна на массив указателей, и по одной на каждый объект.
VD>>Ну, это явное заблуждение. В Шарпе (точнее в дотнете) есть варианты. Можно создать структуру и она будет точно так же размещена в массиве.
EP>Ты конечно же не читатель — слово "класс" я для кого подчеркнул? То что в C# возможно использовать структуры это конечно хорошо (поэтому я и сказал "уж тем более в Java"), но это требует дополнительных движений (которые по умолчанию и не делают), т.е. нельзя просто взять и положить любой класс как структуру в массив.

Конкретный пример:
http://coliru.stacked-crooked.com/a/169cb8f18b2d07f8

struct Shape
{
    virtual void draw() const = 0;
};

struct Triangle : Shape
{
    void draw() const override
    {
        cout << "Triangle" << endl;
    }
};

struct Circle : Shape
{
    void draw() const override
    {
        cout << "Circle" << endl;
    }
};

int main()
{
    vector<Triangle> triangles = {{}, {}};
    vector<Circle> circles = {{}};
    vector<Shape*> shapes = {&triangles[0], &circles[0], &triangles[1]};

    for(auto x : shapes)
        x->draw();
}

Где здесь для C#/.NET ставить struct? Не говоря уже о том, что эти Circle/Triangle могут быть недоступны для изменений.

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

_>>т.к. у него нет кучи важных инфраструктурных вещей.
VD>Что это за загадочные вещи?

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

_>>Кстати, а вот Swift похоже уже взлетел, хотя официально ещё не выпущен. Причём какой-то явной киллер-фичи у него нет, а имеется опять же множество мелких приятностей в синтаксисе. Но зато у него гарантированно нет проблем с инфраструктурой.
VD>С родителями у него нет проблем. У них много бабла и пиара. Это ты имеешь в виду под инфраструктурой?

См. выше. Сейчас конечно же ещё не всё есть, но очевидно что 100% будет. Т.е. уже даже сейчас (ещё до официального выхода) вложение в разработку на Swift'e не будет сильно рискованным шагом.

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

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

BC>>Надо свернуть аккуратно Немерл и попытаться пропихнуть его под новым именем на незнакомой площадке.
BC>>Шансы есть у даже самого неудачного проекта. Тут конечно уже получилось вязкое болото "соотечественников".

K>Вставлю 5 копеек как человек, узнавший про Nemerle где-то полгода назад, прочитавший статьи, впечатлившийся, попробовавший и не ставший внедрять.
K>Ибо:
K>1) Поддержка IDE установилась раза с седьмого после нескольких попыток поставить Nemerle разных версий (на VS2013)
K>2) Поддержка IDE конфликтует с плагинами, например TabSanity (ломается интелисенс)
K>3) Стандартная библиотека ставится в GAC, NuGet-пакет с нужными сборками просто-напросто отсутствует, что делает невозможным нормальное использование Nemerle при разработке библиотек. Выражается это тем, что непонятно как таскать за собой зависимости (включать в пакет и ловить конфликты с другой библиотекой на Nemerle?) и невозможности собрать на сферическом билд-сервере в вакууме без дополнительной настройки, хотя казалось бы, в чём проблема стандартную библиотеку, компилятор и MSBuild-таски распространять через NuGet, закидывая их скриптами в директорию в корне решения, как это делает сам NuGet для поддержки Package Restore.
K>4) Самое важное: .NET-разработчики, и я в том числе, как на наркотик подсели на ReSharper. Он слишком много делает за нас, слишком много позволяет сделать в 2 клика. Пока в нём не будет поддержки Nemerle о массовом промышленном внедрении можно забыть. У Scala, кстати, с IDE схожие проблемы, недавно пришлось поддерживать небольшой компонент на ней, долго плевался.

K>В итоге сижу и жду, пока допилят нитру и, если повезёт, прикрутят поддержку немерла к решарперу.

Могу добавить в список другие мелкие недоработки которые мешают использовать язык:

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

В связи с пунктом 1 интеграция для 2010 и выше работает с компилятором только для .NET 4 . Можно конечно использовать хаки, но это не то.

Нет поддержки авто-генерации перенаправлений(AutoGenerateBindingRedirects) , в связи с чем невозможно использовать SignalR 2.0 и другие библиотеки.

Сама стандартная библиотека Nemerle нуждается в переработке с учетом новых возможностей .NET , но этим пока никто не занимался, в итоге бывает трудно выбрать какой метод использовать Select vs. MapLazy например.

Нет хорошей поддержки *NIX систем. Конечно в Mono есть баги и нужно их учитывать, но с поддержкой Mono можно было бы использовать язык для мобильных приложений. Кроме того это увеличивает количество людей , которым язык мог бы быть интересен.

Нет поддержки новых фич .NET , например dynamic . Конечно есть аналог , однако использовать библиотеку C# где есть dynamic немного неудобно.

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

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

>> Нет возможности компилировать для других версий отличных от компилятора.
Если не ошибаюсь, в Mono проблему решили переездом компилятора на IKVM.Reflection.Emit. Равно как и бред с "можно делать 64-битные сборки только при запуске компилятора в 64-битном дотнете".

>> Нет хорошей поддержки *NIX систем. Конечно в Mono есть баги и нужно их учитывать, но с поддержкой Mono можно было бы использовать язык для мобильных приложений. Кроме того это увеличивает количество людей , которым язык мог бы быть интересен.
По идее там не заводится только компилятор, результирующие сборки работают нормально, так что с Xamarin-овскими утилитами, заточенными на работу в VS принципиальных и неустранимых проблем быть не должно. Xamarin Studio же до сих пор представляет из себя нечто малоюзабельное: несмотря на то что уже пятый год использую Mono в продакшне на серверсайде, для разработки применяем исключительно VS.

>>Сходу все не вспомнишь, но мелочи каждый раз немного достают.
Ну и 183 открытых issue на GitHub говорят о многом, да. В общем и целом создаётся впечатление, что проект скорее мёртв чем жив.


Принципиальный вопрос на самом деле немного в другом. Если в дальнейшем планируется переход на Nitra, имеет ли вообще сейчас смысл трогать хоть как-то компилятор и стандартную библиотеку (немалую часть которой составляют макросы, которые тоже придётся полностью переписывать)?

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

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

>>> Нет возможности компилировать для других версий отличных от компилятора.
K>Если не ошибаюсь, в Mono проблему решили переездом компилятора на IKVM.Reflection.Emit. Равно как и бред с "можно делать 64-битные сборки только при запуске компилятора в 64-битном дотнете".
В Nemerle тоже хотели решить этим способом, но , к сожалению, так и не довели до конца
https://github.com/rsdn/nemerle/tree/ikvm

>>> Нет хорошей поддержки *NIX систем. Конечно в Mono есть баги и нужно их учитывать, но с поддержкой Mono можно было бы использовать язык для мобильных приложений. Кроме того это увеличивает количество людей , которым язык мог бы быть интересен.
K>По идее там не заводится только компилятор, результирующие сборки работают нормально, так что с Xamarin-овскими утилитами, заточенными на работу в VS принципиальных и неустранимых проблем быть не должно. Xamarin Studio же до сих пор представляет из себя нечто малоюзабельное: несмотря на то что уже пятый год использую Mono в продакшне на серверсайде, для разработки применяем исключительно VS.
Только невозможна кросс-компиляция и поэтому с Xamarin не пойдет.

K>Принципиальный вопрос на самом деле немного в другом. Если в дальнейшем планируется переход на Nitra, имеет ли вообще сейчас смысл трогать хоть как-то компилятор и стандартную библиотеку (немалую часть которой составляют макросы, которые тоже придётся полностью переписывать)?
Сейчас Nitra это не компилятор, а парсер.
Я не знаю сроки окончания его, но пока его не закончат о компиляторе Nemerle2 вообще речи и не идет.

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

_NN>Только невозможна кросс-компиляция

А в чём там основная проблема со сборкой? Вы же там с lambdalice что-то ковыряли, на чём застряли? Я немного знаю потроха Mono, может, подскажу что.

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

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

_NN>>Только невозможна кросс-компиляция

K>А в чём там основная проблема со сборкой? Вы же там с lambdalice что-то ковыряли, на чём застряли? Я немного знаю потроха Mono, может, подскажу что.

Я о том, что компилятор не может же компилировать для других версий фреймворка.

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

_NN>Я о том, что компилятор не может же компилировать для других версий фреймворка.

Mono же вроде как сиренево, с какой версией слинкованы сборки (там даже есть ключ --runtime= для явного указания, а в списке рассылки было предложение выкинуть отдельную компиляцию для .NET, предлагалось всё запускать с актуальной версией). Опять же можно post-build таском через Mono.Cecil пройтись и поправить нужное.

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

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

_NN>>Я о том, что компилятор не может же компилировать для других версий фреймворка.

K>Mono же вроде как сиренево, с какой версией слинкованы сборки (там даже есть ключ --runtime= для явного указания, а в списке рассылки было предложение выкинуть отдельную компиляцию для .NET, предлагалось всё запускать с актуальной версией). Опять же можно post-build таском через Mono.Cecil пройтись и поправить нужное.

Не знаю, это надо смотреть
Я что-то подумал , что он также как и .NET работает.

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

EP>>>Конкретный пример где ref-counting действительно к месту:
WH>>Это очень простая задача.
EP>Покажи сложнее.
Nitra. Там одно восстановление после ошибок на порядки сложнее.

EP>* работает на специальном железе (привет Лисп-машинам).
Насколько я понял это предыдущая версия. Новая как я понял работает на любом.
В любом случае я не вижу проблем в том, чтобы совершенствовать железо.

EP>* либо на Linux с модифицированным ядром (привет Windows), так как требуется много remaping'ов виртуальных страниц на физические.
EP>* реализация для JVM (привет .NET).
И что?

EP>* в реализации описанной в статье stop-the-world всё-таки присутствует, пишут что меньше миллисекунды.
Ещё они пишут, что можно убрать совсем. Но не видят смысла.

EP>>>У него есть своя область применения
WH>>Нет. Совсем нет.
WH>>Либо точный. Либо без ГЦ вообще.
EP>Раскрой мысль.
Тормоза. Утечки памяти. Невозможность дефрагментации памяти.

EP>Я же написал что есть ограничения. Они, очевидно, есть и даже без уплотнения — скажем raw pointer не удержит объект живым.
Все эти ограничения сводят полезность ГЦ к нулю.

EP>В той конкретной реализации скорей всего нет.
EP>А вообще, при возможности двигать объекты — да, не вижу проблемы создать поколения.
Вот только этой возможности в С++ нет и не предвидится.

WH>>А вот после нормального исключения можно легко восстановиться.
EP>Цель программы обработать данные, а из-за бага обработка невозможна (пусть хоть исключения летают, хоть акробаты), цель не достигнута, хотя по контракту должна была быть
Если у тебя из миллиона запросов один отвалился это конечно неприятно, но в подавляющем большинстве случаев не смертельно.
А вот если у тебя испортилась память и запросы вместо вменяемых данных начали возвращать мусор...

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

AVK>Но с другой стороны — нет никаких проблем разрешить if без else, вместо того чтобы писать вместо этого when.

Слушайте... ну объясните мне за кипиш с if[/else]?! В чем проблема-то? Я правильно понимаю, что если текущий if/else заменить на гипотетический when/else, а if/else "переписать" на опциональный else и сделать вычисляемым всегда в void, то ваша проблема исчезнет? Так?

Ребята... что if, что when — емнип — макросы. Что мешает, сами себе сделать вам красиво?! Или я чего-то не понимаю?

---
С уважением, Константин Сиваков

P.S. А вычисление assignment в void откуда есть у Nemerle пошло, если не секрет? От поляков?

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

EP>Что характерно, в этом самом QuickHeap, который ты пилил 12 лет назад, как раз и можно было использовать Free List, чтобы не тратить дополнительно место под m_pNext в каждом QHBlock, ты тогда этого не знал.

Читаем что написано по твоей ссылке:

A free list is a data structure used in a scheme for dynamic memory allocation. It operates by connecting unallocated regions of memory together in a linked list, using the first word of each unallocated region as a pointer to the next. It is most suitable for allocating from a memory pool, where all objects have the same size.

Может быть ты сам написанное не понял? У меня ровно это и делается. Только у них пулы выбираются статически, так как язык знает о размере объекта, а у меня был С/С++ с размером объекта передаваемым в параметре. Приходилось сначала искать нужный пул по массиву, а потом уже пользоваться тем самым связанным списком свободных блоков.

EP>Но и через 12 лет, когда тебе пытаются дать новую информацию, ты её отказываешься усваивать и начинаешь хамить.

Нет там никакой новой для меня информации. Ты просто пургу несешь.

EP>Кстати, у Алкесандреску про подобные пулы хорошо описано в Modern C++ Design 2001 года

Я за него рад. Я его книжку увидел сильно позже.

Так вот что касается пулов/регионов. Это весьма опасное решение, хотя и быстрое. Примерно так работает и GC, только он гарантирует корректность управления памятью.

Кроме того в продвинутых GC (к сожалению пока что имеющихся только в Яве) есть такие фишки как escape analysis которые позволяют в автоматическом режиме применять оптимизации вроде размещения памяти в пуле или на стеке для объектов не прикапываемых внутри функций.

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

EP>Где здесь для C#/.NET ставить struct? Не говоря уже о том, что эти Circle/Triangle могут быть недоступны для изменений.

Это пример небезопасной манипуляции указателями. После его применения ты будешь следить за временем жизни объектов из shapes вручную.

Тут вокруг носится alex_public и постоянно доказывает, что С++ не С и. Что в нем то контроль по чище Шарпа...

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

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

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

EP>Да, можно и так трактовать, но как раз constexpr и устраняет неоднозначность в трактовке результата. Для этого, собственно, он там и стоит.

Он превращает выражение в вычисляемое во время компиляции. А это == коду макроса. Я тебе любые вычисления на constexpr превращу в аналогичные внутри макроса.

Тут первично "где и когда выполняется код". Если он constexpr или макрос, то выполняться он будет во время компиляции.

Вся разница с макросами заключается в том, что макрос — это точка входа, а не сама функция. Вот как твой пример реализуется на макросах:

macro Buratino(x : int)
{
  // локальные функции выполняемые во время компиляции.
  // В отличии от ограниченных плюсов тут можно выполнять 
  // любой код. Создать экземпляры обычных классов. Сходить в БД...
  def Carlo(x : int)
  {
    buratino(x + 3) + 4
  }
  and buratino(x : int)
  {
    if (x <= 0)
      Carlo(1) + 2
    else
      x + 5
  }
  
  <[ $(buratino(x)) ]>
}

Вызов аналогичен.

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

EP>>Да, можно и так трактовать, но как раз constexpr и устраняет неоднозначность в трактовке результата. Для этого, собственно, он там и стоит.
WH>В этом случае мы имеем два макроса.

Один

Автор: VladD2
Дата: 13.10.14

. Макрос не функция, а точка входа.

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

EP>Почему? constexpr функция тоже макрос?
EP>Buratino можно вызывать с runtime значениями, брать адрес и т.п.

Ну, возьми адрес глобальной переменной. Хе-хе.

ЗЫ

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

А макрос — это точка расширения для компилятора. Указание, что вот в этом месте (где идет ссылка на макрос) нужно произвести некие вычисления и сгенерить на их основе некий код.

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

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

_>Инфраструктура языка это прежде всего: множество родных библиотек, поддержка для него в основных индустриальных инструментах и возможно несколько родных инструментов, большее сообщество разработчиков.

Какие проблемы с библиотеками и инструментами? Уж у Немерла с ними сильно лучше чем в С++ (где брать чужие библиотеки вообще приключение). Но что-то мне подсказывает, что ты сейчас мне начнешь рассказывать обратное.

Сообщество? Так вот сидят эти потенциальные члены сообщества и ищут причину чтобы не смотреть или фатальный недостаток чтобы отказаться.

Мне с самого начала казалось, что вот есть хороший язык. Люди должны его оценить, создать сообщество. Далее создать качественные инструменты и библиотеки — это дело техники. Тем более, что библиотеки уже есть в больших количествах в дотнете.

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

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

А далее замкнутый круг. Без комьюнити не сделать качественной реализации той же поддержки IDE, так как объем работ большой, возможности автоматизации низкие, и куча непонятного и плохо документированного (или вообще не документированного) API от Microsoft. Плюс баги в SRE от того же производителя.

И вот выходит великий язык Свифт который примерно на 90% == немерл, только без перегрузок, макросов и прочих мелких вкусностей. Имеет он ровно две новые фичи, которые по сути сахар. Тулов к нему особых нет. Библиотеки ни чем не отличаются от немерловых. Но сообщество возникнет обязательно! Надо только запретить писать под свои продукты на чем либо кроме этого языка.

А теперь задумаемся что же такого скрывается за этой "инфраструктурой"? Да ничего технического! Только бабло и известность. И выходит, что богатый и известный может протолкнуть и говно. Надо лишь его в красивую обертку закатать, отполировать чтобы блестело, и распиарить по сильнее. Да даже и пиарить то не надо. Брэнд же уже ОГО-ГО.

Но такие как вы будут учить как надо делать. Что надо делать. Как маркетинг проводить... И это вместо того чтобы взять и помочь в развитии.

Вот не устраивает тебя дотнет. Замечательно! Давно хотели нэйтив-компиляцию на базе той же LLVM залудить. Но рук то на все не хватает. Вот взялся бы в свободное от работы (а то и рабочее) время и помог реализовать эту амбициозную задачу. Был у нас нативный немерл, который и по производительности уже мало чем С++ уступал бы.

Но ведь фига два ты возьмешься помогать. Критиковать то куда проще. Правда?

VD>>С родителями у него нет проблем. У них много бабла и пиара. Это ты имеешь в виду под инфраструктурой?

_>См. выше. Сейчас конечно же ещё не всё есть, но очевидно что 100% будет. Т.е. уже даже сейчас (ещё до официального выхода) вложение в разработку на Swift'e не будет сильно рискованным шагом.

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

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

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

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

Я считаю, что ты зазнался малость и превозносишь этот С++, так как сотворил себе из него кумира.

Ничего особого в С++ нет. То что ты называешь квалификацией — то всего лишь натренированность обходить грабли и решать проблемы вроде управления памятью.

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

А то что на языке не могут писать разные криворукие и нужно много тренироваться — это минус. Всегда есть куча рутинной работы которую лучше переложить на не самых одаренных. В правильно спроектированном языке тебе не придется потратить времени больше чем они на выискивание их багов. В С++ — придется.

Хотя я лично предпочитаю маленькие команды проффесионалов (на любом языке). Но прекрасно понимаю, что команд в 40 может сделать больше чем команда из 3 с супер-языком.

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

VD>>Ну, еще ниши где управляемые языки не применимы (драва, например).

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

Таких ниш очень мало в последнее время. Вот уже поддержку IDE для С++ на Яве пишут.

_>Хы, я как раз Питончик люблю и везде его советую. )))

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

VD>>Вот ты над чем на работе работаешь?

_>C++, спец. язык для SIMD, Python, Prolog, JS и ещё куча всяких узкоспециализированных (типа xslt, wix, plantuml, и т.д.).

Я спрашивал не на чем, а над чем.

В прочем, это тоже интересно.

Кстати, сколько ты программ на C# (про Немерл просто умолчим) написал?

А то я чувствую, у нас с тобой интересный разговор получается. Я то на С и С++ пописал не мало. Лет 10, примерно, писал. Ну, да бросил я его до выхода С++14 (который еще толком и не реализован нигде), где язык малость подтянули до современного уровня. Но все же я прекрасно понимаю о чем говорю. А вот на каком уровне ты знаком с тем же дотнетом?

VD>>Очнись. Переход с С++ на C# шел все прошлое десятилетие. В MS VS объем С++ кода сократился со 100%, то 20. А в скором времени и его не станет.

_>О да, в фантазия MS. )))

Хороши такие фантазии. Энтерпрайз весь на управляемых языках. Самые крутые тулы для разработчиков тоже на них. Остались разве что 3D-игры, ОС и браузеры. Остальные сферы в лучшем случае имеют аналоги на управляемых языках.

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

Я с твоего ЧСВ просто балдею! Ты типа "профессионалка"! А на бизнес лохи работают. Для бизнеса, между прочем, пишется вполне себе коробочный софт. И работают там вполне себе профессионалы и высококлассные специалисты. Многие в прошлом работали на том же С/С++. Так что ты бы уж так не зазнавался говоря о бизнесе.

Кроме того не бизнесом единым. Погляди на тулинг для тех не программистов. Решарпер, ИДЕА, НетБинс, Эклипс — это все продукты написанные на дотнете или яве. И самое смешное, что тулинг для С++ на этих же продуктах делается.

_>Никто и не говорит, что C++ — это идеал. Просто ничего лучшего пока не видно. Ну точнее есть D и в перспективе Rust, но они пока хороши только как сами языки, а вот инфраструктуры за ними никакой...

Я эту песню слышал уже 100 раз. Начни сначала использовать этот Ди или Раст, а потом уже про инфраструктуру говори. Будет таких как вы хотя бы сотня человек и вы сами всю инфраструктуру сделаете. Причем такую какая вам нужна.

Уверен, что ты на том же Ди так ни одного реального проекта не написал.

VD>>C# — это банально более продуманный и последовательный язык с автоматическим управлением памятью на котором проще писать. Проще и все тут. Достаточно попробовать написать несколько приложений и вопрос отпадет сам собой.

_>Это не верная формулировка.

Это с твоей точки зрения. А ты этот язык не знаешь. Я же писал и на том, и на другом. И

_>Для специалиста как раз на C++ может оказаться проще. Правильная формулировка такая: низкоуровневому программисту проще писать на Java/C#, чем на C++. И это действительно чистая правда.

Низкоуровневый программист — это что? Тот кто биты перемалывает что ли?

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

_>Ну так и про C# у меня точно такое же мнение. У него есть своя ниша, в которой он очень хорош. Причём если считать в программистах, а не в инсталляциях софта, эта ниша ещё и побольше чем у C++.

У C# тоже есть свои проблемы. Но многие проблемы C++ он успешно преодалел. Тот же С++14 во многом нагоняет C#. Убогость инициализаторов меня всегда в С++ бесила. Всякие вариадик-шаблоны и констэкспрешоны немного подтягиваеют С++ к немерлу, но все равно это все не то.

У С++ остается только два реальных преимущества.
1. Минималистичный рантайм.
2. Возможность выжимать из железа последние соки.

Остальное от лукавого.

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

ЗЫ

Ты тут спрашивал меня кое-что. Времени отвечать на все не хватает. Так что отвечу блицом
1. Unsafe в Nemerle реализован в виде макросов и микроскопической правки ядра. На все про все ушло 3 дня работы. Жаль, что на практике так и не применили, так ак о оптимизаций еще руки не дошли. Тормоза что у нас есть все упираются в комбинаторные взрывы (ака экспонента), что ансэйфом не лечится, как ты понимашь.
2. Мое отношение к Ди и Расту — заочное. Говорить серьезно о языках которые я не использовал на практике считаю не очень правильным. Могу только высказать свое мнение о их дизайне.

Ди не плохой продолжатель дела С++ и мог бы быть его заменой. Автору не хватает смелости (автор слишком консервативен). Язык до сих пор пишется на С++ (не забутстраплен), что минус. Отсюда же растут некоторые недостатки (на мой взгляд). В зыке нет паттерн-матчинга и алгеброических типов. На мой взгляд эта важная фича. Та МП то есть в Ди слабовато, хотя и выглядит не плохо на фоне С++. Главное что там есть модульность, безопасность и прочие атрибуты современного языка.

Раст имеет ровно обратные проблемы по сравнению с Ди — слишком новаторский. Он еще попросту не устаканился. У авторов явно не было четкого плана действий (а вы тут еще Немерл в отсутствии концепций обвиняли, гы-гы). Авторы дергаются в разные стороны. То 100500 видов указателей, а потом их под нож. То изменение синтаксиса... Макросы у него есть, но они очень примитивные (насколько я могу судить). Их преимущество — их не надо отдельно компилировать как немерловые. Но это же не дает им быть такими же быстрыми и мощными.

В общем, как замена С++ я скорее выбрал бы Ди. Тем более, что он куда более стабильный. Но ему, как и Немерлу, нужно сообщество по больше. И пока такие как ты не будут примыкать к этому сообществу и не смотря ни на что пользоваться языком, он так и будет слыть "чем-то неготовым".

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

VD>

VD>A free list is a data structure used in a scheme for dynamic memory allocation. It operates by connecting unallocated regions of memory together in a linked list, using the first word of each unallocated region as a pointer to the next. It is most suitable for allocating from a memory pool, where all objects have the same size.

VD>Может быть ты сам написанное не понял? У меня ровно это и делается.

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

Да даже если это не считать существенной частью free list'а, а брать только то что это стэк свободных буферов, то что ты тут-то имел в виду:

VD>Пул же это когда память выделяется большим блоком (пулом) и нарезается для конкретных нужд. Ты ниже это назвал Region-based. Free list же не имеет к нему никакого отношения. Это всего лишь тупой и тормозной алгоритм из дремучих веков.

Free list'ы как раз и используются как основа пулов

VD>Только у них пулы выбираются статически, так как язык знает о размере объекта, а у меня был С/С++ с размером объекта передаваемым в параметре. Приходилось сначала искать нужный пул по массиву, а потом уже пользоваться тем самым связанным списком свободных блоков.

Free list это всего лишь список/стэк свободных блоков, грубо говоря структура данных.
В твоём же примере free list'ов несколько, грубо говоря они являются основой алгоритма управления памятью, а не самим алгоритмом.

VD>Так вот что касается пулов/регионов. Это весьма опасное решение, хотя и быстрое. Примерно так работает и GC, только он гарантирует корректность управления памятью.

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

VD>Кроме того в продвинутых GC (к сожалению пока что имеющихся только в Яве) есть такие фишки как escape analysis которые позволяют в автоматическом режиме применять оптимизации вроде размещения памяти в пуле или на стеке для объектов не прикапываемых внутри функций.

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

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

VD>Мне с самого начала казалось, что вот есть хороший язык. Люди должны его оценить, создать сообщество. Далее создать качественные инструменты и библиотеки — это дело техники. Тем более, что библиотеки уже есть в больших количествах в дотнете.

Люди "должны" — квинтэссенция твоего евангелизма Только узнаел про Немерле и уже должен. Ага.

VD>Причем среди тех кто попробовал почти 100% приятие языка и высокая оценка его возможностей.

Этот аргумент, что харктерно, справедлив и про секты, и про наркоту и тд.

VD>А далее замкнутый круг. Без комьюнити не сделать качественной реализации той же поддержки IDE, так как объем работ большой, возможности автоматизации низкие, и куча непонятного и плохо документированного (или вообще не документированного) API от Microsoft. Плюс баги в SRE от того же производителя.

А как же другие проекты, которые в таких же условиях находились, взять лялих тот же ?

VD>И вот выходит великий язык Свифт который примерно на 90% == немерл, только без перегрузок, макросов и прочих мелких вкусностей. Имеет он ровно две новые фичи, которые по сути сахар. Тулов к нему особых нет. Библиотеки ни чем не отличаются от немерловых. Но сообщество возникнет обязательно! Надо только запретить писать под свои продукты на чем либо кроме этого языка.

Не надо ничего запрещать. Свифт нисколько не Немерл. Свифт очень привычный любому современному разработчику язык, то есть искаропки. Немерл — это макро-ориентированое-программирование.
Фактически, ты хочешь вместе с хорошим языком продать экзотическую парадигму.
Есть один тренд, который ты почему то игнорируешь — даже ООП знает очень мало людей, не говоря об ФП. А ты решил еще и макро-парадигму протащить.

VD>Но такие как вы будут учить как надо делать. Что надо делать. Как маркетинг проводить...

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

>...И это вместо того чтобы взять и помочь в развитии.

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