Здравствуйте, MxKazan, Вы писали:

MK>Запустил в debug — массив жил на протяжении работы приложения.
MK>Запустил в release, но из под Студии — массив жил на протяжении работы приложения.
MK>Запустил в release просто из Проводника — объекты массива d начали собираться GC еще на этапе загрузки главного окна приложения.

При подключении дебагера время жизни локальных переменных продляется до конца блока.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, gandjustas, Вы писали:

Х>>>пойнт был не в строках а в константности объектов, замени строку на экземпляр своего класса и разрыдайся вместе со сторонниками C#
G>>Тоже ничего не произойдет, поменяется ссылка внутри метода.
G>>Будет плохо если лезть в поля объекта, но так мало кто делает, потому что можно вернуть новый объект из метода и не заботиться о его времени жизни. В C++ так нельзя.

ГВ>Можно, но так не любят делать, чтобы не связываться с дополнительным оверхедом по быстродействию.



Это в языке, который не имеет оверхедов (с)

Здравствуйте, Геннадий Васильев, Вы писали:

O>>>т.к. хочется сделать красиво, а не можется
G>>Красиво это как? Нафигачить шаблоков?
G>>И как на плюсах сделать красиво IoC-контейнер?
ГВ>Какой именно? В смысле — под какое использование?
Например как MSовский Unity.

G>>>>Такие выкрутасы с перегрузкой от бедности языка, а обилиле подобных "фич" только повышают возможность создать нифига нечитаемый код.
O>>> возможность перегружать это от бедности?
G>>Нет, примерение этой возможности — от бедности.
G>>В Boost даже зяпятую перегрузили потому что инициализаторов коллейкций не было. В C# таки догоадались включить эту фичу.

ГВ>Значит, если отсутствующую фичу реализовали средствами языка — это, типа, недостаток языка. Ясен пень — язык будет плох до тех пор, пока в него не будет прямо включено всё-всё известное на данный момент во всех доступных комбинациях. А то не ровён час — библиотеку писать придётся. Логика жжот напалмом! Сила слова, да.
C# развивающийся язык, за 5 лет в него включили столько фич, сколько С++ не снилось за всю историю существования. И при этом C# не превратился в помойку.
В С++ развивать языковые средства можно, но очень осторожно, новый стандарт это показывает. Кстати, когда очередной раз планируется его принятие?


G>>COM это хорошо, но мееедлеееенно в случае outproc и небезопасно в случае inproc. Вот тебе и дилемма, выход из которой — managed код.
ГВ>Какая ещё дилемма? C++ плохо интеропится с C++-ными либами при несогласованном ABI. Проблема и понятна, и решена в большей или меньшей степени. Через старый добрый C-интерфейс он прекрасно связывается с чем угодно.
Угу, и вся "мощь абстракций" упрется в вызовы GetSomeHandle в итоге. Потрясающий язык.

ГВ>Кстати, а две виртуальных машины .Net (в смысле — два активных экземпляра .Net FW) разных версий свяжутся друг с другом "естественным" порядком? Или тоже с бубном и интеропом поплясать надо?
Сейчас два СДК разных версий не уживаются в одном процессе, то есть нельзя запустить сборку с FW1.1 в процессе FW2.0, но такое очень редко случается. Разные версии FW хорошо совместимы по исходному коду и пересобрать под второй фреймворк (и 3.0 и 3.5) не представляет проблем.
Следующая версия CLR будет нормально работать в одном процессе с предыдущими.

ГВ>А .Net с Java естественно стыкуются?
только интероп через C или средства межпроцессного взаимодействия.

Здравствуйте, gandjustas, Вы писали:

G>>>Будет плохо если лезть в поля объекта, но так мало кто делает, потому что можно вернуть новый объект из метода и не заботиться о его времени жизни. В C++ так нельзя.

ГВ>>Можно, но так не любят делать, чтобы не связываться с дополнительным оверхедом по быстродействию.

G>

G>Это в языке, который не имеет оверхедов (с)

Никто не утверждал, что на C++ бесконечный цикл исполняется за 0 секунд.

Здравствуйте, gandjustas, Вы писали:

O>>>>т.к. хочется сделать красиво, а не можется
G>>>Красиво это как? Нафигачить шаблоков?
G>>>И как на плюсах сделать красиво IoC-контейнер?
ГВ>>Какой именно? В смысле — под какое использование?
G>Например как MSовский Unity.

OK, теперь давай выясним, что такое "красиво". Желательный интерфейс набросаешь кратенько?

ГВ>>Значит, если отсутствующую фичу реализовали средствами языка — это, типа, недостаток языка. Ясен пень — язык будет плох до тех пор, пока в него не будет прямо включено всё-всё известное на данный момент во всех доступных комбинациях. А то не ровён час — библиотеку писать придётся. Логика жжот напалмом! Сила слова, да.
G>C# развивающийся язык, за 5 лет в него включили столько фич, сколько С++ не снилось за всю историю существования. И при этом C# не превратился в помойку.

И как это опровергает сказанное мной? Что если фича реализована средствами языка — это не недостаток самого языка?

G>В С++ развивать языковые средства можно, но очень осторожно, новый стандарт это показывает.

ИМХО, новый стандарт показывает ещё и вполне традиционный подход: зачем менять язык, если свойства некой фичи можно реализовать имеющимися средствами? Собственно, это много раз сказано в D&E.

G>Кстати, когда очередной раз планируется его принятие?

