Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу KA>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ!
Есть мнение, что ты не плюсах писал, а на С с классами, после него от сборки мусора эйфория. А вот после плюсов смотришь на сборщика мусора как на бесполезного сельского дурочка.
Здравствуйте, Big Ben, Вы писали:
BB>Шарп, пожалуй, самый приятный язык программирования с адаптацией под любые кривые руки, и под прямые тоже.
10 лет кодил кодесы на С++. Тут недавно взял проект на c#. Язык конечно хороший, синтаксис более красивый и продуманный, но...
В си есть такая функция atoi. Простая как дупель пусто-пусто. Любую строку, если в строке записано число, превращает в число, иначе возвращает ноль. Меня это вполне устраивало... но нет, в C# аналог (Convert.TiInt32) зачем-то выбрасывает исключение. Пришлось писать функцию-обертку в специальном статическом классе.
Далее, эти поросята "постарались" с интернационализацией. Во всем мире в качестве разделителя используется точка, а у нас почему-то запятая. Вместо того, чтобы силой навязать нам точку, заставить привести национальные стандарты в соответствие мировым (кстати, а есть ли они, такие стандарты — может это просто глупость какая-то), ребята из M$ взяли и сделали, что в России при преобразовании float -> string ставятся запятые. Всякие DataGridView при вводе понимают только запятые и бросают исключения, если ввести точку.
Но MySQL-то понимает только точки!
А заказчик вообще захотел вводить и запятые, и точки, и чтобы все работало.
Вот и еще одну обертку пришлось писать.
Здравствуйте, MTD, Вы писали:
MTD>Умные указатели — современный С++, а не велосипеды. То, что ты не знаешь язык, не говорит о его проблемах.
Умные указатели — это костыль ("паттерн") из прошлого века для языков без автоматического управления памятью или встроенного подсчета ссылок. То, что современный С++ в отношение управления памятью находится в прошлом веке — точно не мои проблемы. Это же не я объявил отсутствие GC некой доблестью.
Здравствуйте, include2h, Вы писали:
I>Вот и еще одну обертку пришлось писать.
Может, вместо обертки стоит книжечки там почитать, документацию? Форумы к конце то концов!
Здравствуйте, noone, Вы писали:
MTD>>Умные указатели — современный С++, а не велосипеды. То, что ты не знаешь язык, не говорит о его проблемах.
N>Умные указатели — это костыль ("паттерн") из прошлого века для языков без автоматического управления памятью или встроенного подсчета ссылок. То, что современный С++ в отношение управления памятью находится в прошлом веке — точно не мои проблемы. Это же не я объявил отсутствие GC некой доблестью.
Ты все перепутал — GC паттерн из прошлого века, тормозной и ненужный.
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу KA>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ!
C++ недоязык. просто недоразумение какое-то, коему я отдал слишком много лет жизни. если косяки исправить — получится шарп. назад — только в кошмарном сне.
Здравствуйте, noone, Вы писали:
MTD>>Давай на конкретном примере, я тебе напишу код без проблемы цикличных ссылок или признаю, что ошибался?
N>Конкретный пример: в метод объекта передается функция, которая сохраняется для последующего использования. Как узнать, что эта примитивная операция не создает цикла?
Это не пример, а демагогия. Я не говорил, что в С++ нельзя прострелить себе ногу, как раз это философия языка — меня можно использовать безопасно, но если ты такой умный, то действуй на свой страх и риск. Я говорил о том, что проблема циклических сылок — проблема дизайна. Или ты думаешь, что в языках со сборщиком мусора нет утечек памяти? Показать пример, как прострелить себе ногу?
Здравствуйте, noone, Вы писали:
MTD>>shared_ptr/weak_ptr, но замечу, что циклические ссылки — проблема кривого дизайна
N>Обсуждается в другой подветке. Но ответ симптоматичный: чудес управления памятью без GC, похоже, не будет — будут велосипеды.
Умные указатели — современный С++, а не велосипеды. То, что ты не знаешь язык, не говорит о его проблемах.
Привет всем,
Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу
СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ!
Здравствуйте, rusted, Вы писали:
R>Здравствуйте, netch80, Вы писали:
N>>Нет, давай вначале разберёмся с общим подходом. Ты настаиваешь на написании кода без циклических ссылок вообще? Или "без проблемы циклических ссылок"?
R>Без циклических владеющих ссылок.
С владеющими ссылками нужно постоянно мысленно инспектировать граф объектов (что в нетривиальной программе быстро превращается в безумие) и профилировать, чтобы не вляпаться в утечку. С невладеющими — в висячий указатель. Чем шило лучше мыла? Еще, конечно, можно натянуть сову на глобус: подогнать программу под ограничения ручного управления. Как сказал бы Xbox 360 Kid: "The great thing about the reference counting isn’t delivering of functionality, it’s showing everyone online that I did".
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Попробуй соорудить реализацию объекта с Dispose в которой бы: КД>- было запрещено использовать объект после вызова Dispose. КД>- Dispose не "разрушал" объект, пока работают другие его методы.
Дотнетовский Dispose заточен под самый популярный сценарий — один владелец, объект гарантированно не будет использоваться в дальнейшем. Если явного владельца нет, но ресурс по-прежнему требуется освобождать, то надо считать ссылки или использовать API с continuation-passing. Я бы смотрел в сторону RX/тасков.
Здравствуйте, khimiki, Вы писали:
K>Здравствуйте, Kubyshev Andrey, Вы писали:
KA>>Привет всем, KA>>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу KA>>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ! KA>>
K>Автомат — это ещё потеря части мощности двигателя, повышенный расход бензина, повышенной износ тормозных дисков и большая ломучесть.
О, замшелые мифы из соседнего форума! Даёшь флейм!
Здравствуйте, include2h, Вы писали:
I>В си есть такая функция atoi. Простая как дупель пусто-пусто. Любую строку, если в строке записано число, превращает в число, иначе возвращает ноль. Меня это вполне устраивало... но нет, в C# аналог (Convert.TiInt32) зачем-то выбрасывает исключение. Пришлось писать функцию-обертку в специальном статическом классе. int.TryParse?
I>Далее, эти поросята "постарались" с интернационализацией. Во всем мире в качестве разделителя используется точка, а у нас почему-то запятая. Вместо того, чтобы силой навязать нам точку, заставить привести национальные стандарты в соответствие мировым (кстати, а есть ли они, такие стандарты — может это просто глупость какая-то), ребята из M$ взяли и сделали, что в России при преобразовании float -> string ставятся запятые. Всякие DataGridView при вводе понимают только запятые и бросают исключения, если ввести точку.
По умолчанию используется текущая культура.
Здравствуйте, noone, Вы писали:
MTD>>Это не пример, а демагогия.
N>Не понял, где здесь демагогия.
Без конкретной постановки задачи — демагогия в чистом виде.
N>Сохранение callback (он же listener, он же delegate) — задача тривиальная и часто встречающаяся в прикладных программах.
Конечно. А вот вопросы владения вопросы вызывают.
N>Причем здесь C++? Ветка про подсчет ссылок.
Ты видимо что-то перепутал. Подсчет ссылок не единственная альтернатива GC.
MTD>>Я говорил о том, что проблема циклических сылок — проблема дизайна.
N>Нет, это проблема подсчета ссылок — простейшие вещи ведут к утечке памяти.
Не ведут.
N>Почему я должен уродовать архитектуру только для того, чтобы натянуть ее на технологию с неподходящей семантикой?
Наоборот, я призываю к простой и понятной архитектуре, тогда и не будет всяких последствий типа циклических ссылок.
N>Почему просто не взять язык с GC?
Здравствуйте, MTD, Вы писали:
MTD>Есть мнение, что ты не плюсах писал, а на С с классами, после него от сборки мусора эйфория. А вот после плюсов смотришь на сборщика мусора как на бесполезного сельского дурочка.
Как решена проблема циклических ссылок?
Как происходит дефрагментация памяти?
Здравствуйте, MTD, Вы писали:
N>>Как решена проблема циклических ссылок? MTD>shared_ptr/weak_ptr, но замечу, что циклические ссылки — проблема кривого дизайна
Как удобно — списал все неприятные случаи на "кривой дизайн" и доволен, что C++ разрешает справиться с остальными случаями.
Я неоднократно встречался с ситуациями, когда естественным представлением предметной области является "сеть" объектов в памяти со многими связями. Например, такое типично в картографии, или в анализе структур человеческих связей. В результате в таких структурах 1) приходилось реализовывать наколенный GC в виде счётчиков ссылок (этих самых shared_ptr или аналогов), 2) реализовывать учёт групповой принадлежности объекта и массовое освобождение по этой принадлежности. А теперь, если вспомнить, что даже там, где подсчёт ссылок работает, он становится неэффективен в широкопараллельной среде, становится понятно, что GC ложился бы на такие задачи значительно естественнее.
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, noone, Вы писали:
N>>Как решена проблема циклических ссылок?
MTD>shared_ptr/weak_ptr, но замечу, что циклические ссылки — проблема кривого дизайна
Обсуждается в другой подветке. Но ответ симптоматичный: чудес управления памятью без GC, похоже, не будет — будут велосипеды.
N>>Как происходит дефрагментация памяти?
MTD>Как обычно, что интересует?
Интересует как происходит дефрагментация свободной памяти программы. Впрочем, этот вопрос я сниму с повестки — к GC он имеет меньше отношения, чем к арифметике указателей.
Здравствуйте, noone, Вы писали:
MTD>>Умные указатели — современный С++, а не велосипеды. То, что ты не знаешь язык, не говорит о его проблемах.
N>Умные указатели — это костыль ("паттерн") из прошлого века для языков без автоматического управления памятью или встроенного подсчета ссылок. То, что современный С++ в отношение управления памятью находится в прошлом веке — точно не мои проблемы. Это же не я объявил отсутствие GC некой доблестью.
Кстати, вопрос: Dispose — это костыль (пардон, "паттерн") или нет?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, MTD, Вы писали:
MTD>Это не пример, а демагогия.
Не понял, где здесь демагогия. Сохранение callback (он же listener, он же delegate) — задача тривиальная и часто встречающаяся в прикладных программах.
MTD>Я не говорил, что в С++ нельзя прострелить себе ногу, как раз это философия языка — меня можно использовать безопасно, но если ты такой умный, то действуй на свой страх и риск.
Причем здесь C++? Ветка про подсчет ссылок.
MTD>Я говорил о том, что проблема циклических сылок — проблема дизайна.
Нет, это проблема подсчета ссылок — простейшие вещи ведут к утечке памяти. Почему я должен уродовать архитектуру только для того, чтобы натянуть ее на технологию с неподходящей семантикой? Это ведь не бесплатно. А потом тратить время на подчистку утечек за менее опытными коллегами. Почему просто не взять язык с GC? Потому что MTD уверен — без этого легко обойтись. Вот я и жду ответа.
MTD>Или ты думаешь, что в языках со сборщиком мусора нет утечек памяти? Показать пример, как прострелить себе ногу?
В начале ветки я задал вопрос: как конкретные проблемы, решенные GC, могут быть решены без него. То, что GC это не райское наслаждение, мне доказывать не нужно.
Здравствуйте, neFormal, Вы писали:
MTD>>Нет. shared_ptr реально нужен в 1 случае из 200.
F>как тогда предлагаешь управлять памятью?
Открой для себя контейнеры.
MTD>>Везде где надо что-то привести вручную. F>т.е. shared_ptr — признак плохого дизайна? кхм
Странный вывод. Можешь привести ход рассуждений?
MTD>>Меня интересует твоя реализация. F>моя вполне классическая.
Ну так приведи, а не отмазывайся.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Сам по себе метод не костыль — внешние ресурсы действительно нужно освобождать и (в отличие от случая с памятью) только программист знает как и когда. C# я не знаю, но, кажется, там этот интерфейс дополнительно поддерживается языком. Сейчас прочитал там про какие-то пляски с finalizer — вот это уже похоже на непроработанность. Больше с моими знаниями сказать сложно.
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, noone, Вы писали:
MTD>Без конкретной постановки задачи — демагогия в чистом виде.
MTD>Конечно. А вот вопросы владения вопросы вызывают.
Не понимаю, что здесь так тяжело постигнуть.
Some s;
Publisher p;
s.publisher = p; // эту строчку ты не видишь, она - в недрах библиотеки/соседнем методе
p.subscriber = lambda (Event event) { s.doSomething(event.data) }
Если у нас подсчет ссылок, то мы уже приехали. Это простейший пример. На практике есть случаи повеселей, но их в двух словах не опишешь.
N>>Причем здесь C++? Ветка про подсчет ссылок.
MTD>Ты видимо что-то перепутал. Подсчет ссылок не единственная альтернатива GC.
Ознакомь меня с техникой, которая не была бы вырожденным случаем подсчета ссылок и не вела бы к копированию объектов. Это интересно.
N>>Нет, это проблема подсчета ссылок — простейшие вещи ведут к утечке памяти.
MTD>Не ведут.
См. пример.
N>>Почему я должен уродовать архитектуру только для того, чтобы натянуть ее на технологию с неподходящей семантикой?
MTD>Наоборот, я призываю к простой и понятной архитектуре, тогда и не будет всяких последствий типа циклических ссылок.
Архитектура должна расти из свойств домена, а не из кривости конкретных техник. Некий компромисс всегда неизбежен, но это не тот случай — есть механизм, прекрасно подходящий для данной задачи.
N>>Почему просто не взять язык с GC?
MTD>Потому, что это не серебрянная пуля.
Здравствуйте, neFormal, Вы писали:
Ops>>Открой для себя контейнеры. F>при чём тут контейнеры? мне их на каждый чих создавать?
Вроде же ты про управление памятью начал?
F>в гугле забанили?
Ну ок, отмазывайся.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, noone, Вы писали:
N>>Этот бред имеет отдельную поддержку от языка в C# — http://msdn.microsoft.com/en-us/library/ms173171(v=vs.80).aspx . Наверное, от скуки они его туда 10 лет назад приделали, тебя потроллить.
MTD>Нет, тролишь здесь похоже ты. Или ты приведешь адекватный пример?
Это натурально простейший практический кусочек, проще него только репа. Примеров на C# можно обчитаться в вышеприведенной ссылке. Вот микропример на Java
public class MyPanel extends JPanel {
JButton myButton;
private void initButton() {
myButton = new JButton("Do something");
myButton.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
doSomething();
}
});
add(myButton);
}
private void doSomething() {
}
}
При подсчете ссылок придется явно городить слабую ссылку на this (костыль). В чуть более сложном случае — курить бамбук (много костылей) с риском получить висячие ссылки/утечки.
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу
По годным дорогам без снега и пробок — разница минимальна между ними.
KA>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется.
Странно, переходил пару раз в обе стороны, особых неудобств не замечал.
Как вам верно заметили выше, при наличии некоторого опыта за плечами и умением пользоваться STL или лучше ATL, управление памятью в С++ практически перестаёт создавать проблем.
Алгоритмы с графами реализуются элементарно, как только поймёте шо это не ноды владеют друг другом, а граф владеет всеми нодами, которые конечно ссылаются друг на друга, но не владеют.
В качестве бесплатного бонуса, вы получите ускорение алгоритма на десятки процентов, потому шо становится технически просто разместить все ноды графа в последовательных адресах памяти.
Из языков на которых программирую, сложнее всего с управлением памятью в Оbjective-C — у Apple как обычно всё через задницу.
Здравствуйте, 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.
Здравствуйте, DreamMaker, Вы писали:
DM>C++ недоязык. просто недоразумение какое-то, коему я отдал слишком много лет жизни. если косяки исправить — получится шарп. назад — только в кошмарном сне.
Толсто, товарисчъ Недоразумение — это ваше высказывание.
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Привет всем, KA>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Привет всем, KA>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу KA>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ! KA>
13 лет на плюсах. Один на шарпе (по началу — феерические ощущения). Потом снова 9 месяцев на плюсах (кстати, после шарпа, с очень хорошим плюсом. но дело не в языке). Сейчас вот снова на шарпе, и снова прет
Наверное меня просто прет от программирования как такового. А наличие возможностей, которые были недоступны в суровом социалистическом детстве, только усиливает ощущения
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Привет всем, KA>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу KA>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ! KA>
Шарп, пожалуй, самый приятный язык программирования с адаптацией под любые кривые руки, и под прямые тоже. Но развращает. Надо время от времени делать встряску себе, хотя бы вставлением native кода чтобы вспоминать как компьютер работает
Лучше конечно по ходу всегда мысленно транслировать C# в C++ чтобы становилось страшно и приятно одновременно. Это не будет позволять слишком отрываться от реальности )
Здравствуйте, include2h, Вы писали:
I>Здравствуйте, Big Ben, Вы писали:
BB>>Шарп, пожалуй, самый приятный язык программирования с адаптацией под любые кривые руки, и под прямые тоже.
I>10 лет кодил кодесы на С++. Тут недавно взял проект на c#. Язык конечно хороший, синтаксис более красивый и продуманный, но... I>В си есть такая функция atoi. Простая как дупель пусто-пусто. Любую строку, если в строке записано число, превращает в число, иначе возвращает ноль.
Эта функция в C++ deprecated, так как не позволяет отличить 0 от невалидной строки. Лучше использовать strtol.
I>Меня это вполне устраивало... но нет, в C# аналог (Convert.TiInt32) зачем-то выбрасывает исключение. Пришлось писать функцию-обертку в специальном статическом классе.
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ!
У меня C# не пошел. Если мне не важна производительности, то я выберу что-то питоно или рубиподобное. а если производительность нужна, то программирование на C# для меня достаточно некомфортно.
Здравствуйте, MTD, Вы писали:
KA>>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу KA>>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ! MTD>Есть мнение, что ты не плюсах писал, а на С с классами, после него от сборки мусора эйфория. А вот после плюсов смотришь на сборщика мусора как на бесполезного сельского дурочка.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, MTD, Вы писали:
MTD>>Есть мнение, что ты не плюсах писал, а на С с классами, после него от сборки мусора эйфория. А вот после плюсов смотришь на сборщика мусора как на бесполезного сельского дурочка.
F>а как "мегаплюсы" решают эту проблему лучше?
Да нет никакой проблемы с утечками: нужно создавать объекты динамически — используй unique_ptr\shared_ptr\weak_ptr, нужен локальный буфер — std::vector\std::array, надо за ресурсом следить — RAII парадигам в помощь.
Проблема в другом — очень маленькая стандартная библиотека — множество стандартных задач остаются за бортом и надо либо искать что-то либо свое городить.
Здравствуйте, michae1, Вы писали:
MTD>>>Есть мнение, что ты не плюсах писал, а на С с классами, после него от сборки мусора эйфория. А вот после плюсов смотришь на сборщика мусора как на бесполезного сельского дурочка. F>>а как "мегаплюсы" решают эту проблему лучше? M>Да нет никакой проблемы с утечками: нужно создавать объекты динамически — используй unique_ptr\shared_ptr\weak_ptr
и городи что-то своё, чтобы решить тривиальные проблемы. да, всё так и есть.
M>Проблема в другом — очень маленькая стандартная библиотека — множество стандартных задач остаются за бортом и надо либо искать что-то либо свое городить.
Здравствуйте, netch80, Вы писали:
N>Как удобно — списал все неприятные случаи на "кривой дизайн" и доволен, что C++ разрешает справиться с остальными случаями.
N>Я неоднократно встречался с ситуациями, когда естественным представлением предметной области является "сеть" объектов в памяти со многими связями. Например, такое типично в картографии, или в анализе структур человеческих связей.
Давай на конкретном примере, я тебе напишу код без проблемы цикличных ссылок или признаю, что ошибался?
Здравствуйте, neFormal, Вы писали:
F>ну зачем же фантазировать? F>shared_ptr — для использования такой тривиальной штуки, как шаблонный метод, требует регулярных кучерявых кастингов. не?
Зачем в шаблонном методе shared_ptr? Кастинги — признак плохого дизайна. Пример кода есть?
Здравствуйте, MxMsk, Вы писали:
I>>Вот и еще одну обертку пришлось писать. MM>Может, вместо обертки стоит книжечки там почитать, документацию? Форумы к конце то концов!
Нет у чела времени изучать, кодить надо!
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Привет всем, KA>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу KA>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ! KA>
У нас архитектор на плюсах 13 лет писал, потом перешел на C# (уже год скоро). Говорит, на плюсы не вернется ни под каким предлогом
Здравствуйте, MTD, Вы писали:
MTD>Давай на конкретном примере, я тебе напишу код без проблемы цикличных ссылок или признаю, что ошибался?
Конкретный пример: в метод объекта передается функция, которая сохраняется для последующего использования. Как узнать, что эта примитивная операция не создает цикла?
Здравствуйте, MTD, Вы писали:
MTD>Это не пример, а демагогия. Я не говорил, что в С++ нельзя прострелить себе ногу, как раз это философия языка — меня можно использовать безопасно, но если ты такой умный, то действуй на свой страх и риск. Я говорил о том, что проблема циклических сылок — проблема дизайна. Или ты думаешь, что в языках со сборщиком мусора нет утечек памяти? Показать пример, как прострелить себе ногу?
Покажи. Только без примера типа "в бессмысленной цепочке объектов, на которую ссылается забытое из-за legacy поле популярного объекта, непонятно почему приютилась ссылка на 20GB непонятной неудаляемой херни".
Здравствуйте, MTD, Вы писали:
N>>Как удобно — списал все неприятные случаи на "кривой дизайн" и доволен, что C++ разрешает справиться с остальными случаями.
N>>Я неоднократно встречался с ситуациями, когда естественным представлением предметной области является "сеть" объектов в памяти со многими связями. Например, такое типично в картографии, или в анализе структур человеческих связей.
MTD>Давай на конкретном примере, я тебе напишу код без проблемы цикличных ссылок или признаю, что ошибался?
Нет, давай вначале разберёмся с общим подходом. Ты настаиваешь на написании кода без циклических ссылок вообще? Или "без проблемы циклических ссылок"?
Здравствуйте, MTD, Вы писали:
F>>ну зачем же фантазировать? F>>shared_ptr — для использования такой тривиальной штуки, как шаблонный метод, требует регулярных кучерявых кастингов. не? MTD>Зачем в шаблонном методе shared_ptr?
предлагаешь вручную управлять памятью?
MTD>Кастинги — признак плохого дизайна.
upcasting или downcasting? или оба вместе?
MTD>Пример кода есть?
Здравствуйте, netch80, Вы писали:
MTD>>Давай на конкретном примере, я тебе напишу код без проблемы цикличных ссылок или признаю, что ошибался?
N>Нет, давай вначале разберёмся с общим подходом.
Здравствуйте, netch80, Вы писали:
N>Покажи. Только без примера типа "в бессмысленной цепочке объектов, на которую ссылается забытое из-за legacy поле популярного объекта, непонятно почему приютилась ссылка на 20GB непонятной неудаляемой херни".
Почему, нет? Неиспользуемы поля встречаются гораздо чаще циклических ссылок
Здравствуйте, MTD, Вы писали:
MTD>>>Зачем в шаблонном методе shared_ptr? F>>предлагаешь вручную управлять памятью? MTD>Нет. shared_ptr реально нужен в 1 случае из 200.
как тогда предлагаешь управлять памятью?
MTD>>>Кастинги — признак плохого дизайна. F>>upcasting или downcasting? или оба вместе? MTD>Везде где надо что-то привести вручную.
т.е. shared_ptr — признак плохого дизайна? кхм
MTD>>>Пример кода есть? F>>не знаешь, как делается шаблонный метод? MTD>Меня интересует твоя реализация.
Здравствуйте, MTD, Вы писали:
MTD>Ты все перепутал — GC паттерн из прошлого века, тормозной и ненужный.
Да фиг с ним, что тормозной. Плохо, что он бывает внезапно тормозной.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, neFormal, Вы писали:
MTD>>>Нет. shared_ptr реально нужен в 1 случае из 200.
F>>как тогда предлагаешь управлять памятью? Ops>Открой для себя контейнеры.
А что контейнеры ? Если нужна полноценная инверсия управления, то нужны замыкания, а следовательно и GC. Все, приехали.
Здравствуйте, netch80, Вы писали:
N>Нет, давай вначале разберёмся с общим подходом. Ты настаиваешь на написании кода без циклических ссылок вообще? Или "без проблемы циклических ссылок"?
Попробуй соорудить реализацию объекта с Dispose в которой бы:
— было запрещено использовать объект после вызова Dispose.
— Dispose не "разрушал" объект, пока работают другие его методы.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Ops, Вы писали:
MTD>>>Нет. shared_ptr реально нужен в 1 случае из 200. F>>как тогда предлагаешь управлять памятью? Ops>Открой для себя контейнеры.
при чём тут контейнеры? мне их на каждый чих создавать?
MTD>>>Меня интересует твоя реализация. F>>моя вполне классическая. Ops>Ну так приведи, а не отмазывайся.
Здравствуйте, Евгений Акиньшин, Вы писали:
MTD>> но замечу, что циклические ссылки — проблема кривого дизайна
ЕА>Это когда они стали плохим дизайном и почему
Здравствуйте, Ops, Вы писали:
Ops>>>Открой для себя контейнеры. F>>при чём тут контейнеры? мне их на каждый чих создавать? Ops>Вроде же ты про управление памятью начал?
"Ноды" и связи — это отдельный вещи (со своими счетчиками ссылок). И хранятся они отдельно. Связи ссылаются на "ноды". Кстати, связи могут выступать нодами для следующего уровня связей и так далее.
Вообще говоря, одним счетчиком тут не обойтись. Делается два счетчика — первый низкоуровневый (который убивает объект при обнулении), а второй отвечает за подсчет ссылок на объект внутри графа (когда обнуляется может уведомить "глобальный контейнер" о "ненужности" объекта).
Поверх этих "низкоуровневых" объектов, можно соорудить другой набор объектов (создаваемых динамически, то есть по-требованию) который бы упрощал получение входящих и исходящих связей для "нодов".
На первый взгляд — выглядит муторно. Но если есть шаблоны для конструирования подобных вещей, то такие конструкции создаются тоннами в рамках рабочего дня
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, noone, Вы писали:
N>Здравствуйте, MTD, Вы писали:
MTD>>Давай на конкретном примере, я тебе напишу код без проблемы цикличных ссылок или признаю, что ошибался?
N>Конкретный пример: в метод объекта передается функция, которая сохраняется для последующего использования. Как узнать, что эта примитивная операция не создает цикла?
Это не конкретный пример, а конкретный способ решения.
Здравствуйте, neFormal, Вы писали:
MTD>>>>Меня интересует твоя реализация. F>>>моя вполне классическая. Ops>>Ну так приведи, а не отмазывайся.
F>в гугле забанили?
Здравствуйте, Sinix, Вы писали:
КД>>Попробуй соорудить реализацию объекта с Dispose в которой бы: КД>>- было запрещено использовать объект после вызова Dispose. КД>>- Dispose не "разрушал" объект, пока работают другие его методы.
S>Дотнетовский Dispose заточен под самый популярный сценарий — один владелец, объект гарантированно не будет использоваться в дальнейшем.
Кем гарантируется? Программистом?!
Упаси меня Господь закладываться на такие гарантии
> Я бы смотрел в сторону RX/тасков.
Не, спасибо (хоть бы ссылку дали, что-ли, для темных).
Я как-то по-старинке — прикрутил "неявный" счетчик ссылок к подобным объектам и закрыл эту тему для себя
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, MTD, Вы писали:
MTD>Ну бред же написан Что нибудь из реальной жизни есть?
Этот бред имеет отдельную поддержку от языка в C# — http://msdn.microsoft.com/en-us/library/ms173171(v=vs.80).aspx . Наверное, от скуки они его туда 10 лет назад приделали, тебя потроллить. Это в качестве примера, в других языках это делают без дополнительного сахара. Охотно верю, что С++ — единственная среда, до которой новинки пятидесятилетней давности не дошли.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Попробуй соорудить реализацию объекта с Dispose в которой бы: КД>- было запрещено использовать объект после вызова Dispose. КД>- Dispose не "разрушал" объект, пока работают другие его методы.
Нужен, как я понял, shared ресурс: счетчик ссылок в руки, он как раз для этого придуман. Файлы и сокеты не грозят циклическими ссылками (кроме каких-нибудь патологических случаев), так что механизм отлично будет работать.
Кстати, Microsoft мог встроить автоматическую поддержку этого для IDisposable в компилятор/рантайм, раз уж они начали. Видимо, есть занятия поважней.
Здравствуйте, noone, Вы писали:
КД>>Попробуй соорудить реализацию объекта с Dispose в которой бы: КД>>- было запрещено использовать объект после вызова Dispose. КД>>- Dispose не "разрушал" объект, пока работают другие его методы.
N>Нужен, как я понял, shared ресурс: счетчик ссылок в руки, он как раз для этого придуман. Файлы и сокеты не грозят циклическими ссылками (кроме каких-нибудь патологических случаев), так что механизм отлично будет работать. N>Кстати, Microsoft мог встроить автоматическую поддержку этого для IDisposable в компилятор/рантайм, раз уж они начали. Видимо, есть занятия поважней.
Не, это только начало.
Допустим, правильную реализацию Dispose мы победили.
А теперь следующая задача.
Есть два связанных объекта. Пусть это будет подключение и транзакция. И нужно запретить диспозить подключение, пока работает код в объекте транзакции.
Опять юзаем счетчик ссылок. Только счетчик находится в одном объекте, а инкрементит/декрементит его другой объект.
И еще нужно не забыть прикрутить ко всему этому делу CER, чтобы гарантированно выполнить декремент. Я прав?
Вообщем, лично у меня сформировалось мнение — что счетчик ссылок это костыли не для плюсов (где, формально, это фундамент для более менее сложных вещей, и его не замечают так же как воздух), а для C#-а
---
Но мне нравится писать на обоих языках
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, Евгений Акиньшин, Вы писали:
MTD>>> но замечу, что циклические ссылки — проблема кривого дизайна
ЕА>>Это когда они стали плохим дизайном и почему
MTD>Уточнение — владеющие. Это из контекста понятно.
Ну может кому-то и понятно, а в управляемых средах нет необходимости в искусственных разграничениях на владеющие\ не владеющие ссылки
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, Sinix, Вы писали:
КД>>>Попробуй соорудить реализацию объекта с Dispose в которой бы: КД>>>- было запрещено использовать объект после вызова Dispose. КД>>>- Dispose не "разрушал" объект, пока работают другие его методы.
S>>Дотнетовский Dispose заточен под самый популярный сценарий — один владелец, объект гарантированно не будет использоваться в дальнейшем.
КД>Кем гарантируется? Программистом?!
Языком (см using). При нормальном процессе разработки ещё и FxCop-ом на билдсервере
dispose + using заточен под сценарии, когда время жизни ресурса заведомо меньше цикла сборки мусора, иначе освобождение ресурсов (если оно вообще требуется) спокойно может переехать в финалайзер.
как наглядный пример:
using (var fileWriter = OpenFile(...))
{
// запись в файл
// ...
} // Происходит вызов fileWriter.Dispose()
// здесь к fileWriter-у при всём желании не обратишься.
Если настроен FxCop и забыли обернуть xmlWriter в using — будет предупреждение (или ошибка, смотря как настроить) при сборке.
Если ваш ресурс должен жить столько же, сколько овнер, то овнер тоже должен реализовать IDisposable и освобождать используемые ресурсы. Забыли — снова варнинг.
КД>Упаси меня Господь закладываться на такие гарантии
Эмм... какие ещё гарантии нужны?
>> Я бы смотрел в сторону RX/тасков. КД>Не, спасибо (хоть бы ссылку дали, что-ли, для темных).
Но перед тем, как туда лезть, придётся основательно подучить матчасть и определиться с задачей, иначе выйдет только хуже.
Если проблема вот в этом:
Есть два связанных объекта. Пусть это будет подключение и транзакция. И нужно запретить диспозить подключение, пока работает код в объекте транзакции.
то использование dispose напрямую вам ничем не поможет. Если отвлечься от самой проблемы:
— транзакция подписывается на connection.Closing и кидает исключение, если что не так.
— соединение хранит внутри себя аналог RefCountDisposable из Rx и отдаёт транзакции ссылку через GetDisposable()
Если не отвлекаться — нужно подробно изучать вот этот док. Ресурсы в транзакции (особенно в распределённых транзакциях) — достаточно сложная штука, свои велосипеды вылезут боком.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, noone, Вы писали:
КД>Есть два связанных объекта. Пусть это будет подключение и транзакция. И нужно запретить диспозить подключение, пока работает код в объекте транзакции. КД>Опять юзаем счетчик ссылок. Только счетчик находится в одном объекте, а инкрементит/декрементит его другой объект. КД>И еще нужно не забыть прикрутить ко всему этому делу CER, чтобы гарантированно выполнить декремент. Я прав?
Аббревиатуру не осилил, но идея понятна. Да, все как ты сказал.
КД>Вообщем, лично у меня сформировалось мнение — что счетчик ссылок это костыли не для плюсов (где, формально, это фундамент для более менее сложных вещей, и его не замечают так же как воздух), а для C#-а
Сам механизм подсчета ссылок не хороший и не плохой, он просто есть и имеет некоторую семантику. В C++ он реализован через костыль — семейство *_ptr и используется везде, в C# — тоже (классы с ручным retain/release) и используется только для внешних к программе ресурсов. Пример подсчета без костылей — современный Objective-C, где сохраняются все достоинства подсчета и его недостатки, но, по крайней мере, он поддерживается непосредственно компилятором. Это очень важное свойство — доступна куча статических проверок и взаимодействие между библиотеками от разных автором в области управления памятью прозрачное насколько это возможно.
КД>--- КД>Но мне нравится писать на обоих языках
Здравствуйте, noone, Вы писали:
КД>>Есть два связанных объекта. Пусть это будет подключение и транзакция. И нужно запретить диспозить подключение, пока работает код в объекте транзакции. КД>>Опять юзаем счетчик ссылок. Только счетчик находится в одном объекте, а инкрементит/декрементит его другой объект. КД>>И еще нужно не забыть прикрутить ко всему этому делу CER, чтобы гарантированно выполнить декремент. Я прав?
N>Аббревиатуру не осилил, но идея понятна. Да, все как ты сказал.
Это я про "Constrained Execution Regions" говорил.
N>Сам механизм подсчета ссылок не хороший и не плохой, он просто есть и имеет некоторую семантику. В C++ он реализован через костыль — семейство *_ptr
Я всегда думал, что "костыль" (в плане счетчика ссылок) это когда руками вызываешь AddRef/Release и постоянно паришься чтобы не облажаться с ними. В нормально спроектированной программе таких проблем нет.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, noone, Вы писали:
КД>Это я про "Constrained Execution Regions" говорил.
Это вовсе необязательно. Декремент делается в finally.
N>>Сам механизм подсчета ссылок не хороший и не плохой, он просто есть и имеет некоторую семантику. В C++ он реализован через костыль — семейство *_ptr
КД>Я всегда думал, что "костыль" (в плане счетчика ссылок) это когда руками вызываешь AddRef/Release и постоянно паришься чтобы не облажаться с ними.
Да. А еще костыль это еще когда тулзы не могут при взгляде на программу сказать, что же тут происходит. Или когда в дебаггере черт ногу сломит из-за лишних объектов. Когда умных указателей целый зоопарк, и в каждой библиотеке он свой, и есть тонна имплицитных преобразований между одними и другими (пользуясь случаем, передаю привет WebKit вообще и PassRefPtr в частности). Одним словом, костыль это когда семантика языка плохо ложится на задачу и средствами языка правится плохо.
Здравствуйте, noone, Вы писали:
КД>>Это я про "Constrained Execution Regions" говорил.
N>Это вовсе необязательно. Декремент делается в finally.
Ага. Он у меня и делается в finally. Надо только что бы этот finally гарантировано вызвался. Для этого и юзаю CER. Может я что конечно попутал в этом деле, но решил перестраховаться по-полной
Впрочем, я сверялся с кодом из самого фреймворка, и думаю я ничего не напутал.
N>Да. А еще костыль это еще когда тулзы не могут при взгляде на программу сказать, что же тут происходит. Или когда в дебаггере черт ногу сломит из-за лишних объектов. Когда умных указателей целый зоопарк, и в каждой библиотеке он свой, и есть тонна имплицитных преобразований между одними и другими (пользуясь случаем, передаю привет WebKit вообще и PassRefPtr в частности). Одним словом, костыль это когда семантика языка плохо ложится на задачу и средствами языка правится плохо.
Не, ну зоопарк можно где угодно соорудить
У меня только два типа смарт-указателей — для COM-а и для моих классов. И они никак не пересекаются. Можно считать — полная гармония и умиротворенность
А от всяких ужосов типа буста и еже с ними — я (по правде говоря) шарахаюсь
Со сложностью борюсь всякими злобными методами. Перечислять которые нет смысла.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Ну может кому-то и понятно, а в управляемых средах нет необходимости в искусственных разграничениях на владеющие\ не владеющие ссылки
Нет необходимости, только если класс не содержит неуправляемых ресурсов. В протипвном случае, вылезают всякие неочевидные вещи, типа
Смешались в кучу кони, люди ... Встроенная в платформу реализация publisher/subscriber это event. Delegate это просто функциональный тип. И да, можно обходится и без event, как в других языках, Rx тому примером.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Встроенная в платформу реализация publisher/subscriber это event.
Да, это один из самых популярных методов, которые мне попадались, "как сделать утечку памяти на C#".
Здравствуйте, noone, Вы писали:
N>Это натурально простейший практический кусочек, проще него только репа. Примеров на C# можно обчитаться в вышеприведенной ссылке. Вот микропример на Java
N>При подсчете ссылок придется явно городить слабую ссылку на this (костыль). В чуть более сложном случае — курить бамбук (много костылей) с риском получить висячие ссылки/утечки.
Вот, наконец адекватный пример. Так вот, если из плюсов пытаться яву сделать, то да, будет связка shared_ptr/weak_ptr. А если на плюсах писать, то будет так:
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Смешались в кучу кони, люди ... Встроенная в платформу реализация publisher/subscriber это event. Delegate это просто функциональный тип. И да, можно обходится и без event, как в других языках, Rx тому примером.
OK. Назовем все это Observer — лучше?
То, что можно обойтись без чего угодно, я знаю. Вернемся к исходному вопросу: могу ли я сохранить объект, который мне пришел в метод/функцию, или нет? И что делать, когда объект точно нужен, но сохранять его нельзя, т.к. есть вероятность цикла? Правильно: перепиливаем архитектуру, добавляем хаки по вкусу. Или используем GC.
Здравствуйте, MTD, Вы писали:
MTD>Вот, наконец адекватный пример. Так вот, если из плюсов пытаться яву сделать, то да, будет связка shared_ptr/weak_ptr. А если на плюсах писать, то будет так:
Это тот же самый пример (чуть проще). Интересно, что ты его узнал только когда речь пошла о UI.
MTD>
Здесь мы наблюдаем, как байндится raw-указатель this, то есть явно используется факт того, что кнопка живет не дольше this. Чуть усложним Java-пример:
interface Listener {
void doSomething();
}
public class MyPanel extends JPanel implements Listener {
JButton myButton;
public void initButton(final Listener listener) {
myButton = new JButton("Do something");
myButton.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
listener.doSomething();
}
});
add(myButton);
}
@Override
public void doSomething() {
}
public static void main(String[] args) {
MyPanel p = new MyPanel();
p.initButton(p);
p.initButton(new Listener() {
@Override
public void doSomething() {
}
});
}
}
Теперь в initButton может передаваться как this, так и совершенно посторонний listener. Время жизни зарегистрированного listener должно быть не меньше времени жизни кнопки.
Здравствуйте, Константин, Вы писали:
К>Из языков на которых программирую, сложнее всего с управлением памятью в Оbjective-C — у Apple как обычно всё через задницу.
Как оно может быть сложнее С++, если там shared_ptr и weak_ptr встроены в язык?
Здравствуйте, noone, Вы писали:
N>Как оно может быть сложнее С++, если там shared_ptr и weak_ptr встроены в язык?
C++
Опасные вещи, такие как операторы new/delete нужны крайне редко.
Если в полях объекта только smart pointers и generic collections, то при удалении объекта все его поля удалятся автомагически.
Если конструировать top-level objects только на стеках – вам вообще не нужно заниматься управлением памятью, за вас всё сделают язык, компилятор и библиотеки.
Obj-C
Даже при использовании рекомендуемой практики @property(retain), если вы забыли освободить какое-то поле в методе -(void)dealloc, вот она утечка.
Случайно сослались на self в блоке — получили циклическую ссылку.
Более безопасных альтернатив не существует.
Здравствуйте, noone, Вы писали:
N>То, что можно обойтись без чего угодно, я знаю. Вернемся к исходному вопросу: могу ли я сохранить объект, который мне пришел в метод/функцию, или нет? И что делать, когда объект точно нужен, но сохранять его нельзя, т.к. есть вероятность цикла? Правильно: перепиливаем архитектуру, добавляем хаки по вкусу. Или используем GC.
Тут суть не столько в Publisher/Subscriber, сколько в замыканиях. И таки да, известный факт — без GC замыкания неюзабельны.
Здравствуйте, 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>>Что опасного в создании объекта? К>Тем что потом кто-то другой, часто непонятно кто именно, должен его удалять.
Ну так это в С++ опасная операция. В других языках — нет.
К>Это в Штатах телефоны спонсируются операторами, потому полностью обновляются за 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>
Автомат — это ещё потеря части мощности двигателя, повышенный расход бензина, повышенной износ тормозных дисков и большая ломучесть.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, MTD, Вы писали:
MTD>>>>Зачем в шаблонном методе shared_ptr? F>>>предлагаешь вручную управлять памятью? MTD>>Нет. shared_ptr реально нужен в 1 случае из 200.
F>как тогда предлагаешь управлять памятью?
scoped_ptr(array) жи есть. Разные контейнеры.
F>т.е. shared_ptr — признак плохого дизайна? кхм
Ну типа да.
Здравствуйте, michae1, Вы писали:
M>Здравствуйте, DreamMaker, Вы писали:
DM>>C++ недоязык. просто недоразумение какое-то, коему я отдал слишком много лет жизни. если косяки исправить — получится шарп. назад — только в кошмарном сне.
M>Толсто, товарисчъ Недоразумение — это ваше высказывание.
M>Расскажи какие косяки были исправлены в с#?
Ну я понял, ляпнуть хочеться, а ответить-то нечего , зато минусы ставим. Слив засчитан.