мой приоритет - иметь как можно больше контроля в своих руках
.net по сути, уже позволяет писать практически на ассемблере. Есть интристикс апи, которым мы иногда даже пользуемся. Есть конструкции которые позволяют не покидать стек. Есть возможность работать, практически, с нулевой актиностью GC. По сути, (кроме граничных случаев) я не вижу смысла писать на тех же плюсах. Выигрыш в производительности в большинстве случаев, будет минимальный. При том, что я упускаю вопрос - а нужна ли вам такая производительность. Какой контроль еще Вам нужен, я не понимаю.
Я бы с удовольствием бы использовал механизм вроде #define из C++
ух... мне кажется, Вас сейчас здесь забьют :) Я лично такого дерьма насмотрелся с этим препроцессором... с этим пунктом я точно не соглашусь.
Этот "синтаксический сахар" начинает подбешивать потихоньку.
Это к психотерапевту.
Подается как "самое новое и крутое"
Ничто,никому не подается. Не хочешь - не используй. Самое новое и крутое, обычно, происходит в рантайме, а не в языке. У инженера должна быть возможность писать качественный софт и возможность его оперативно поддерживать, а не радоваться новому свитчу.
Смотришь в IL - а там все тоже самое, что и было раньше,
Это и есть синтаксический сахар.
Если бы можно было самому делать такой "синтаксический сахар" без черезмерных усилий
Есть Розлин - вперёд. Пусть только все ИДЕшки научатся это поддерживать. Я не вижу в этом особой полезности.
Ну да... обычно, при переходе в другую команду, со старым плюсовым проектом, первое задание, зачастую на несколько дней - скомпилить проджект. Часто это заканчивалось тем, что сидели и компилили всей командой. "Главное один раз сбилдить, а потом главное не удаляй статические либы.. ибо заново". Еще когда-то был случай когда в процессе "разработки" каким-то хреном добавили кросс-зависимость между двумя библиотеками. И получилось, что А не билдится без Б, а Б не билдится без А... В том же .net, такой проблемы не может быть по определению..
Та нет... если ты делаешь, хоть что-то более-менее требующее умственных затрат, то ты 99% времени читаешь и изучаешь какой-то вопрос. Набор текста, это просто набор текста. Вводи его хоть мышкой.
Надеюсь, что так и есть. Я начал смотреть, после того как прочитал, что Линус "одобрил". Я даже где-то в комментах писал, что если даже этот "Му**к" (в хороше смысле) одобрил, то видимо стоит взглянуть :D
От мягких и шелковистых волос, я бы тоже не отказался ))
аа.. вот балда.. значит наврал. Там по ссылке, в коммите есть юнит тесты. Gc Я был уверен, что сделали. Даже в .NET Blog упоминали, что добавили (limited).
long allocatedBytesBefore = GC.GetAllocatedBytesForCurrentThread();
int testResult = test();
long allocatedBytesAfter = GC.GetAllocatedBytesForCurrentThread();
ну, и между ними засунуть, что-то. Да, только не забыть обратиться после, дабы реально не вырезал. У меня получалось ноль на примитивных классах.
Я на прошлой неделе, кажется, еще писал тест на пятой коре. В GC появился метод который возвращает аллоцированные байты. Выделяет класс. Смотрите разницу. Класс в стеке. выделено ноль. Коммит, вроде бы тоже как в мастере.
Писать можно и без сборки мусора. Пулинг никто не отменял. Зачем? Если сравнивать си, то это безопаснее. В этом критичном к производительности куске после, находят парочку дыр. Но, да, есть Rust. Я его плохо знаю, пока не в курсе насколько он справляется с типичными сишными проблемами.
Уже была написана, как тестовый проект.Да Singularity называется. Если верить Торвалдсу, то ООЯ не очень хорошо подходят для написания операционных систем.
(не совсем понимаю почему)
но может ему виднее. На том же Шарпе, вполне можно писать достаточно низкоуровнево.
Ну, я начал учить его с 4.0 кажется. Но до этого уже немного знал Си. Это было сто процентов проще нежели сейчас. Могу только пожелать терпения. .net очень обширный.
Оо да... В добавок, уже на многие вопросы, которые были актуальны в 2010, перестали таковыми быть сейчас. К примеру, вопросы об аллокации классов уже не совсем не однозначные ибо в core 3.0 сделали escape analysis и теперь при должных условиях класс улетает в стек. Или вот сегодня утром читал свежевышедшую статью (на хабре есть её укороченная версия) Performance improvents in .NET 6.0 . Насколько понимаю, что .NET 6.0 при определенных условиях сможет сапрессить баудс чек массивов. (Я её еще не дочила до конца ибо она огромная, но подозреваю, что сюрпризов там достаточно).
Но людей с определённым профессиональным опытом настораживает попытка создать универсальную платформу для всего сразу.
Ну, люди с "определённым профессиональным опытом" должны понимать (я уверен что понимают), что ситуации бывают разные и иногда нужно выжимать из кода всё, что возможно. Пусть только в определённых точках кодовой базы. Убеждения, что для этого нужно писать код на Си, они хреновенько выглядят на практике ибо их трудно поддерживать, появляются гетерогенные (или как это назвать) проджекты с обертками для нативных вызовов. Тяжело билдить. Тяжело поставлять. Неприятно (иногда) дебажить.
Единственную серьезную проблему, которуя я здесь вижу, это офигевание человека который через пару лет начнёт учить .net. С другой стороны, никто не форсит использоваться сразу всё. Вполне себе можно погружаться постепенно и более опытные товарищи подскажут, как платформа позволяет это же сделать еще лучше.
Скорее они разобьют об наноголову космокирпич.
Кажется он
http://e4004.szyc.org/iset.html
Поссылке даже его можно запрограммировать.
Всегда на страже.
.net по сути, уже позволяет писать практически на ассемблере. Есть интристикс апи, которым мы иногда даже пользуемся. Есть конструкции которые позволяют не покидать стек. Есть возможность работать, практически, с нулевой актиностью GC. По сути, (кроме граничных случаев) я не вижу смысла писать на тех же плюсах. Выигрыш в производительности в большинстве случаев, будет минимальный. При том, что я упускаю вопрос - а нужна ли вам такая производительность. Какой контроль еще Вам нужен, я не понимаю.
ух... мне кажется, Вас сейчас здесь забьют :) Я лично такого дерьма насмотрелся с этим препроцессором... с этим пунктом я точно не соглашусь.
Это к психотерапевту.
Ничто,никому не подается. Не хочешь - не используй. Самое новое и крутое, обычно, происходит в рантайме, а не в языке. У инженера должна быть возможность писать качественный софт и возможность его оперативно поддерживать, а не радоваться новому свитчу.
Это и есть синтаксический сахар.
Есть Розлин - вперёд. Пусть только все ИДЕшки научатся это поддерживать. Я не вижу в этом особой полезности.
"но С++ исходит из предположения, что программист не идиот" - так появился Go? :)
"Раньше было лучше" (с)
C, C++,VB6, JS, C#, VB.NET.... Java
Ну да... обычно, при переходе в другую команду, со старым плюсовым проектом, первое задание, зачастую на несколько дней - скомпилить проджект. Часто это заканчивалось тем, что сидели и компилили всей командой. "Главное один раз сбилдить, а потом главное не удаляй статические либы.. ибо заново". Еще когда-то был случай когда в процессе "разработки" каким-то хреном добавили кросс-зависимость между двумя библиотеками. И получилось, что А не билдится без Б, а Б не билдится без А... В том же .net, такой проблемы не может быть по определению..
Та нет... если ты делаешь, хоть что-то более-менее требующее умственных затрат, то ты 99% времени читаешь и изучаешь какой-то вопрос. Набор текста, это просто набор текста. Вводи его хоть мышкой.
Надеюсь, что так и есть. Я начал смотреть, после того как прочитал, что Линус "одобрил". Я даже где-то в комментах писал, что если даже этот "Му**к" (в хороше смысле) одобрил, то видимо стоит взглянуть :D
От мягких и шелковистых волос, я бы тоже не отказался ))
Всё я нашел
В комментариях указанно, что выключено по-умочанию https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-3-0/.
Дальйшую судьбу узнал вот только от тебя.
Спасибо, за уточнение!! Дейсвительно запутали еще больше.
Инлайнер - да. Нужно будет вечером засеть и разобрать внимательно статью. Капец она здоровая.
аа.. вот балда.. значит наврал.
Там по ссылке, в коммите есть юнит тесты.
Gc
Я был уверен, что сделали. Даже в .NET Blog упоминали, что добавили (limited).
long allocatedBytesBefore = GC.GetAllocatedBytesForCurrentThread();int testResult = test();long allocatedBytesAfter = GC.GetAllocatedBytesForCurrentThread();ну, и между ними засунуть, что-то. Да, только не забыть обратиться после, дабы реально не вырезал. У меня получалось ноль на примитивных классах.
Я на прошлой неделе, кажется, еще писал тест на пятой коре.
В GC появился метод который возвращает аллоцированные байты. Выделяет класс. Смотрите разницу. Класс в стеке. выделено ноль. Коммит, вроде бы тоже как в мастере.
https://github.com/dotnet/coreclr/pull/20814
Они описывают как "limited support". Но всё же должен быть.
Тестил я на очень простом кейсе. Собственно, и сам тест я взял из юнит тестов к коммиту. Было интересно поиграться.
Писать можно и без сборки мусора. Пулинг никто не отменял. Зачем? Если сравнивать си, то это безопаснее. В этом критичном к производительности куске после, находят парочку дыр.
Но, да, есть Rust. Я его плохо знаю, пока не в курсе насколько он справляется с типичными сишными проблемами.
Уже была написана, как тестовый проект.Да Singularity называется. Если верить Торвалдсу, то ООЯ не очень хорошо подходят для написания операционных систем.
(не совсем понимаю почему)
но может ему виднее. На том же Шарпе, вполне можно писать достаточно низкоуровнево.
Хз, может когда-то будет.
Ну, я начал учить его с 4.0 кажется. Но до этого уже немного знал Си. Это было сто процентов проще нежели сейчас. Могу только пожелать терпения. .net очень обширный.
Оо да... В добавок, уже на многие вопросы, которые были актуальны в 2010, перестали таковыми быть сейчас.
К примеру, вопросы об аллокации классов уже не совсем не однозначные ибо в core 3.0 сделали escape analysis и теперь при должных условиях класс улетает в стек. Или вот сегодня утром читал свежевышедшую статью (на хабре есть её укороченная версия) Performance improvents in .NET 6.0 . Насколько понимаю, что .NET 6.0 при определенных условиях сможет сапрессить баудс чек массивов. (Я её еще не дочила до конца ибо она огромная, но подозреваю, что сюрпризов там достаточно).
Верно! Не уверен, но я видел протитим delegate*, который не аллоцирует делегат.
Но людей с определённым профессиональным опытом настораживает попытка создать универсальную платформу для всего сразу.Ну, люди с "определённым профессиональным опытом" должны понимать (я уверен что понимают), что ситуации бывают разные и иногда нужно выжимать из кода всё, что возможно. Пусть только в определённых точках кодовой базы. Убеждения, что для этого нужно писать код на Си, они хреновенько выглядят на практике ибо их трудно поддерживать, появляются гетерогенные (или как это назвать) проджекты с обертками для нативных вызовов. Тяжело билдить. Тяжело поставлять. Неприятно (иногда) дебажить.
Единственную серьезную проблему, которуя я здесь вижу, это офигевание человека который через пару лет начнёт учить .net. С другой стороны, никто не форсит использоваться сразу всё. Вполне себе можно погружаться постепенно и более опытные товарищи подскажут, как платформа позволяет это же сделать еще лучше.
Ну да, есть интристики.. по сути уже можно начиная с Core 3.0.