Шут их знает. Не то в этом году, не то в следующем.

ГВ>>Какая ещё дилемма? C++ плохо интеропится с C++-ными либами при несогласованном ABI. Проблема и понятна, и решена в большей или меньшей степени. Через старый добрый C-интерфейс он прекрасно связывается с чем угодно.
G>Угу, и вся "мощь абстракций" упрется в вызовы GetSomeHandle в итоге. Потрясающий язык.

Почему? Компоновку вызовов GetSomeHandle в классы никто не отменяет.

ГВ>>Кстати, а две виртуальных машины .Net (в смысле — два активных экземпляра .Net FW) разных версий свяжутся друг с другом "естественным" порядком? Или тоже с бубном и интеропом поплясать надо?
G>Сейчас два СДК разных версий не уживаются в одном процессе, то есть нельзя запустить сборку с FW1.1 в процессе FW2.0, но такое очень редко случается. Разные версии FW хорошо совместимы по исходному коду и пересобрать под второй фреймворк (и 3.0 и 3.5) не представляет проблем.
G>Следующая версия CLR будет нормально работать в одном процессе с предыдущими.
ГВ>>А .Net с Java естественно стыкуются?
G>только интероп через C или средства межпроцессного взаимодействия.

Вопросы были риторическими. Иными словами, на самом деле проблем с совместимостью и интероперабельностью хватает у всех, так что выпячивать аналогичные недостатки C++ как некие особенные тут нет никакого смысла.

Здравствуйте, criosray, Вы писали:

C>Откуда информация? Дайте ссылку на авторитетный источник.

Покопайся в сообщениях вот этого сиятельного господина.

Здравствуйте, Anton Batenev, Вы писали:

AB> M> Чектого определения нет. Обычно просто обозначает высококачественную игру с большим бюдэетом.

AB> А предполагается, что качество напрямую коррелирует с размером бюджета?

Неа Тут все типа вилами по воде. Если игра огромнобюджетная + качественная + «не провалилась в прокате» (по аналогии с фильмами ), то это — ААА

Мне кажется, что языки, используемые нами для выражения своих идей, становятся частью нас самих, поэтому, если вы знаете только один язык, может показаться, будто сторонники других языков представляют опасность лично для вас. Мне представляется, что выход из этой ситуации – освоение других языков. Сомневаюсь, что можно быть профессионалом в области ПО и знать лишь один язык программирования. Может быть и экономическая причина: фундаментальные знания выходят за границы языка программирования в отличие от многих практических навыков. Поэтому, если я знаю только язык X и его наборы инструментов, а вы являетесь сторонником языка Y и его наборов инструментов, вы представляете угрозу для источника моего заработка. И вновь решение, как мне кажется, — в знании нескольких языков и наборов инструментов (а также твердое понимание фундаментальных концепций).

Интервью++: Бьерн Страуструп об эволюции языков

Портфелем знаний мы предпочитаем называть все факты, известные программистам об информатике, обалсти приложений, в которых они работают, и накопленный ими опыт. Управление портфелем знаний очень похоже на управление финансовыми портфелем.
Предложения по поддержке портфеля знаний:
— Учите (как минимум) по одному языку программирования каждый год.
— Читайте по одной технической книге ежеквартально.
— Читайте книги, не относящиеся к технической литературе.
— Экспериментируйте с различными операционными средами.
Важно продолжать инвестирование. Как только вы почувствуете, что освоили новый язык или фрагмент технологии, двигайтесь дальше. Изучайте другой.
Неважно, будете ли вы когда-либо использовать одну из этих технологий в проекте или даже не упомянете о них в своем резюме. Процесс обучения расширит ваше мышление, открывая вас для новых возможностей и новых путей в творчестве. "Перекрестное опыление" идей важно; попытайтесь применить выученные уроки к проекту, над которым вы работаете в настоящее время. Даже если в вашем проекте не используется некая технология, вы наверняка сможете позаимствовать некоторые идеи.

Эндрю Хант и Дэвид Томас. Программист-прагматик. Путь от подмастерья к мастеру

Как сказал Дэвид Грфйс (Gries) подход к программированию не должен определяться используемыми инструментами. В связи с этим он проводит различие между программированием на языке (programming in lanuage) и программирование с использованием языка (programming into language). Разработчики, программирующие «на» языке, ограничивают свое мышление конструкциями, непосредственно поддерживаемых языком. Если предоставляемые языком средства примитивны, мысли программистов будут столь же примитивными.
Разработчики, программирующие «с использованием» языка, сначала решают, какие мысли они хотят выразить, после чего определяют, как выразить их при помощи конкретного языка.

Стив Макконнелл. Совершенный код.

Я привел три цитаты, каждая из которых говорит о второстепенной роли языка программирования в жизни разработчика. Причем автор одной из них имеет непосредственное отношение к одному из языков программирования!
Конечно же, я не придерживаюсь мысли, что язык программирования не играет никакой роли. Нет, это не так. Я не считаю, что не нужно углублять свои знания в конкретном языке или технологии; не считаю, что нужно выбросить книги Герба Саттера и Андея Александреску, Джошуа Блоха и Билла Вагнера, и не зачитыватся этюдами nikov-а на этом форуме. Все это очень полезно. Но польза не только в том, что эти знания вы можете использовать сейчас на текущем проекте с текущим языком и технологией, а в том, что эти знания позволят перейти вам на следующий уровень своего развития и решать более сложные задачи в следующих проектах, уже на совершенно других языках программирования и совершенно других технологиях.

