LINUX.ORG.RU

Ответ на: комментарий от RazrFalcon

C++ очень «простой» /если знаешь 1001 мелочь/.
Та же Visual Studio то же бывает чудит /да еще как/.
Например если остались некоторые не закрытые при debug процессы, ...
Но если знаком с тем «Что делать?», то все Ok!

anonymous
()
Ответ на: комментарий от anonymous

Пока не все библиотеки переписаны под .NET Standard. Некоторые до сих пор только под классический .NET Framework. Также всё ещё много тырпрайзной вебни на старом ASP.NET, которую внезапно могут захотеть пускать на Лине. Ну и Unity 3D само собой. Вряд-ли его перепишут под .NET Core в ближайшее время.

Unicode4all ★★★★★
()
Ответ на: комментарий от fsb4000

У Paritytech - реализация ноды Bitcoin на Rust, Ethereum тоже и еще пачки блокчейнов включая собственные проекты Substrate и Polkadot.

У Grin - основная реализация на Rust. У Libra тоже.

Приватные блокчейны от Bitfury - Exonum.

У Zcash, Monero, Ethereum Classic есть или развиваются важные компоненты на Rust.

anonymous
()

Пусть напишет Gnome4 на расте.

devl547 ★★★★★
()
Ответ на: комментарий от anonymous

Зачем ты все это в кучу свалил? Релевантно здесь только го, но на нем пишут микросервисы, там разумно иметь самодостаточный микроблоб. На расте пишут пока хелловорлды, и то уже огребают проблемы с долгой компиляцией. Как вы собираетесь делать системные либы без so неясно. Хотя ясно, что вы не собираетесь. Это очередной говноклей.

В растишке создавать файлы *.so, а потом подключать их на удивление просто, даже очень просто. Причем даже необязательно создавать и использовать хедеры на сишке.

dave ★★★★★
()
Ответ на: комментарий от dave

Поясню, что это значит при взаимодействии rust <-> *.so <-> rust, минуя сишку.

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

Единственное, что как я написал выше, нужно, чтобы и в либе, и в программе использовался один и тот же алокатор памяти (либо malloc везде, либо jemalloc везде). И крайне желательно, чтобы обе части были скомпилированы одной и той же версией rustc.

dave ★★★★★
()
Ответ на: комментарий от Princesska

Но зато из бесплатных есть гнутый. Причём, он выскочил в результатах одного из запросов по встроенной процедуре сам. Думаю, он со своей задачей должен справляться, скастануть бы кого-нибудь, разбирающегося в теме, если такие на лоре вообще есть.

Для linux здесь немного всё проще: поставил gfortran и хоть что-то можно делать. Но сам gfortran появился и принял приличный вид с gcc 4.1. В связке с mpi вполне себе работает.

С windows немного сложнее: самым простым способом была установка codeblocks из установщика, содержащего gfortran. Но в текущей в состав входит неработающая библиотека, вызывающая падение, кажется, при выводе данных в терминал/файл. Приходится заменять библиотеку, либо ставить mingw64.

Есть pgfortran от pgi compilers (сейчас принадлежит nvidia) с бесплатной community версией (можно пользоваться год с момента выпуска), но для windows требует обязательной установки visual studio. У него 2 варианта, новый из которых основан на llvm. Зато в нём сразу есть плюшки для работы с cuda + openacc. Есть установщик для linux.

Из основанных на llvm + flang ещё есть

  • сам flang (требует патчей к llvm и clang), поэтому в систему нужно ставить с ними отдельно;
  • aocc от amd - в его состав также входят clang и flang;
  • f18 - переписанный на c++ компилятор flang, оба они наработки nvidia. Ожидает принятия в базу llvm;
  • какой-то новый компилятор lfortran - на стадии пре-альфа, тоже использует llvm.

Из платных есть:

  • ifort от intel, для linux можно получить бесплатно в рамках работы над открытыми проектами;
  • упомянутый pgi fortran compiler - платная версия.
  • Absoft;
  • NAG Fortran compiler;
  • IBM XL Fortran;
  • Lahey/Fujutsu Fortran;
  • ряд других.

Все они в разной степени оптимизируют код. Где-то видел бенчмарки для разных типов задач и в зависимости от неё там были разные результаты.

