Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, lpd, Вы писали:
lpd>>Слышал но не видел, что у Java удобные системы сборки. В любом случае make несколько стар. Ops>Так что с легаси-то делать?
Главное перевести библиотеки для постепенного перевода проектов. А make можно продолжать поддерживать, как и текущий stl.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re[20]: так все же gcc или clang компилирует этот код правильно?
Здравствуйте, alex_public, Вы писали:
1>>Собственно на этом можно заканчивать... _>Ну т.е. в итоге так и записываем: лямбды в C# не сравнимо слабее по функциональности C++ реализации.
Ага. Лямбды в C# не позволяют получить разный результат на выходе программы в зависимости от компилятора.
Ты кстати так и не смог объяснить что должно быть на входе, что на выходе. Код ради кода.
_>Stop world шёл у меня отдельным пунктом (недетерминированные задержки). А неэффективность появляется в других местах: повышенная косвенность (это критично для современных процессоров, т.к. данные начинают идти не из кэша), невозможность нормальной работы с указателями (т.е. недоступны самые эффективные техники типа арифметики указателей и SIMD) и т.д. и т.п.
JIT убивает повышенную косвенность. C# no safe нормально работает с сырыми указателями, адресной арифметикой и неуправляемой памятью. Не говоря о том, что часть этих вещей работает и сама по себе через JIT. То, что языки с управляемой памятью и JIT имеют свои проблемы ну никак не отменяет того, что ты привел крайне неудачный пример, в котором они незаметны.
Пойми я же ничего не имею против, того что C#/Java не в меру жрут память и могут подтормаживать, но блин, ты привел именно тот случай когда этого не будет. Вот и всё.
_>>>Как на Java/C# получить автоматическое закрытие всех соединений сразу после удаления массива? На C++ это будет просто закрытие соединение в деструкторе объекта обёртки. 1>>На Java/C# это будет просто закрытие соединений в деструкторе объекта обертки? Я вообще потому и прошу пример кода, что в упор не вижу разницы. _>Ну так а в какой момент будет вызван этот самый деструктор? )))
Если под удалением массива ты имеешь в виду область видимости, то в момент выхода из using.
Если динамическое управление, то IDisposable, и в терминах C# не деструктор, а финализатор.
Здравствуйте, Ops, Вы писали:
SVZ>>Да, есть нагруженный софт. К нему и требования не такие, как к ERP. Ops>Угу. ERP — это электронное перекладывание бумажек, и это далеко не всегда основное занятие бизнеса.
Зато очень распространенное и там Шарп/Ява очень уместны.
SVZ>>Дабы не скатываться в офтопик расскажи лучше, выиграет ли этот софт, если С++, по мысли ТС, "прокачать" до Явы — навертеть стандартную либу, расширить язык (непонятно, правда, в какую сторону). Ops>Либу — только за, при условии низкой связности модулей. 100500 велосипедов, раскиданных по разным крупным библиотекам, реально задалбывают, и часто вынуждают писать свои велосипеды под проект. Но тут другая сложность, в отличие от явы с дотнетом, здесь мы имеем неповоротливый комитет и кучу формалистики, для подобной библиотеки такой подход нежизнеспособен. Да, есть буст, который развивается по гораздо лучшей модели, но там уже начинается коллективное безответственное с поддержкой некоторых библиотек. Ну и до сих пор слышу про его категорическое неприятие и запрет в некоторых проектах, из которых процент аргументированных в окрестностях 0.
С библиотекой тут получается интересное. С одной стороны хочется иметь всё "из коробки", а с другой стороны всегда будет ситуация, когда вроде бы инструмент есть, а по каким-то критериям не подходит. Вроде бы и надо велосипед писать, а западло — есть же "стандартный"
Сейчас проще — либо буст, либо велосипед (свой или чужой)
С запретом Буста я сталкивался в двух проектах, оба были связаны с кривыми компиляторами С++ на специфических платформах (HP-UX, z/OS). Там не то что буст, стандартную-то либу можно было использовать с оглядкой.
SVZ>>Моё ИМХО — нет, не выиграет. Только инструмент (С++) будет испорчен. Ops>С чего вдруг он будет испорчен? При всех его минусах, библиотекой с ним ничего не сделаешь.
Ну библиотекой, наверное, не испортишь. В конце концов никто не заставляет использовать только стандартную библиотеку.
А вот если попытаться впихнуть в язык что-то невпихуемое, то запросто.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>С библиотекой тут получается интересное. С одной стороны хочется иметь всё "из коробки", а с другой стороны всегда будет ситуация, когда вроде бы инструмент есть, а по каким-то критериям не подходит. Вроде бы и надо велосипед писать, а западло — есть же "стандартный" SVZ>Сейчас проще — либо буст, либо велосипед (свой или чужой)
Ну так и со стандартной библиотекой так же, она тоже не всегда подходит, но в большинстве случаев годится, при этом дает хорошую переносимость и единообразность там, где не надо выжимать такты или делать что-то специфичное. Ничего не мешает ее расширить исходя из такого подхода, сразу намного легче станет. Причем это делается, добавляют библиотеки из того же буста. Только вот очень медленно, и при этом развитие включенных в стандарт библиотек замораживается.
SVZ>С запретом Буста я сталкивался в двух проектах, оба были связаны с кривыми компиляторами С++ на специфических платформах (HP-UX, z/OS). Там не то что буст, стандартную-то либу можно было использовать с оглядкой.
Ну вот даже на форуме часто пишут "буст не предлагать", в т.ч. для распространенных платформ. Почему-то многие его воспринимают как что-то монолитное, исключительно на многоэтажных шаблонах, вдобавок считают, что и для использования придется их писать. А ведь и с твоими компиляторами наверняка можно было что-то использовать практически искаропки.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[21]: так все же gcc или clang компилирует этот код правильно?
Здравствуйте, 11molniev, Вы писали:
_>>Ну т.е. в итоге так и записываем: лямбды в C# не сравнимо слабее по функциональности C++ реализации. 1>Ага. Лямбды в C# не позволяют получить разный результат на выходе программы в зависимости от компилятора. 1>Ты кстати так и не смог объяснить что должно быть на входе, что на выходе. Код ради кода.
Данный нюанс не имеет никакого отношения к лямбдам, а является всего лишь следствием особенностей данного конкретного кода. Если есть желание, то можем и его обсудить. Для начала начнём с вопроса о том, в каких языках с наличием функции map (или аналога) в стандарте закреплена очерёдность обхода элементов. Потом можем обсудить особенности использования нечистых функций (типа вывода на консоль) в функциях типа map и т.д. и т.п. Но к лямбдам это не будет иметь никакого отношения — всё тоже самое касается и обычных функций, причём в любых языках.
_>>Stop world шёл у меня отдельным пунктом (недетерминированные задержки). А неэффективность появляется в других местах: повышенная косвенность (это критично для современных процессоров, т.к. данные начинают идти не из кэша), невозможность нормальной работы с указателями (т.е. недоступны самые эффективные техники типа арифметики указателей и SIMD) и т.д. и т.п. 1>JIT убивает повышенную косвенность. C# no safe нормально работает с сырыми указателями, адресной арифметикой и неуправляемой памятью. Не говоря о том, что часть этих вещей работает и сама по себе через JIT. То, что языки с управляемой памятью и JIT имеют свои проблемы ну никак не отменяет того, что ты привел крайне неудачный пример, в котором они незаметны.
1>Пойми я же ничего не имею против, того что C#/Java не в меру жрут память и могут подтормаживать, но блин, ты привел именно тот случай когда этого не будет. Вот и всё.
Так весь фокус в том, что мы не можем (в Java/C#) использовать для данного нюанса сборщик мусора, а для всего остального что-то другое, более эффективное. Т.е. для того, чтобы у нас появилась возможность автоматического решения в данном нюансе, мы автоматически накладываем ограничение по тормозам вообще на всё приложение.
_>>Ну так а в какой момент будет вызван этот самый деструктор? ))) 1>Если под удалением массива ты имеешь в виду область видимости, то в момент выхода из using. 1>Если динамическое управление, то IDisposable, и в терминах C# не деструктор, а финализатор.
Вот про using и IDisposable речь и идёт — это и есть рукопашный код в стиле C.
Re[20]: так все же gcc или clang компилирует этот код правильно?
Здравствуйте, lpd, Вы писали:
lpd>Соседний топик "java vs. c++" навевает вопрос причин отсутствия фреймворков для разработки корпоративных приложений(вроде Spring, Struts) и серверов приложений на C++.
Вот с этим явовским "корпоративные приложения", можете оставаться в яве по уши. На С++ можно писать
любые приложения, решающие любые задачи. Хоть корпоративными их можно назвать хоть некорпоративными.
В чём вообще проблема? Не только на C++, хоть на Lisp написать можно что угодно, хоть корпоративное хоть
некорпоративное. А если для любого чиха прогеру обязательно нужен набор функций с длиннющими названиями, корпоративными,
то это технология деградации, а не технология развития.
Здравствуйте, lpd, Вы писали:
lpd>Соседний топик "java vs. c++" навевает вопрос причин отсутствия фреймворков для разработки корпоративных приложений(вроде Spring, Struts) и серверов приложений на C++.
Главное, не на чем писать, а что.
Если вы пишете скучную корпоративную хрень, то лучшее ее вообще не писать, ни на java, ни на C++
Здравствуйте, alex_public, Вы писали:
_>Начинать сравнивать синтаксис можно после проверки приблизительного равенства функциональности. Можно увидеть аналог на C# для данного http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc простейшего кода с полиморфными лямбдами? ) Как только увижу его, можно будет начать разговор об удобстве синтаксиса...
Где, кому и зачем может потребоваться это лютое говно?
Какие реальные задачи оно решает или может решить?
Здравствуйте, lpd, Вы писали:
lpd>Если в терминологии wikipedia{C++11}{C++14}: lpd>lamda-выражения считаю бесполезными — если мне надо вызвать несколько функций, я их вызову без lambda. lpd>Alternative function syntax — зачем? lpd>User-defined literals — бесполезно. lpd>Function return type deduction — ужас lpd>Variable templates — бесполезно
Ты на С++ писал, как на Си, только с классами, да?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, AlexRK, Вы писали:
_>>Начинать сравнивать синтаксис можно после проверки приблизительного равенства функциональности. Можно увидеть аналог на C# для данного http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc простейшего кода с полиморфными лямбдами? ) Как только увижу его, можно будет начать разговор об удобстве синтаксиса... ARK> ARK>Где, кому и зачем может потребоваться это лютое говно? ARK>Какие реальные задачи оно решает или может решить?
Это демонстрация возможностей лямбд в C++. Конкретно этот код на практике не нужен. Хотя бы потому, что в стандартную библиотеку уже и так входят готовые кортежи (реализованные не через лямбды). Однако он очень хорошо демонстрирует сами возможности языка, а уж где их применить с пользой, думаю и так очевидно.
Здравствуйте, lpd, Вы писали:
lpd>Возможно, в некоторых случаях ламбды сокращают код. Но любую программу можно написать без них (вроде Тьюринг еще доказывал).
Любишь писать тетрисы на Брейнфаке? Он тоже тьюринг-полон.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, alex_public, Вы писали:
_>1. У нас есть отдельные строки (по гигабайту каждая, для остроты ощущений) и пустой массив строк. Мы хотим положить одну строку в массив. Но чтобы при этом естественно не происходило копирования гигабайта. Ну и само собой при удаление массива все строки в нём должны удаляться. _> — C: можно наколбасить руками эффективную реализацию _> — Java/C#: работает автоматически, но не эффективно (сборщик мусора со всеми печальными последствиями из этого) _> — C++: работает автоматически и эффективно _> — так какой там язык давно имел эффективное автоматическое решение данной проблемы?
Дельфи?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[18]: так все же gcc или clang компилирует этот код правильно?
Здравствуйте, T4r4sB, Вы писали:
_>>ОК. Можно для начала показать аналог такого http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc элементарного кода? ) TB>Нефиг делать, как только я пойму, что в нём вообще происходит. А с этим хреново. Пожалуй, этот код демонстрирует недостатки лямбд и вариадиков.
Там создают полноценные кортежи и функции работы с ними (map и т.п.) из лямбд.
С удовольствием посмотрю на аналогичную реализацию на Java/C#. Особенно с учётом того, что в .net вообще не осилили нормальные кортежи (ограничение на 8 элементов — это же смешно) даже просто классами, а не лямбдами.
Re[19]: так все же gcc или clang компилирует этот код правильно?