Продолжая рассуждение о языках программирования в жизни разработчика, достаточно вспомнить, что пишет Брукс и Буч о сложности программных систем:

Эйнштейн неоднократно утверждал, что природа должна иметь простые объяснения, поскольку Богу не свойственны капризность и произвол. У программиста нет такого утешения: сложность, с которой он должен справиться, лежит в самой природе системы

а затем:

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

Как вы можете заметить, не один из этих пунктов не содержит фразы: «сложность программного обеспечения обусловлена неверным выбором языка программирования». Кроме того, вам будет довольно сложно найти цитату авторитетного автора, который бы сказал что-то вроде этого: «Изучение языка программирования А – это ваш путь к успеху. Благодаря ему уже через полгода его изучения вас ждет почет и уважение в среде разработчиков по всему миру, вы будете президентом корпорации и будете ездить на Bentley, а вот если ваш выбор остановится на языке программирования Б – вас ждет позор, забвение и жизнь на помойке».

На закуску, хочется привести еще одну цитату Ханта и Томаса:

Программирование – это прикладное искусство. Простейший его смысл заключается в следующем: заставить компьютер делать то, что вам нужно (или то, что нужно пользователю, работающему с вашей программой). Программист – он и слушатель, он и советник, он и переводчик и даже диктатор. Вы пытаетесь ухватить суть не совсем ясных требований и найти такой способ их выражения, что только машина сможет оценить их по достоинству. Вы пытаетесь задокументировать работу так, чтобы она была понятна другим, спроектировать ее так, чтобы другие могли на нее положиться. Кроме того, вы пытаетесь сделать все это вопреки безжалостному ходу стрелки часов, отсчитывающих время, отпущенное на проект. Каждый день вы совершаете по маленькому чуду.
Это непростая работа.
Многие предлагают вам помощь. Фирмы-поставщики инструментальных средств настойчиво говорят о чудесах, которые творят их программы. Мудрецы от методологии заверяют в том, что их средства гарантируют результаты. Каждый считает свой язык программирования лучшим из лучших, а операционную систему – панацеей.
Разумеется, эти утверждения неверны. Простых ответов не существует. Не существует такого понятия, как наилучшее решение, будь то инструментальное средство, язык или операционная система. Существует лишь некие системы, которые являются более приемлемыми при конкретном стечении обстоятельств.
И в этот момент на сцену выходит прагматизм. Стоит избегать обряда венчания с конкретной технологией, но при этом необходимо обладать подготовкой и опытом, настолько обширными, что это позволит выбрать верные решения в конкретных ситуациях. Ваша подготовка происходит из понимания основных принципов информатики, а опыт основывается на разнообразных практических проектах. Теория и практика сочетаются, придавая вам силу.

ЗЫ. топикпастеру (если он все еще читает это обсуждение): расценивай это обсуждение так, как будто оно находится в форуме «Коллеги, улыбнитесь». Главное – выбор интересного коллектива с интересной задачей, а язык программирования имеет второстепенное значение.

Здравствуйте, SergeyT.,

Отдельное спасибо за удачную подборку саму по себе.

Здравствуйте, gandjustas, Вы писали:

G>Да вот в этот раз нет. Именно по замерам времени выполнения код на F# оказался быстрее C++_ного варианта в 8 раз.

G>Правда никто мегаоптимизацией на С++ не занимался.
G>Вот и хочется увидеть вариант решения задачи на С++ от крутых перцев из КСВ.
видимо крутые перцы из КСВ заняты
я тут мимо прохожу раз в N дней, от того и лаги.
Судя по цифрам тот код на плюсах что у вас есть ничего не стоит — так что
обрежьте лишнее, и кидайте на публичный ресурс а ссылку в ответ.
Когда меня чужие баги задалбывают я для отдыха гоняю профайлер — так что если алгоритмы примерно похожи выгребание ошибок первого порядка позволит С++ "не ударить в грязь лицом".

зы. сделайте тестовый набор данных, эталон. Длина запуска не больше 5 минут на типовом железе. Мне вот может придется винду поставить ради этого — так что если будет совсем грустно то могу и забить.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, gandjustas, Вы писали:

O>>>>>т.к. хочется сделать красиво, а не можется
G>>>>Красиво это как? Нафигачить шаблоков?
G>>>>И как на плюсах сделать красиво IoC-контейнер?
ГВ>>>Какой именно? В смысле — под какое использование?
G>>Например как MSовский Unity.

ГВ>OK, теперь давай выясним, что такое "красиво". Желательный интерфейс набросаешь кратенько?
Угу. Есть метод Register, который заносит в контейнер пару (тип интерфейса, тип реализации), и метод Resolve, который по заданному типу интерфейса выдает объект нужного типа реализации.
Когда получится можно сделать так чтобы если тип реализации имеет конструктор с параметрами, то при создании объекта в параметры конструктора подсчтавлялись бы объекты полученные через Resolve.

ГВ>>>Значит, если отсутствующую фичу реализовали средствами языка — это, типа, недостаток языка. Ясен пень — язык будет плох до тех пор, пока в него не будет прямо включено всё-всё известное на данный момент во всех доступных комбинациях. А то не ровён час — библиотеку писать придётся. Логика жжот напалмом! Сила слова, да.
G>>C# развивающийся язык, за 5 лет в него включили столько фич, сколько С++ не снилось за всю историю существования. И при этом C# не превратился в помойку.
ГВ>И как это опровергает сказанное мной? Что если фича реализована средствами языка — это не недостаток самого языка?
Если фича востребована, а реализация делается через непонятно что. причем за много лет в самом языке это не было исправлено, то это однозначно свидетельствует о недостатке языка.