Среди коммерческих естественно присутствует конкуренция.

grem ★★★★★
()
Ответ на: комментарий от the_real_kinik

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

buddhist ★★★★★
()
Ответ на: комментарий от WatchCat

А что конкретно они не открыли? Даже такую жесть как Workflow Foundation выложили, и кому-то даже интересно это поддерживать.

Только в .NET Core попало не все что было в .NET Framework. Многое по причинам необходимости в кроссплатформенности. И уже никогда не попадет.

Например AppDomains - вместо них в NET Core нормальный механизм для загрузки и выгрузки сборок, без пердолинга с маршалингом.

Midael ★★★★★
()
Последнее исправление: Midael (всего исправлений: 2)
Ответ на: комментарий от WatchCat
https://github.com/dotnet/winforms                         This repo contains Windows Forms for .NET Core

https://github.com/dotnet/wpf                              This repo contains Windows Presentation Foundation (WPF) for .NET Core

https://github.com/Microsoft/WPF-Samples                   Repository for WPF related samples Microsoft

----------------------------------------
https://github.com/aseem/WPF                               Code for WPF in 24 Hours
https://github.com/dotnet/winforms                         This repo contains Windows Forms for .NET Core

https://github.com/EmilianoElMariachi/WPF                  Contains library to help building WPF applications

https://github.com/Code52/DownmarkerWPF                    MarkPad - a visual Markdown editor (inspired by the Downmarker project) http://code52.org/DownmarkerWPF/


https://github.com/aelij/WPFContrib                        A collection of WPF controls and utility classes I've accumulated over the years

https://github.com/aelij/FasterReflection                  Utilizes System.Reflection.Metadata to read type information very fast and without locking assembly file
anonymous
()
Ответ на: комментарий от vertexua

Первыми нативными языками по прежнему являются C и ассемблер для той платформы что под рукой, потому что они показывают нейтив как он есть. Без прекрас и не засирает мозг не нужными на старте абстракциями. Так что gcc и какой-нибудь fasm, вот что нужно.

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

ixrws ★★★
()
Последнее исправление: ixrws (всего исправлений: 1)
Ответ на: комментарий от vertexua

двусвязный список
Должны лежать рядышком в векторе
ссылаться оп индексам
выделяться из free list

А потом этот вектор, скажем, на пару десятков миллионов элементов приходится ресайзить. «Просто константа плохая» — ответит типичный растаман.

И неплохая реализация в С++ будет делать что-то похожее

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

kawaii_neko ★★★★
()
Ответ на: комментарий от kawaii_neko

А потом этот вектор, скажем, на пару десятков миллионов элементов приходится ресайзить.

Предлагаешь просто дергать аллокатор миллион раз? Нуну. Есть случаи когда LinkedList лучше ArrayList говорили они. А потом пришли современные процессоры с гигантскими кешами и сказали что лучше они 1 МБ скопируют вместо этого дерьма

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

А потом пришли современные процессоры с гигантскими кешами и сказали что лучше они 1 МБ скопируют вместо этого дерьма

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

anonymous
()
Ответ на: комментарий от anonymous

Mono – это часть xamarin, т.е. мобильная реализация исполняемой платформы .net.

Пока даже в планах нет, чтобы .net core заменил реализацию xamarin.

Хотя конечно логично всё свести в одно, но много гемора.

mono ★★★★★
()
Последнее исправление: mono (всего исправлений: 1)
Ответ на: комментарий от WatchCat

Больше нет разделения на .NET Framework и .NET Core.

Есть .NET 5.0, который включает в себя разные рантаймы.

Mono теперь не альтернативная реализация .NET, а самая настоящая часть .NET 5.0.

mono ★★★★★
()
Ответ на: комментарий от Deleted

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

anonymous
()
Ответ на: комментарий от mono

Больше нет разделения на .NET Framework и .NET Core.

У них все очень запутано, как обычно

Они сделали стандарт, реализуемый рантаймами. При этом стандарт шире рантаймов - например в стандарте есть AppDomains, но реализация AppDomains есть, например только в NET Framework (может еще в моно, но тут надо копаться смотреть)

