Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonДима. Еще добавлю. КМК именно буферизация (или отложенная деаллокация) дает преимущества. Это как в БД и файловых системах. Если ты делаешь батчинг с умным предвариельным анализм батча - то можешь здорово сэкономить на всем объеме операций. И поэтому КМК сиюминутное пожелание срочно отработать "деструктор" приводит к ненужной суетливой активности и потере общего КПД. И еще раз. Я ратую за компромисс а не за "священную войну против GC и MM". Ну ты как? ОК? Не ОК? Деструктор и освобождение памяти это разные вещи. Деструктор это логика уровня приложения. Сообщение объекту что он больше не используется сразу как он стал ненужным. Я об этом. Что там реально с памятью происходит - не важно. Пример с БД неудачен, т.к. РСУБД и ООП никак не пересекаются. Но в РСУБД есть аналог деструктора - триггер. В общем деструктор нужная штука и там где его нет изобретают всякие костыли для его эмуляции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2017, 20:45 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Dima TПример с БД неудачен, т.к. РСУБД и ООП никак не пересекаются. Но в РСУБД есть аналог деструктора - триггер. Я другое имел в виду. Если рассматривать MM как структуру данных то и "чистку" неиспользуемых объектов в памяти лучше делать не "штучно" а массово. Это повышает общий КПД алгоритма хотя и вводит некую задержку в освобождение памяти. Но кому нужен жесткий синхронизм? Тебе нужен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2017, 22:17 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Dima TВ общем деструктор нужная штука и там где его нет изобретают всякие костыли для его эмуляции. По поводу костылей для языков с GC. Костыль номер раз. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. И костыль номер два - это try-with-resources о котором я говорил. Его легко нагуглить. Там будет и перегруженный метод ::close(). Это и есть как-бе деструктор. Насколько это костыльно по 10 балльной шкале? Я не знаю. Я думаю что не очень. Т.к. сам юзкейс очень специфичен. Ситуации когда тебе кровь-из-носа нужно освободить ресурсы достаточно редки. Их можно посчитать по пальцам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2017, 22:22 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonСитуации когда тебе кровь-из-носа нужно освободить ресурсы достаточно редки разве это не типовая ситуация? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2017, 23:07 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
mayton, завтра обязательно будет "лучше", чем было вчера. try-with-resources появился спустя 15 лет после старта дохлой java-идеи, когда в нее вдыхалась уже третья жизнь, потенциал которой будут выбирать еще лет пять-семь вперед, благодаря впрыснутой в машину invokedynamic ( говорят, к java-11, наконец, пересмотрят генерики, и сделают их почти такими же "плохими", как в c++ (генерирующими на этапе компиляции версию класса для использующего типа, (а сначала-то появились в генерации 2.5 "хорошие" - с затиранием фактического типа)). Само по себе это имеет мало отношения к вопросу о том, что лучше - языковую или системную поддержку для работы с динамической памятью. Это вопрос математики. Даг Ли явил в malloc имени себя любимого нечто, что спустя 15-20 лет было переосмыслено как потенциальная возможность математической гарантии управления памятью. К тому моменту, когда математика окончательно сойдется, ява перестанет быть java-ой, так как потребность иметь поддержку управления памятью, отличную от предоставляемой операционной системой просто отпадет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2017, 23:48 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
ИзопропилmaytonСитуации когда тебе кровь-из-носа нужно освободить ресурсы достаточно редки разве это не типовая ситуация? Это не типовая ситуацию для языков с GC. Другими словами - вы хотите чтобы объект, который покинул scope - немедленно (физически) был удален из eden/surv/oldgen. И вы его факт удаления тут-же зафиксировали в memree(..). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2017, 08:59 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonЭто не типовая ситуацию для языков с GC. Другими словами - вы хотите чтобы объект, который покинул scope - немедленно (физически) был удален из eden/surv/oldgen. И вы его факт удаления тут-же зафиксировали в memree(..).Это неправильная посылка. Финализатор позволяет сделать "изощрённое освобождение памяти", но заменой деструктора он всё равно не станет. Деструктор требуется тогда, когда необходимо явно управлять временем жизни любых ресурсов, кроме памяти JVM. Тривиальный пример - сокеты IP-стека. Там, где "плюсовики" один раз напишут деструктор и дальше будут управлять временем жизни объекта "расставляя фигурные скобочки", "кофеманам" придётся явно прописывать try/finally. С моей кочки зрения это не минус и не плюс: try/catch всё равно необходимы, а необходимость прописывать finally устраняет синтаксический сахар try-with-resource. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2017, 09:21 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonЯ другое имел в виду. Если рассматривать MM как структуру данных то и "чистку" неиспользуемых объектов в памяти лучше делать не "штучно" а массово. Точно так же можно массово освобождать память в С++. Пропиши свой delete, где запоминай указатели на освобождаемую память, а затем массово их удали в нужный тебе момент. Уже писал: деструктор - это логика уровня приложения. Способ управления памятью тут ни при чем. maytonИ костыль номер два - это try-with-resources о котором я говорил. Его легко нагуглить. Там будет и перегруженный метод ::close(). Это и есть как-бе деструктор. Почитал про try-with-resources, это тоже самое что using() в C#. maytonНасколько это костыльно по 10 балльной шкале? Я не знаю. Я думаю что не очень. Не особо костыльно. Чуть больше кода. maytonТ.к. сам юзкейс очень специфичен. Ситуации когда тебе кровь-из-носа нужно освободить ресурсы достаточно редки. Их можно посчитать по пальцам. От задач зависит. Мне часто надо. А может я просто привык что есть дестуктор, поэтому с ним мне удобнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2017, 10:39 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Dima TТочно так же можно массово освобождать память в С++. Пропиши свой delete, где запоминай указатели на освобождаемую память, а затем массово их удали в нужный тебе момент. Уже писал: деструктор - это логика уровня приложения. Способ управления памятью тут ни при чем. Убедил. Согласен что деструктор - это логика управления приложением. А свой delete прописывать не хочу. Ну... по крайней мере это не будет кастомизацией приложения. Как платформа или язык - да. Как приложение - нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2017, 11:00 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonМне кажется в спорах о m.management можно выделить две крайности. Два антогонизма. 1. Мемори leaks вызванные ошибкай разработчика при обработке исключения или просто ошибкой. 2. Накладные расходы на управляемую кучу в виде стоп-вселенная и потребления мегафлопов. Оба тезиса имеют место. Но многие ораторы не ищут компромисса между 1 и 2 а просто доказывают Правильность линии свой партии. Не вижу смысла рассматривать какую либо [не]оптимальность ГЦ при потреблении Явой памяти в обычном случае в >3.5 раза больше. ИзопропилAnatoly MoskovskyА время жизни захваченных переменных продлевается естественно. но эта "локальная" переменная - уже не может жить на стеке. ничего я не путаю. лексическая область видимости - локальная, время жизни - может превышать время жизни активации. хорошая такая "локальная переменная." Лямбда в c# превращается в целый независимый класс и живет в хипе. ShSergeЧё-то здесь про QNX говорили. Он дорого стоит - поэтому "распил" называется. А про количество строк - ху кновс. В Ассемблере всё с новой строки. VxWorks стоила (сравнивал давно) столько же. Конкурируй. Хотя есть и подешевле варианты RT-систем, RTOS-32 например. Но Майтон верно написал - не всем нужен RT, добавлю еще, что там где он действительно нужен, часто не нужен С. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2017, 19:35 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
SiemarglЛямбда в c# превращается в целый независимый класс и живет в хипе. Хм... я-бы перепроверил этот факт. Есть мысль что все-таки не в класс а в статический метод. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2017, 23:02 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
mayton, trust me, i'm an engineer =) на хабре пробегала статья с кодом из il-dasm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2017, 23:09 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
(разводя руками) Зачем нам Хабр? Давайте щас соберем код. И дизассемблернём. P.S. В статьи на Хабре я охотно верю. Но эволюция версий ПО мать ее так... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2017, 23:14 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
maytonХм... я-бы перепроверил этот факт. Есть мысль что все-таки не в класс а в статический метод. Лямбда не может быть в общем случае просто функцией. У ее экземпляров обычно есть состояние. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2017, 00:55 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskymaytonХм... я-бы перепроверил этот факт. Есть мысль что все-таки не в класс а в статический метод. Лямбда не может быть в общем случае просто функцией. У ее экземпляров обычно есть состояние.предлагаю не травмировать обитателя упрощенного форума ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2017, 01:22 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
оффтопик авторне всем нужен RT, добавлю еще, что там где он действительно нужен, часто не нужен С. Скажите, пожалуйста, а на чём же пишут системы реального времени, если не на С? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2017, 03:47 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskymaytonХм... я-бы перепроверил этот факт. Есть мысль что все-таки не в класс а в статический метод. Лямбда не может быть в общем случае просто функцией. У ее экземпляров обычно есть состояние. Приведите пример ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2017, 08:15 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
azsxоффтопик авторне всем нужен RT, добавлю еще, что там где он действительно нужен, часто не нужен С. Скажите, пожалуйста, а на чём же пишут системы реального времени, если не на С? Например: Ада, Модула . Стоит ещё учитывать для чего используется система - степень требуемой надёжности. "С" это ширпотреб, его никто в здравом уме не рассматривает как основу систем реального времени с гарантиями качества. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2017, 08:25 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
kealon(Ruslan)azsxоффтопик пропущено... Скажите, пожалуйста, а на чём же пишут системы реального времени, если не на С? Например: Ада, Модула . Стоит ещё учитывать для чего используется система - степень требуемой надёжности. "С" это ширпотреб, его никто в здравом уме не рассматривает как основу систем реального времени с гарантиями качества. Не затруднит развить вашу глубокую мысль ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2017, 09:16 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
schiНе затруднит развить вашу глубокую мысль ? а что в ней непонятного? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2017, 09:27 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
azsxоффтопик авторне всем нужен RT, добавлю еще, что там где он действительно нужен, часто не нужен С. Скажите, пожалуйста, а на чём же пишут системы реального времени, если не на С? Алгоритмы заказчика на https://en.wikipedia.org/wiki/IEC_61131 К языкам относится часть 3 Но вот сама ОС контроллеров, скорее всего на С. По крайней мере, внешние интерфейсы для расширения низкоуровневой функциональности я видел только Сишные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2017, 09:33 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Siemargl, я не силён в нерусском и мой вопрос скорее для повышения общего уровня образованности. Я нашёл по вашей ссылке такую цитату: авторIEC 61131-3 currently defines five programming languages for programmable control systems: function block diagram (FBD), ladder diagram (LD), structured text (ST; similar to the Pascal programming language), instruction list (IL; similar to assembly language), and sequential function chart (SFC).[12] These techniques emphasize logical organization of operations.[11] Из неё я делаю вывод, что при программировании программируемого логического контролёра (plc) в том числе используют язык, похожий на паскаль. В то же время мне всегда казалось, что операционные системы реального времени (real time os) -- это windows nt, qnx и прочие.То есть это полноценные ос, просто умеют прерывания делать жёсткие в определённые моменты времени. То есть Ваша ссылка не подходит, она не для этого. Я совсем не прав? В чём мои ошибки? зы Меня просто также удивило, что критичные к времени приложения пишут не на С, я ответа не знаю, хочу спросить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2017, 09:48 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
Мне показалось что камент Руслана скорее философский. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2017, 09:50 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
azsx, Есть две большие области применения RT - embedded и PLC В первой применяются ОС более-менее общего назначения, как ты написал. На самом деле там может быть и не RT-ос, а простенькая прошивка (например как в ардуино) или даже клон DOS или простого (не РТ) Линуха. Но обычно поддержка RT есть. Во второй - только hard-RT, свои закрытые ОС, и тот стандарт, что я указал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2017, 10:42 |
|
||
|
На чём лучше писать код при одинаковом количестве строк: на C или на C++?
|
|||
|---|---|---|---|
|
#18+
azsxМеня просто также удивило, что критичные к времени приложения пишут не на С, я ответа не знаю, хочу спросить. критичные к времени и надёжности приложения пишут не на С всякие контроллёры на ардуино это ширпотреб, от которых ничего критичного не зависит более того там все гарантии нулевые представили, например, как боинг запустить с такими гарантиями? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2017, 10:47 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=39497053&tid=1340092]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
168ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 267ms |
| total: | 541ms |

| 0 / 0 |