ГВ>>>Кстати, а две виртуальных машины .Net (в смысле — два активных экземпляра .Net FW) разных версий свяжутся друг с другом "естественным" порядком? Или тоже с бубном и интеропом поплясать надо?
G>>Сейчас два СДК разных версий не уживаются в одном процессе, то есть нельзя запустить сборку с FW1.1 в процессе FW2.0, но такое очень редко случается. Разные версии FW хорошо совместимы по исходному коду и пересобрать под второй фреймворк (и 3.0 и 3.5) не представляет проблем.
G>>Следующая версия CLR будет нормально работать в одном процессе с предыдущими.
ГВ>>>А .Net с Java естественно стыкуются?
G>>только интероп через C или средства межпроцессного взаимодействия.

ГВ>Вопросы были риторическими. Иными словами, на самом деле проблем с совместимостью и интероперабельностью хватает у всех, так что выпячивать аналогичные недостатки C++ как некие особенные тут нет никакого смысла.
На самом деле проблем нету, потому что все описанное является только потенциальными проблемами и очень редко встречается в жизни. Тогда как интероп между C++_ными библиотеками встречается часто.

Здравствуйте, SleepyDrago, Вы писали:

SD>Здравствуйте, gandjustas, Вы писали:

G>>Да вот в этот раз нет. Именно по замерам времени выполнения код на F# оказался быстрее C++_ного варианта в 8 раз.

G>>Правда никто мегаоптимизацией на С++ не занимался.
G>>Вот и хочется увидеть вариант решения задачи на С++ от крутых перцев из КСВ.
SD>видимо крутые перцы из КСВ заняты
За то время, котороекрутые перцы потратили на постинг булшита могли бы уже такую простую программку написать.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, ollv, Вы писали:

O>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, ollv, Вы писали:

O>>>> Кроме того, на плюсах вполне реализуемы элементы не родственных стурктур, к примеру итерации for_each, find_if count_if, функторы, придают плюсам оттенки функциональных языков
G>>>ржунимагу. шаблоны позволяют сделать то что уже есть в других языках
ну посмейся, может в процессе придет понимание того, что в с++ есть возможность сделать то, чего нет в других языках, и есть возможность сделать подобие того, чего в нем изначально не было, и есть в других. И это при том, что в нем можно работать как в менеджед, так и в анменеджед, Сравнивать же менеджед и анменеджед — изначально бредово, т.к. если идет сравнение возможностей, то последние молчат при необходимости работы с МАПИ и библиотеками с ансаппортным диспатч и т.д.

O>>>>но вообще метапрограммирование видоизменяет плюсы, а говорить, что это все можно реализовать в джава или дотнете — просто не знать плюсы
G>>>Рассказываю тайны, большенство программистов на C# достаточно долго программили на плюсах и отлично его знают.
G>>>А вот наоборот — редко бывает.
O>> пустые слова, шарп расхолаживает
G>Чего расхолаживает?
Ощущение , что попал в песочницу с необходимостью постоянно в случае невозможности рыть совочком, прыгать опять за забор или через импорт апишных методов, или чз написание дополнительных утилзов на сях

O>>>>Даже простейший вызов из темплейтного метода непредопределенного класса с оператором () — уже недостижимая мечта для шарпа или жавы.
G>>>Включай моз, для чего нужно переопределение скобок? Чтобы объект вел себя как функция, а это значит что возможностей функций не хватает.
O>> Преопределение скобок — это лишь перегрузка одного из операторов, и все, а то, что это получило свое развитие это отдельная история, но основа опять таки не в этом,
G>А в чем? Зачем скобки переопределять надо?
ты изначально поставил глупый вопрос, нафига в нете делегаты, что методов мало ?

O>>биндинг в плюсах покрывает делегаты, а вот обратного нет, т.к. теже функторы это лишь одно из множества, и не потому, что не хватает, а потому, что еще и так можно.
G>Это о чем? Какие делегаты, биндинг, функторы? Вывалил все умные словка, которые знаешь?
А ты подумай немного, ..как реализовывать late fastening в дотнете ? Когда конструирование аргументов, владельцев методов, и создание каскада вызовов разведено во времени? — никак. а через поздний биндинг это решается.

O>>а при писанине на дотнете после плюсов всегда чувствуешь тормоза, и ограниченность,
G>
G>Особенно тормоза

O>>т.к. хочется сделать красиво, а не можется
G>Красиво это как? Нафигачить шаблоков?
G>И как на плюсах сделать красиво IoC-контейнер?
да запросто, причем реализовывается с ограничение депенденси, при превышении даже собираться не будет

G>>>Такие выкрутасы с перегрузкой от бедности языка, а обилиле подобных "фич" только повышают возможность создать нифига нечитаемый код.
O>> возможность перегружать это от бедности?
G>Нет, примерение этой возможности — от бедности.
G>В Boost даже зяпятую перегрузили потому что инициализаторов коллейкций не было. В C# таки догоадались включить эту фичу.
ах в бууст даже запятую перегрузили .. ты меня реально утомил. Плюсы на столько гибкий язык, что позволяет имлементить реализации модифицирующие синтаксис, да еще и чик __asm и ты уже там . А тебя это раздражает Да