Дальше интереснее - NET Framework 4.8 поддерживает NET Standard 2.0. Версия стандарта 2.1 - уже нет, т.к. много ломающих изменений в рантайме. Так и останется на 2.0.

NET Core, несмотря на поддержку стандарта 2.1 не реализует его полностью (на этом месте я перестал понимать их логику - те же самые аппдомены в стандарте они оставили, но никто из поддерживающих версию 2.1. рантаймов их не реализует)

NET Core будет двигаться дальше вместе со стандартом и в следующей версии будет переименован в .NET 5.0

Сказать что граница между фреймворком и кором стерта - имхо нельзя, т.к. 4.x это огромная гора легаси. Причем сами МС не рекомендуют никуда портировать сущестующие проекты, и вроде как обещают пожизненную поддержку

Midael ★★★★★
()
Ответ на: комментарий от a1batross

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

anonymous
()
Ответ на: комментарий от anonymous

Нет, этим я и сам пользуюсь. Да, бинари сильно жиреют.

Я же именно о малых бинарях и стандартой библиотеке поставляемой с оффтопиком.

a1batross ★★★★★
()
Ответ на: комментарий от kawaii_neko

на пару десятков миллионов элементов приходится ресайзить

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

Связанный список - очень нишевая штука.

red75prim ★★★
()
Последнее исправление: red75prim (всего исправлений: 2)
Ответ на: комментарий от red75prim

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

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

Владимир

anonymous
()
Ответ на: комментарий от red75prim

Что, и достоинства сохраняются? Вроде O(1) на вставку в произвольное место. Не верю

Не совсем как массив, но на порядки эффективнее Кнутовских списков.

anonymous
()
Ответ на: комментарий от anonymous

А, ну да. Есть разные структуры данных с разными компромиссами. Только связанным списком называется вполне определенная структура данных.

red75prim ★★★
()
Ответ на: комментарий от red75prim

А, ну да. Есть разные структуры данных с разными компромиссами. Только связанным списком называется вполне определенная структура данных.

Дружище, это и есть тот связанный список о котором вы говорите, но у
которого возможно позиционирование «как в массиве».

Владимир

anonymous
()
Ответ на: комментарий от red75prim

Только связанным списком называется вполне определенная структура данных.

Просьба к вам не судить о том, в чем не разбираетесь.

Владимир

anonymous
()
Ответ на: комментарий от anonymous

Кафедра со специализацией по терминологии? И где же связанным списком называют какую-то структуру данных с константным временем доступа к элементам?

red75prim ★★★
()
Ответ на: комментарий от anonymous

Владимир, если ты такой разбирающийся, где твой багрепорт gcc, что связанный список они, как и любой другой компилятор С++, реализуют через ноды и указатели без всяких векторов?

fsb4000 ★★★★★
()
Ответ на: комментарий от red75prim

И где же связанным списком называют какую-то структуру данных с константным временем доступа к элементам?

Очевидно на ЛОР.

Владимир

anonymous
()
Ответ на: комментарий от fsb4000

Владимир, если ты такой разбирающийся, где твой багрепорт gcc, что связанный список они, как и любой другой компилятор С++, реализуют через ноды и указатели без всяких векторов?

«Нельзя объять, необъятное».
Разрабатываю некую платформу для разработки программ, ... и работы в ней - ВЫШЕ КРЫШИ.

PS: «Каждому, свое».

anonymous
()
Ответ на: комментарий от fsb4000

как и любой другой компилятор С++, реализуют через ноды и указатели без всяких векторов?

Они все правильно делают, но имеется такое понятие как - «Структуры данных» и оно не является догмой.

anonymous
()
Ответ на: комментарий от fsb4000

реализуют через ноды и указатели без всяких векторов?

STL хороша, но поверьте имеются и иные подходы /в них также имеются вектора, .../.

anonymous
()
Ответ на: комментарий от fsb4000

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

dave ★★★★★
()
Ответ на: комментарий от dave

Ну, чего спорите из-за пустяков?)

Вот молодчик.
Видно, что понимает - «Вектора, списки, ...» это структуры и они могут быть не обязательно такими, как учат «деды с бородами».

anonymous
()
Ответ на: комментарий от anonymous

Эээ нет, он сказал бы - «Давно пора».

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.