Здравствуйте, noone, Вы писали:
N>Это тот же самый пример (чуть проще). Интересно, что ты его узнал только когда речь пошла о UI.
Решить задачу можно разными способами. Ты не сказал какую задачу нужно решить, а привел способ. Получается, что программист на Фортране напишет программу на Фортране на любом языке.
MTD>>
N>Здесь мы наблюдаем, как байндится raw-указатель this, то есть явно используется факт того, что кнопка живет не дольше this. Чуть усложним Java-пример:
Ты сильно не прав о том, что там происходит.
N>Теперь в initButton может передаваться как this, так и совершенно посторонний listener. Время жизни зарегистрированного listener должно быть не меньше времени жизни кнопки.
Здравствуйте, MTD, Вы писали:
MTD>Получается, что программист на Фортране напишет программу на Фортране на любом языке.
Ну да. Программист со счетчиком ссылок будет любой граф объектов сводить руками к ациклическому.
N>>Здесь мы наблюдаем, как байндится raw-указатель this, то есть явно используется факт того, что кнопка живет не дольше this. Чуть усложним Java-пример:
MTD>Ты сильно не прав о том, что там происходит.
Сказать, что я не прав мало, нужно еще сказать почему.
MTD>Да без разницы вообще.
MTD>
Здравствуйте, noone, Вы писали:
MTD>>Ты сильно не прав о том, что там происходит.
N>Сказать, что я не прав мало, нужно еще сказать почему.
Я забыл кое-что дописать в примере, оттого видимо вышло недопонимание. Исправляюсь.
Boost.Signals can automatically track the lifetime of objects involved in signal/slot connections,
including automatic disconnection of slots when objects involved in the slot call are destroyed.
здесь
N>Если panel сдохнет до вызова handler, здесь будет висячий указатель.
Signal/slot disconnections occur when any of these conditions occur:
The connection is explicitly disconnected via the connection's disconnect method directly,
or indirectly via the signal's disconnect method or scoped_connection's destructor.
A trackable object bound to the slot is destroyed.
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, noone, Вы писали:
N>>Как оно может быть сложнее С++, если там shared_ptr и weak_ptr встроены в язык?
К>C++ К>Опасные вещи, такие как операторы new/delete нужны крайне редко.
Что опасного в создании объекта?
К>Если в полях объекта только smart pointers и generic collections, то при удалении объекта все его поля удалятся автомагически.
То же самое в Objective-C (см. ARC). Только не удаляются, а уменьшаются счетчики, что может привести и к удалению.
К>Если конструировать top-level objects только на стеках – вам вообще не нужно заниматься управлением памятью, за вас всё сделают язык, компилятор и библиотеки.
То же самое в Objective-C (см. ARC), только не сами объекты, а ссылки на них.
К>Obj-C К>Даже при использовании рекомендуемой практики @property(retain), если вы забыли освободить какое-то поле в методе -(void)dealloc, вот она утечка.
В dealloc ссылки на Objective-C объекты release-ить не нужно, там уже все написал компилятор (см. ARC). И какой retain, когда уже 2 года как должен быть strong (см. ARC)?
К>Случайно сослались на self в блоке — получили циклическую ссылку.
При захвате С++ лямбдой shared_ptr будет та же проблема. Это как раз беда подсчета ссылок.
MTD>Boost.Signals can automatically track the lifetime of objects involved in signal/slot connections,
MTD>including automatic disconnection of slots when objects involved in the slot call are destroyed.
Симпатичный костылик, примерно из той же оперы, что и weak-ссылки в Objective-C.
В нем 2 проблемы:
1) Объект должен наследоваться от бустового класса. То есть библиотечные объекты придется явно заворачивать. Работает только для bind, так что лямбдам можно помахать ручкой.
2) Решает другую задачу. Слот отваливается, когда trackable объект умирает. А я хотел наоборот — захваченные объекты становятся не нужны, когда кнопка становится не нужна.
Здравствуйте, noone, Вы писали:
К>>C++ К>>Опасные вещи, такие как операторы new/delete нужны крайне редко. N>Что опасного в создании объекта?
Тем что потом кто-то другой, часто непонятно кто именно, должен его удалять.
Когда на C++ программирую, вообще не использую операторы new/delete, только изредка и в отдельных изолированных местах placement new, в тех случаях где зачем-то нужно ручное управление памятью (например аллоцировать ноду, которой владеет граф). Так делать совсем несложно, и я уже много лет не искал утечек памяти в своём коде.
N>В dealloc ссылки на Objective-C объекты release-ить не нужно, там уже все написал компилятор (см. ARC).
Это в Штатах телефоны спонсируются операторами, потому полностью обновляются за 2 года максимум, и щас можно разрабатывать для iOS 5.
В России наоборот довольно много пользователей старых устройств.
Например клиенты компании, где я разрабатывал для iOS, обычно хотели поддержку iPhone 3G, соответственно iOS 4.2.1.
Алсо, слышал что есть ньюансы со старыми third party libraries.
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, noone, Вы писали:
К>>>C++ К>>>Опасные вещи, такие как операторы new/delete нужны крайне редко. N>>Что опасного в создании объекта? К>Тем что потом кто-то другой, часто непонятно кто именно, должен его удалять.
Ну так это в С++ опасная операция. В других языках — нет.
К>Это в Штатах телефоны спонсируются операторами, потому полностью обновляются за 2 года максимум, и щас можно разрабатывать для iOS 5. К>В России наоборот довольно много пользователей старых устройств. К>Например клиенты компании, где я разрабатывал для iOS, обычно хотели поддержку iPhone 3G, соответственно iOS 4.2.1. К>Алсо, слышал что есть ньюансы со старыми third party libraries.
ARC прекрасно работает на iOS 4 за исключением автообнуления weak-ссылок, для которого нет соответствующей поддержки в рантайме (вместо nil там будет висячий указатель, как до ARC). С third-party кодом нет никаких проблем: ARC включается/выключается на уровне отдельных файлов.
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, noone, Вы писали:
К>>>Если в полях объекта только smart pointers и generic collections, то при удалении объекта все его поля удалятся автомагически. N>>То же самое в Objective-C (см. ARC). Только не удаляются, а уменьшаются счетчики, что может привести и к удалению. К>Это не так. К>http://stackoverflow.com/questions/2189919/how-is-release-handled-for-synthesized-retain-properties
Здравствуйте, noone, Вы писали:
К>>>>C++ К>>>>Опасные вещи, такие как операторы new/delete нужны крайне редко. N>>>Что опасного в создании объекта? К>>Тем что потом кто-то другой, часто непонятно кто именно, должен его удалять. N>Ну так это в С++ опасная операция. В других языках — нет.
Я в курсе, разумеется.
Да, есть такая особенность языка.
Лично мне она совсем не мешает, и даже иногда помогает.
Помогает когда приходится выделять память кусками побольше, и потом нарезать placement new (как в случае с нодами, которыми владеет граф) — из-за CPU кешей ощутимо растёт производительность, по сравнению с кучей обычных операторов new.
Кстати именно из-за этого ATL коллекции вроде CAtlMap и CAtlList почти вдвое эффективнее своих STL-аналогов.
К>>Это в Штатах телефоны спонсируются операторами, потому полностью обновляются за 2 года максимум, и щас можно разрабатывать для iOS 5. К>>В России наоборот довольно много пользователей старых устройств. К>>Например клиенты компании, где я разрабатывал для iOS, обычно хотели поддержку iPhone 3G, соответственно iOS 4.2.1. К>>Алсо, слышал что есть ньюансы со старыми third party libraries. N>ARC прекрасно работает на iOS 4 за исключением автообнуления weak-ссылок, для которого нет соответствующей поддержки в рантайме (вместо nil там будет висячий указатель, как до ARC).
Честно говоря, я надеюсь мне больше не придётся разрабатывать на Obj-C.
Моё личное впечатление — шо xCode, шо MacOS X, шо Obj-C все какие-то half-assed. Хорошо хоть сам iOS более-менее OK работает.
Но если вдруг понадодится — спасибо, буду иметь в виду..
Это до недавнего времени — не IDE, а жалкий редактор с подкраской кода. Сейчас там есть неплохой дебаггер. А использовать надо AppCode.
К>шо MacOS X
Меня устраивает: есть все что мне нужно от Линукса без линуксовой вырвиглазности. Хотя последние релизы (со всякими App Store и пр.) не радуют, да.
К>Obj-C
Отличный маленький язык с мощным (для своего размера и области применения) набором ортогональных фич. Полная противоположность С++ в моем сознании. Прекрасно подходит для склейки больших компонент и UI.
К>Но если вдруг понадодится — спасибо, буду иметь в виду..
Здравствуйте, noone, Вы писали:
К>>шо MacOS X N>Меня устраивает: есть все что мне нужно от Линукса без линуксовой вырвиглазности. Хотя последние релизы (со всякими App Store и пр.) не радуют, да.
Разумеется это намного лучше чем linux.
Однако по сравнению с windows 7 или 8, оно прям совсем ни в какие ворота.
К>>Obj-C N>Отличный маленький язык с мощным (для своего размера и области применения) набором ортогональных фич. Полная противоположность С++ в моем сознании. Прекрасно подходит для склейки больших компонент и UI.
C# подходит ещё лучше, однако умеет вещи, которые никому из конкурентов даже не снились. Например linq и async-await.
Щас намечается новый проект кроссплатформенный — думаю mono.touch попробую в этот раз.
Судя по интернетам, пользователи в целом довольны.
Здравствуйте, include2h, Вы писали:
I>Здравствуйте, Big Ben, Вы писали:
BB>>Шарп, пожалуй, самый приятный язык программирования с адаптацией под любые кривые руки, и под прямые тоже.
I>10 лет кодил кодесы на С++. Тут недавно взял проект на c#. Язык конечно хороший, синтаксис более красивый и продуманный, но... I>В си есть такая функция atoi. Простая как дупель пусто-пусто. Любую строку, если в строке записано число, превращает в число, иначе возвращает ноль. Меня это вполне устраивало... но нет, в C# аналог (Convert.TiInt32) зачем-то выбрасывает исключение. Пришлось писать функцию-обертку в специальном статическом классе.
I>Далее, эти поросята "постарались" с интернационализацией. Во всем мире в качестве разделителя используется точка, а у нас почему-то запятая. Вместо того, чтобы силой навязать нам точку, заставить привести национальные стандарты в соответствие мировым (кстати, а есть ли они, такие стандарты — может это просто глупость какая-то), ребята из M$ взяли и сделали, что в России при преобразовании float -> string ставятся запятые. Всякие DataGridView при вводе понимают только запятые и бросают исключения, если ввести точку. I>Но MySQL-то понимает только точки! I>А заказчик вообще захотел вводить и запятые, и точки, и чтобы все работало. I>Вот и еще одну обертку пришлось писать.
Не, шарп он много чего позволяет делать, только надо разобраться как. Про int.TryParse уже писали. И во всех конвертациях в строку и из строки существует возможность явно указывать culture в параметре IFormatProvider, по умолчанию он использует текущие настройки системы. В твоем случае достаточно было указать этот параметр как CultureInfo.InvariantCulture — были бы точки вместо запятых.
Можно также установить культуру для всего потока чтобы каждый раз не заморачиваться:
CultureInfo ci = CultureInfo.CreateSpecificCulture("en-US");
Thread.CurrentThread.CurrentCulture = ci;
Thread.CurrentThread.CurrentUICulture = ci;
Достает правда, если часто создаешь новые потоки, приходится все время об этом помнить.
или, в .NET 4.5 для AppDomain наконец то ввели новую функцию:
CultureInfo ci = CultureInfo.CreateSpecificCulture("en-US");
CultureInfo.DefaultThreadCurrentCulture = culture;
CultureInfo.DefaultThreadCurrentUICulture = culture;
KA>>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ!
MTD>Есть мнение, что ты не плюсах писал, а на С с классами, после него от сборки мусора эйфория. А вот после плюсов смотришь на сборщика мусора как на бесполезного сельского дурочка.
Это так, на С с классами, но я не совсем про сборщик мусора. Я писал обертки (плагины под MMC) на С++. Это легкий кошмарец. В .NETе я написал готовую вещь за 2 дня.
Одно удовольствие поглядеть как это теперь делается.
... в С++ как то сильно много надо печатать по любому поводу.
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ!
Ты после С++ на plain C сходи. Потом между С# и C++ переключаться будешь вообще незаметно.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Привет всем, KA>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу KA>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ! KA>
Автомат — это ещё потеря части мощности двигателя, повышенный расход бензина, повышенной износ тормозных дисков и большая ломучесть.
Здравствуйте, khimiki, Вы писали:
K>Здравствуйте, Kubyshev Andrey, Вы писали:
KA>>Привет всем, KA>>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу KA>>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ! KA>>
K>Автомат — это ещё потеря части мощности двигателя, повышенный расход бензина, повышенной износ тормозных дисков и большая ломучесть.
О, замшелые мифы из соседнего форума! Даёшь флейм!
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, MTD, Вы писали:
MTD>>>>Зачем в шаблонном методе shared_ptr? F>>>предлагаешь вручную управлять памятью? MTD>>Нет. shared_ptr реально нужен в 1 случае из 200.
F>как тогда предлагаешь управлять памятью?
scoped_ptr(array) жи есть. Разные контейнеры.
F>т.е. shared_ptr — признак плохого дизайна? кхм
Ну типа да.
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу KA>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ!
C++ недоязык. просто недоразумение какое-то, коему я отдал слишком много лет жизни. если косяки исправить — получится шарп. назад — только в кошмарном сне.