O>>>>Впрочем практика показывает, базовый функционал крупных проектов требующих гибкой архитектуры реализуется чаще на плюсах (во всяком случае в моей практике это именно так)
G>>>Какой гибкой архитектуры? C++ не умеет интеропать ни с какими другими языками, даже при интеропе с другой либой на С++ могут возникнуть проблемы.
O>> ему это и не надо, а для предоставления интерфейса наверх и предоставлен менеджед С++, и ком
G>Менеджед С++ вам не поможет, он интеропа между дувумя бинарями не добавляет.
G>COM это хорошо, но мееедлеееенно в случае outproc и небезопасно в случае inproc. Вот тебе и дилемма, выход из которой — managed код.
Ком нужен для определенной специфики, чтобы мегатяжелые менеджед грабли таки могли получить быстро работающий код, или код, который может дернуть то, чего ну никак не дернуть из менеджед , или просто попытаться избавить себя от гемороя мегатомных импортов. А для реализации прослоек используется менеджед си.

O>>>>констрейны дают возможность предопределить поведение при компиляции. Да и еще, плюсы то развиваются, стандарт постоянно дополняется новыми фичами расширяюшими возможности, typeof это не последнее
G>>>За последние 5 лет какое развитие было?
O>> фреймворки ж)
G>Мы про язык\стандартную библиотеку.
опять за рыбу деньги, — фреймворк внесенный в стандарт становится частью языка. Просто понимаешь какая штука, за время своего существования плюсы стали академическим языком, просто так внести новый фреймворк, не так просто нужно доказать, что в этом есть необходимость.

Здравствуйте, gandjustas, Вы писали:

G>>>Правда никто мегаоптимизацией на С++ не занимался.
G>>>Вот и хочется увидеть вариант решения задачи на С++ от крутых перцев из КСВ.
SD>>видимо крутые перцы из КСВ заняты
G>За то время, котороекрутые перцы потратили на постинг булшита могли бы уже такую простую программку написать.
если не интересно здесь кидайте к себе в блог. Ссылки на идею алгоритма недостаточно для того чтобы сдвинуть с места ленивого человека

Здравствуйте, ollv, Вы писали:

O>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, ollv, Вы писали:

O>>>Здравствуйте, gandjustas, Вы писали:

G>>>>Здравствуйте, ollv, Вы писали:

O>>>>> Кроме того, на плюсах вполне реализуемы элементы не родственных стурктур, к примеру итерации for_each, find_if count_if, функторы, придают плюсам оттенки функциональных языков
G>>>>ржунимагу. шаблоны позволяют сделать то что уже есть в других языках
O> ну посмейся, может в процессе придет понимание того, что в с++ есть возможность сделать то, чего нет в других языках, и есть возможность сделать подобие того, чего в нем изначально не было, и есть в других.
Ну тогда в студию GC, с такими же performance характеристиками, как в managed.

O>И это при том, что в нем можно работать как в менеджед, так и в анменеджед,
Это не является преимуществом.
У unmanaged вообще говоря достаточно мало преимуществ.

O>Сравнивать же менеджед и анменеджед — изначально бредово, т.к. если идет сравнение возможностей, то последние молчат при необходимости работы с МАПИ и библиотеками с ансаппортным диспатч и т.д.
.NET умеет работать с COM.

O>>>>>но вообще метапрограммирование видоизменяет плюсы, а говорить, что это все можно реализовать в джава или дотнете — просто не знать плюсы
G>>>>Рассказываю тайны, большенство программистов на C# достаточно долго программили на плюсах и отлично его знают.
G>>>>А вот наоборот — редко бывает.
O>>> пустые слова, шарп расхолаживает
G>>Чего расхолаживает?
O> Ощущение , что попал в песочницу с необходимостью постоянно в случае невозможности рыть совочком, прыгать опять за забор или через импорт апишных методов, или чз написание дополнительных утилзов на сях
Ты неверное в другом мире живешь.
Сколько я проектов сделал на .NET необходимость в вызовах нативных методов возникала раза два.
Неверное это от твоего незнания библиотеки.

O>>>>>Даже простейший вызов из темплейтного метода непредопределенного класса с оператором () — уже недостижимая мечта для шарпа или жавы.
G>>>>Включай моз, для чего нужно переопределение скобок? Чтобы объект вел себя как функция, а это значит что возможностей функций не хватает.
O>>> Преопределение скобок — это лишь перегрузка одного из операторов, и все, а то, что это получило свое развитие это отдельная история, но основа опять таки не в этом,
G>>А в чем? Зачем скобки переопределять надо?
O> ты изначально поставил глупый вопрос, нафига в нете делегаты, что методов мало ?
Делегаты можно считать навороченным "указателем на функцию", так как в .NET сам методы не являются FCO.
А в C++ не было ни делегатов и ФВП, были только указатели на функцию, которые как и все указатели наделены родовыми травмами.
Перегрузка скобок дает возможность делать что-то издалека похоже на делегаты .NET или ФВП, в остальном такая перегрузка нафиг не нужна.

O>>>биндинг в плюсах покрывает делегаты, а вот обратного нет, т.к. теже функторы это лишь одно из множества, и не потому, что не хватает, а потому, что еще и так можно.
G>>Это о чем? Какие делегаты, биндинг, функторы? Вывалил все умные словка, которые знаешь?
O> А ты подумай немного, ..как реализовывать late fastening в дотнете ? Когда конструирование аргументов, владельцев методов, и создание каскада вызовов разведено во времени? — никак. а через поздний биндинг это решается.
Ты вывалил все оставшиеся слова, которые знаешь? Покажи пример кода на С++.

O>>>т.к. хочется сделать красиво, а не можется
G>>Красиво это как? Нафигачить шаблоков?
G>>И как на плюсах сделать красиво IoC-контейнер?
O> да запросто, причем реализовывается с ограничение депенденси, при превышении даже собираться не будет
Ну код в студию.

G>>>>Такие выкрутасы с перегрузкой от бедности языка, а обилиле подобных "фич" только повышают возможность создать нифига нечитаемый код.
O>>> возможность перегружать это от бедности?
G>>Нет, примерение этой возможности — от бедности.
G>>В Boost даже зяпятую перегрузили потому что инициализаторов коллейкций не было. В C# таки догоадались включить эту фичу.
O> ах в бууст даже запятую перегрузили .. ты меня реально утомил. Плюсы на столько гибкий язык, что позволяет имлементить реализации модифицирующие синтаксис, да еще и чик __asm и ты уже там . А тебя это раздражает Да
Если каждый начнет "имплементить реализации" (шибанутое словосочетание) модифицирющие синтаксис, то будет попа. Код станет абсолютно нечитаемым.

O> Ком нужен для определенной специфики, чтобы мегатяжелые менеджед грабли таки могли получить быстро работающий код, или код, который может дернуть то, чего ну никак не дернуть из менеджед , или просто попытаться избавить себя от гемороя мегатомных импортов. А для реализации прослоек используется менеджед си.
Это ты сам себе придумал? Из C# отлично дергаются нативные методы, да нужны они очень редко, а работа с комом происходит гораздо проще.

G>>>>За последние 5 лет какое развитие было?
O>>> фреймворки ж)
G>>Мы про язык\стандартную библиотеку.
O> опять за рыбу деньги, — фреймворк внесенный в стандарт становится частью языка. Просто понимаешь какая штука, за время своего существования плюсы стали академическим языком, просто так внести новый фреймворк, не так просто нужно доказать, что в этом есть необходимость.
Не отмазывайся.

Здравствуйте, gandjustas, Вы писали:

ГВ>>OK, теперь давай выясним, что такое "красиво". Желательный интерфейс набросаешь кратенько?
G>Угу. Есть метод Register, который заносит в контейнер пару (тип интерфейса, тип реализации), и метод Resolve, который по заданному типу интерфейса выдает объект нужного типа реализации.
G>Когда получится можно сделать так чтобы если тип реализации имеет конструктор с параметрами, то при создании объекта в параметры конструктора подсчтавлялись бы объекты полученные через Resolve.

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

class IoC_Container
{
  public:
    template<typename I_, typename T_>
      void Register(){...}

    template<typename I_>
      I_ *Resolve(){...}
};

Не уверен, насколько надёжной может быть реализация Resolve в смысле параметров, но это только "пока что не уверен".

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

ГВ>>И как это опровергает сказанное мной? Что если фича реализована средствами языка — это не недостаток самого языка?
G>Если фича востребована, а реализация делается через непонятно что. причем за много лет в самом языке это не было исправлено, то это однозначно свидетельствует о недостатке языка.

В лучшем случае, это свидетельствует о недостатках процесса управления разработкой языка. Мало ли какие фичи могут оказаться востребованными?

ГВ>>Вопросы были риторическими. Иными словами, на самом деле проблем с совместимостью и интероперабельностью хватает у всех, так что выпячивать аналогичные недостатки C++ как некие особенные тут нет никакого смысла.
G>На самом деле проблем нету, потому что все описанное является только потенциальными проблемами и очень редко встречается в жизни. Тогда как интероп между C++_ными библиотеками встречается часто.

Как ни странно, но даже это вполне объяснимо количеством производителей компиляторов. В отличие от той же Java и тем более — от .Net. Кстати, заморочки с переносом кода между .Net и Mono, AFAIK, имеют место быть.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>С другой стороны, в самом по себе паттерне IoC ничего запредельного нет, мне сейчас любопытно поиграться в тех ограничениях, которые ты предложил.
Удачи. Учти что ни одной толковой реализации IoC-контейнера на C++ с конфигурированием в рантайме нету.
Я видел только решения с precompile-time кодогенерацией.

ГВ>>>И как это опровергает сказанное мной? Что если фича реализована средствами языка — это не недостаток самого языка?
G>>Если фича востребована, а реализация делается через непонятно что. причем за много лет в самом языке это не было исправлено, то это однозначно свидетельствует о недостатке языка.
ГВ>В лучшем случае, это свидетельствует о недостатках процесса управления разработкой языка.
Наличие надостатков в управлении разработкой веде к недостаткам в самом языке.

ГВ>Мало ли какие фичи могут оказаться востребованными?
Есть другие языки, достаточно смотреть по сторонам и думать головой.
Кстати разработчики C# сейчас демонстрируют обратный паттерн поведения, и мне реально иногда становится страшно за будущее шарпа.

ГВ>>>Вопросы были риторическими. Иными словами, на самом деле проблем с совместимостью и интероперабельностью хватает у всех, так что выпячивать аналогичные недостатки C++ как некие особенные тут нет никакого смысла.
G>>На самом деле проблем нету, потому что все описанное является только потенциальными проблемами и очень редко встречается в жизни. Тогда как интероп между C++_ными библиотеками встречается часто.

ГВ>Как ни странно, но даже это вполне объяснимо количеством производителей компиляторов. В отличие от той же Java и тем более — от .Net. Кстати, заморочки с переносом кода между .Net и Mono, AFAIK, имеют место быть.
Не имеют, надо только уметь готовить.
Специально поставил второй моно, написал на нем Winforms прогу, не используя mono-scecific библиотеки, и она запустилась под .NET без перекомпиляции.
Если хочется переносимости — надо использовать переносимое подмножество библиотек, это аксиома для любого языка.

Здравствуйте, shrecher, Вы писали:

S>Эти твои утверждения протеворечивы. Тут только одно из двух: либо престанут разрабатывать на C++, что мало вероятно, т.к. очень много продуктов на нем, тогда да — c++ таланты исчезнут; либо, что более вероятно, продолжат разработку и развитие продуктов на C++, и тогда без людей не обойтись.

Если массовым софтом считать софт о котором слышали(или щупали) 20% от общего числа юзеров в мире. Над разработкой такого софта трудится видимо меньше 1% от общнго числа программистов. Кому хочется в этот 1% видимо стоит ориентироваться на С++. Хотя, для опытного разработчика знание языка это вобще то мелочь, нужно на порядок больше чем просто знание языка и нескольких небольших универсальных библиотек.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, ollv, Вы писали:

O>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, ollv, Вы писали:

O>>>>Здравствуйте, gandjustas, Вы писали:

G>>>>>Здравствуйте, ollv, Вы писали:

O>>>>>> Кроме того, на плюсах вполне реализуемы элементы не родственных стурктур, к примеру итерации for_each, find_if count_if, функторы, придают плюсам оттенки функциональных языков
G>>>>>ржунимагу. шаблоны позволяют сделать то что уже есть в других языках
O>> ну посмейся, может в процессе придет понимание того, что в с++ есть возможность сделать то, чего нет в других языках, и есть возможность сделать подобие того, чего в нем изначально не было, и есть в других.
G>Ну тогда в студию GC, с такими же performance характеристиками, как в managed.
нахрен он нужен если есть шаред птр? чтобы морочить себе голову вызовом принудительной сборки для попытки освободить ресурс в прогнозируемое время

O>>И это при том, что в нем можно работать как в менеджед, так и в анменеджед,
G>Это не является преимуществом.
G>У unmanaged вообще говоря достаточно мало преимуществ.
ты совсем ляпнулся или как ? Код по работе из менеджед с МАПИ? (даже не пытайся, по твоим суждения видно что ты не доганяешь принципиальной разницы диспатч саппортинга )

O>>Сравнивать же менеджед и анменеджед — изначально бредово, т.к. если идет сравнение возможностей, то последние молчат при необходимости работы с МАПИ и библиотеками с ансаппортным диспатч и т.д.
G>.NET умеет работать с COM.
: насмешил мои тапочки очередной раз ..ну подними IUnknown

O>>>>>>но вообще метапрограммирование видоизменяет плюсы, а говорить, что это все можно реализовать в джава или дотнете — просто не знать плюсы
G>>>>>Рассказываю тайны, большенство программистов на C# достаточно долго программили на плюсах и отлично его знают.
G>>>>>А вот наоборот — редко бывает.
O>>>> пустые слова, шарп расхолаживает
G>>>Чего расхолаживает?
O>> Ощущение , что попал в песочницу с необходимостью постоянно в случае невозможности рыть совочком, прыгать опять за забор или через импорт апишных методов, или чз написание дополнительных утилзов на сях
G>Ты неверное в другом мире живешь.
G>Сколько я проектов сделал на .NET необходимость в вызовах нативных методов возникала раза два.
G>Неверное это от твоего незнания библиотеки.
Ха, какой библиотеки если есть области для которых менеджед код не имеет библиотек, МАПИ — это лишь одна — совсем малая из них. Ты что до сих пор не понял, роль менеджед Си?

O>>>>>>Даже простейший вызов из темплейтного метода непредопределенного класса с оператором () — уже недостижимая мечта для шарпа или жавы.
G>>>>>Включай моз, для чего нужно переопределение скобок? Чтобы объект вел себя как функция, а это значит что возможностей функций не хватает.
O>>>> Преопределение скобок — это лишь перегрузка одного из операторов, и все, а то, что это получило свое развитие это отдельная история, но основа опять таки не в этом,
G>>>А в чем? Зачем скобки переопределять надо?
O>> ты изначально поставил глупый вопрос, нафига в нете делегаты, что методов мало ?
G>Делегаты можно считать навороченным "указателем на функцию", так как в .NET сам методы не являются FCO.
G>А в C++ не было ни делегатов и ФВП, были только указатели на функцию, которые как и все указатели наделены родовыми травмами.
G>Перегрузка скобок дает возможность делать что-то издалека похоже на делегаты .NET или ФВП, в остальном такая перегрузка нафиг не нужна.
Да нифига, си благодаря своей гибкости () позволяет реализовать то, что есть в других языках без изменения самого Си , функторы появились зодолго до делегатов, — , которые в принципе ничем не отличаются от указателя на функцию, кроме оверкодинга в декларации.
идиома mem_fun и bind это гораздо более широкое понятие, чем делегаты именно благодаря позднему связыванию, когда
декларации вида:

class _1call 
{
  public:
  tempate <typename T> 
     void m(T val) {}
};

class _2call 
{
  public:
  tempate <typename T> 
     void m(T val) {}
};
...
task<_1call, task<_2call > > t (bind(&_1call::m<dyadya_vasya>), task<_2call, task<_3call >... >... );

//вызовется в последствии
_1call owner;
  t(owner)(dyadya_vasya);

с возможностью биндить как аргументы, так и владельцев, так и чуваков как ты, для обучения тому, что сранивать языки менеджед и анменеджед — глупо, только потому, что у каждого своя роль и преимущество. Что надо писать на лиспе, что-то на прологе,
К примеру анменеджед нельз использовать в том-же ком+. Так чтобы подвеситься на события некоего приложения ханделером через ком+ надо юзать менеджед. А чтобы дергать ком без поддержки диспатч надо юзать анменеджед. Только вот если говорить о синтаксисе, конечно каждый сам себе хозяин — но лично мне ближе плюсы.

O>>>>биндинг в плюсах покрывает делегаты, а вот обратного нет, т.к. теже функторы это лишь одно из множества, и не потому, что не хватает, а потому, что еще и так можно.
G>>>Это о чем? Какие делегаты, биндинг, функторы? Вывалил все умные словка, которые знаешь?
O>> А ты подумай немного, ..как реализовывать late fastening в дотнете ? Когда конструирование аргументов, владельцев методов, и создание каскада вызовов разведено во времени? — никак. а через поздний биндинг это решается.
G>Ты вывалил все оставшиеся слова, которые знаешь? Покажи пример кода на С++.
тебе какой? иди бусты ревьювь, там каждый второй шаг — недостижимая мечта для менеджед языков.
да прочти констрейны для задачи поведения при сборке хотя бы, я там выше пример привел — такое на шарпе и еже с ним не изобразить. И замечу, к слову о абстракции на момент имплемента класса, параметр шаблона чистая абстракция, и вызовы от него в том числе, в отличие от шарпа, где надо указывать кто должен быть чем

O>>>>т.к. хочется сделать красиво, а не можется
G>>>Красиво это как? Нафигачить шаблоков?
G>>>И как на плюсах сделать красиво IoC-контейнер?
O>> да запросто, причем реализовывается с ограничение депенденси, при превышении даже собираться не будет
G>Ну код в студию.
денег давай будет — а пока можешь уже готовые решения посмотреть , а они есть ..

G>>>>>Такие выкрутасы с перегрузкой от бедности языка, а обилиле подобных "фич" только повышают возможность создать нифига нечитаемый код.
O>>>> возможность перегружать это от бедности?
G>>>Нет, примерение этой возможности — от бедности.
G>>>В Boost даже зяпятую перегрузили потому что инициализаторов коллейкций не было. В C# таки догоадались включить эту фичу.
O>> ах в бууст даже запятую перегрузили .. ты меня реально утомил. Плюсы на столько гибкий язык, что позволяет имлементить реализации модифицирующие синтаксис, да еще и чик __asm и ты уже там . А тебя это раздражает Да
G>Если каждый начнет "имплементить реализации" (шибанутое словосочетание) модифицирющие синтаксис, то будет попа. Код станет абсолютно нечитаемым.
на этой попе, простите, сидит весь NET

O>> Ком нужен для определенной специфики, чтобы мегатяжелые менеджед грабли таки могли получить быстро работающий код, или код, который может дернуть то, чего ну никак не дернуть из менеджед , или просто попытаться избавить себя от гемороя мегатомных импортов. А для реализации прослоек используется менеджед си.
G>Это ты сам себе придумал? Из C# отлично дергаются нативные методы, да нужны они очень редко, а работа с комом происходит гораздо проще.
Опять смешишь тапочки, ? создай в шарпе натив экземпляр и вызови от него метод.

G>>>>>За последние 5 лет какое развитие было?
O>>>> фреймворки ж)
G>>>Мы про язык\стандартную библиотеку.
O>> опять за рыбу деньги, — фреймворк внесенный в стандарт становится частью языка. Просто понимаешь какая штука, за время своего существования плюсы стали академическим языком, просто так внести новый фреймворк, не так просто нужно доказать, что в этом есть необходимость.
G>Не отмазывайся.
Это не отмазка, изучи историю написания MFC-шных листов и прочего, почему это делалось ? До того как шел в использование стл, после появления стл необходимость в этих листах отпала. Что же касается нета, то там все иначе, пока корпорация не разродится на патч все дышут веником.

Здравствуйте, kochetkov.vladimir, Вы писали:
MK>>Сначала Дворкин меня задалбывал этим предсказаниями чего там будет через 10-20 лет, теперь вот ты

KV>Не-не-не, он в конце-концов сдался и написал, что "конца С# не будет и никуда он не денется" Re: Сишарпкапец наступает

Автор: Pavel Dvorkin
Дата: 10.03.09

А какие проблемы ... даже если он изчезнет. Многие С# программисты с удовольствием с ним попрощаются если будет предложено что-то еще более эффективное. К ЯП понятие верность "неуместно". Только вот к тому времени на С++ будут еще меньше писать.

Вобще-то новинки вводят для того чтобы производительность труда программистов повысить. Не хочется не изучай. И вобще-то в C# (как языке) все новинки которые были — совсем мизерные в плане их изучения (2-3 дня) но не по полезности мизерные. Так что ворчать по поводу изменений стандарта С# вобще неуместно. ... Если меняются библиотеки это уже другое дело...