Re[14]: откуда такая нелюбовь к нативному коду? - Компьютерные священные войны

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

M>Новые языки программирования растут как грибы после дождя. Старые набирают комьюнити. На вскидку популярные языки, которые на слуху: C, C++, C#, Java, VisualBasic, PHP, Python, Perl, JavaScript, lisp, scala, Deplhi, erlang, D, Dart, ObjectiveC, ActionScript, Lua, Ruby — какие-то из них мало используются (D), но всё равно на слуху. Так вот, большинство из этих языков интерпретируемые или компилятся в свой байт-код, нативный код из коробки дают C, C++, ObjC, Delphi, D и всё. Почему так мало языков, которые компилятся в нативный код?

Потому что "не нужен"?

Вот есть скрипт на перле/баше/питоне — и нафига ему компилиться в машкод? Что ты от этого собираешься выиграть?
Если нужна скорость, то ее можно достичь в любом тормозном языке через вызов частей, которые пишутся на нативных языках (но только они в нейтив и пишутся!).
Тот же питон — дичайшее тормозилово, но его можно (сюрприз!) использовать в научных вычислениях, потому что есть нативные библиотеки, написанные на Си, которые делают все быстро (NumPy、SciPy), а скриптовый язык просто предоставляет клей, которому нафиг не нужно быть супербыстрым и уж тем более компилиться в машкод. Тот же матлаб, те же игры, те же редакторы — начинка вся нативная, но логика на тормознутом скрипте (Matlab Script, Mathematica, Lua, eLisp, Autocad Lisp, VBA, из еще более высокоуровневых — Visual Basic, PowerShell, unix shell), и всем хорошо, и все довольны.

А нативщикам остается писать начинку, которой будет рулить какой-нть скрипт, и этот скрипт предоставит удобный и прозрачный DSL для решаемой задачи.
И это хорошо.
И пусть таких языков будет больше — людям жить будет легче, и программить смогут даже админы (перл, питон), которым для их поделок нафиг не нужны вяские петтерны и прочие радости "настоящего" программирования.

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

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

M>Новые языки программирования растут как грибы после дождя. Старые набирают комьюнити. На вскидку популярные языки, которые на слуху: C, C++, C#, Java, VisualBasic, PHP, Python, Perl, JavaScript, lisp, scala, Deplhi, erlang, D, Dart, ObjectiveC, ActionScript, Lua, Ruby — какие-то из них мало используются (D), но всё равно на слуху. Так вот, большинство из этих языков интерпретируемые или компилятся в свой байт-код, нативный код из коробки дают C, C++, ObjC, Delphi, D и всё. Почему так мало языков, которые компилятся в нативный код?

Нативные языки по своей природе ограниченны, потому что упираются в нижележащие
возможности архитектуры и операционной системы. Плюс некоторый "сахар" в виде
языковых средств (шаблоны в С++) и набора библиотек, но не больше.
Концепция компилируемых языков во многих отношениях свой ресурс исчерпала и дальше
двигаться просто некуда. Новые задачи не решаются совершенствованием компилятора и
добавлением новых библиотек.

Другие языки опираются на некий промежуточный слой (рантайм), который может
быть спроектирован более гибко и продуманно, с учетом специфики целевой области.
И он, как правило, предоставляет потенциально очень интересные и полезные возможности.
Например, динамическая генерация типов, позволяющая конструировать и использовать
объекты, информации о которых не было на стадии компиляции. Такой объект можно
сконструировать из данных, переданных, скажем, по сети с другого конца света.
Компилируемые языки отдыхают.

Да и смысл в компиляции иногда никакой.
Представьте, что если каждый bat-ник или сценарий WSH нужно было предварительно
скомпилировать с определенными настройками среды, и только после этого выполнять.

Еще один фактор — кросс-платформенность. Которую многие компилируемые языки
обеспечивают только на уровне исходного кода, да и то с массой "если" и "но".

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

Вот и получается, что выгоды очевидны, а минусы, если они вообще есть, несущественны.

P.S.
Да и потом, зачем нам еще один C++ ?

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

S>Там уже больше 20%:

Ты серьезно ?

Вот сейчас простой эксперимент сделал. Открыд LibreOffice Writer (у меня нет Word), в нем открыл некий pdf, из него вырезал первую страницу и вставил в новый документ. После этого просто запустил некий jpg, он открылся в Photo Editor, там я сделал Copy и вставил эту картинку в новый документ. После этого документ сохранил и открыл заново. Все нормально, заняло секунд 20.

Делаем то же в этом самом Word Web App.

Загружаю файл. Он отправляется, жду секунд 15. Появился.
Открываю его. Появляется окно с pdf viewer (а это, между прочим, нативный плагин) и загружается. Тоже секунд 15
Вырезаю страницу и копирую.
Черт возьми! Я этот pdf открыл просто щелчком, поэтому в том же окне. Ладно, Back
Открываю документ. Хочу вставить. нет, сначала надо "Редактировать в броузере" (а я где, спрашивается?). Ладно, жму
Вставляю из Clipboard. Почему-то не та кодировка, так что прочитать ничего нельзя. Ладно, простим.
Хочу добавить фотографию. Добавляю. Отсылается на сервер, еще секунд 10. Наконец появляется и встает по месту курсора. А я не там хочу! Пытаюсь сдвинуть мышью. Черта с два. Пытаюсь сжать по горизонтали (в офисе без проблем). Тоже черта с два.
Нажимаю в офисе правую кнопку на фотографии. Тут впору горькими слезами заплакать. И Flip там, и Crop, и поля задать, и Alignment, и Bring To Front / Send To Back и чего там только нет. А в Web все, что есть — это "Вырезать" , "Копировать" и "Вставить".

Я уж не говорю про VBA приложения для Office.

Так что извини. До standalone редактора тут очень далеко. Я не спорю, это несколько лучше, чем какой-нибудь js редактор из какой-то cms, но до Word очень далеко.

А всем этим графическим редакторам до Фотошопа — как до другой галактики.

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

I>>Ага, "я освоил потому проблем нет" зато бОльшая часть людей валится на собеседованиях именно из за этих указателей.
_>Ага, вот пусть эта большая часть людей дружным строем марширует в сторону менеджет.

Если честно, то для человека, не осилившего указатели до уровня среднего собеседования по плюсам, у меня очень плохие прогнозы и для менеджед. Как минимум, это 100% означает, что человек не понимает(и так же с трудом будет понимать), как работает выделение памяти и ее сборка в менеджед, что может привести к нехорошим последствиям, особенно в нагруженных проектах.

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

I>При том, что менеджет как правило не использует указатели. У многиъ программистов хронически не получается использовать указатели, софт тупо не взлетает или глючит.
Не волнуйся ты так, этих криворучкек выпинывают с работы и они идут говнокодить на managed.

I>Эти же программисты худо бедно но рожают менеджет решения
Да да. Наши говнокодеры уже все у вас. Что изрядно улучшило стабльность native софта.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

M>>>Ну дык. Указатели старательно упаковывают в GC для бедных — auto_ptr, shared_ptr и прочая *_ptr
BBI>>Это не GC ни разу. Это RAII.

M>Выделено.

M>>> чтобы не дай бог кто-то не использовал голые указатели.
BBI>>Отнюдь. Основная причина: упрощение управления времени жизни объекта. Уменьшение рукопашной.

M>А что GC, по-твоему, делает с точки зрения программиста? ВНЕЗАПНО упрощает управление временем жизни объекта. Уменьшает рукопашную. Но GC — это зло, а вот все остальное — это добро, агаага

Люди, ни разу не писавшие на языках с деструкторами и RAII, под временем жизни объекта понимают несколько другое, нежели люди, активно использующие RAII. Поэтому им не понятно, что GC НЕ упрощает управление временем жизни объекта в понимании С++. В плюсовой программе удаление одного объекта-хозяина часто приводит к целому каскаду событий, как-то закрытие файлов, сокетов, изменение имперсонации (логаут пользователя с точки зрения операционной системы, например) и .т.п. В языках с GC все эти действия приходится продумывать отдельно от управления памятью. Сложно назвать это упрощением.

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

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

I>>>Глючат. Но таких проблем с указателями и близко нет.

L>>Проблем с указателями не бывает. Бывают проблемы с программистами, их ниасилившими и их кодом.

I>Это абсолютно несущественная разница. Если прогарммист не осилил указатели, то эта особенность указателей проявится во всех фрагментах его кода.

Нет, разница существенная. Ниасиливший простейшую концепцию контроля за ресурсами программист банально профнепригоден. Управляемые среды просто услужливо заметают следы его факапов под ковер. Обычно прокатывает, но бывает и так, что проблема вылезает. Как правило, на терминальной стадии.

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

O>Нативные языки по своей природе ограниченны, потому что упираются в нижележащие
O>возможности архитектуры и операционной системы.

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

L>Зато бывают баги, вызванные кривыми руками и мозгами, ниасилившими ручное управление ресурсами и продуманную архитектуру. Ну и, в качестве привета из каменного века, так всеми любимое переполнение буфера, которое в нынешнем С++ нужно еще постараться устроить.

Ну дык. Указатели старательно упаковывают в GC для бедных — auto_ptr, shared_ptr и прочая *_ptr, чтобы не дай бог кто-то не использовал голые указатели. Можно поискать по форумам. Как только кто-то заикается про указатели, его всем форумом начинают бить канделябром за неиспользование *_ptr. Но при этом продолжают всем рассказывать сказки про то, что от указателей проблем нет

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

I>>>Неудовлетворительно. Если нет низкоуровневой фигни, то обычно дешевле перевести на менеджед.
_>>Странно что такой проект дожил до возраста легаси. Но чего в жизни не бывает.

I>ничего странного, жизнь проекта определяется не количеством багов, а размером бюджета. Если бизнес считает, что N млн долларов в год это не деньги, то проект будет жить до тех пор, пока затраты не превысят это N.
Ну не знаю.

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

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

E__>>Хм. Насколько промежуточный жабовский язык поход на ассемблер х86? Практически никак. И тем не менее, в общем случае падение производительности не такое и большое.

PD>Смотря на чем. Для матричных операций я получил 2-3 раза.

Про числодробилки — да. Но и тем не менее не в 30 раз, как для Питона. И то, виртуалки совершенствуются. Несмотря на различную идеологию байткода и нативы. Кстати, ты использовал интерпритатор, или же версию с JIT? Это очень важно, ибо последняя может увеличить производительность после компиляции числодробилки в нативу в 2-15 раз.
А еще есть управление памятью. Которое очень сложный вопрос. В приложениях типа веба — шах и мат нативе. Тут много факторов. И быстрая работа ГЦ при сборе юного поколения объектов(а при обработке запроса все туда попадают), и быстрейшее выделение памяти в жабошарпах(передвинуть указатель это быстро), и раздельность потоков(непойманное исключение в жабошарпах ложит текущий поток обработки с записью в логи, в плюсах — весь сервер; в жабе еще и чекед исключения убирают трясун типа "а вдруг что-то пойдет не так" — всегда знаешь, что именно может пойти не так, а рантайм исключения — это крах в 99% случаев, там по-другому решать надо).

А реальные приложения вообще забавные. Мы тут замеры производили... Я офигел с самописного теста(пытался делать не особо однородный, получился такой говнокод, что самому страшно) — коре2дуо(2х2.2) проигрывает феному 1100(6х3.3) в однопоточке в 6 раз, выигрывает в многопоточке в 4 раза(как?), а новехонький топовый бульдозер от амд проигрывает в 8 раз феному по обоим тестам. И это тест за 20 минут написанный от фонаря. Реальные приложения еще труднее в оценке.

>>Плюс, JIT не стоит на месте, а очень даже развивается. А компилять код, зная контекст и аппаратное окружение, можно куда эффективнее, чем "для общего случая".

PD>Для обычного компилятора время не критично, и если проект компилируется минуты — переживем. JIT это себе позволить не может. Поэтому обычный компилятор может устроить какие угодно межмодульные оптимизации, в принципе его связка с линкером может перестраивать и оптимизировать код как угодно. JIT не может, по этой причине. Поэтому его развитие ограничено сложностью алгоритмов оптимизации — начиная с некоторой сложности, банально не хватит времени.

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

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

I>>>Показал. вам, сиплюсникам, надо определиться. Или проблем с указателями нет, тогда не ясно зачем вам valgrind, или...
L>>Если ты не сиплюсплюсник, то что ты к указателям прицепился?

I>Я занимаюсь в т.ч. набором
А, ну теперь понятно почему у вас нормальных С++сников нету.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

PD>>ПО, которое продается в тысячах и миллионах копий, как писали на нативных языках, так и пишут. ПО, которое делается на заказ, как писали раньше на Бейсике, так и пишут сейчас на его духовных наследниках.
BS> Не скажите. Тиражные вещи также пишутся и не на нативном коде. Даже для программистов. Например ide от jetbrains. Просто увеличивается отношение объем задачи / время, затраченное на выполнение этой задачи. Поэтому там, где есть смысл пожертвовать временем машины — жертвуют. Там, где нет, — нет. немножко кэпствую, простите.

Я не спорю, что такие программы есть, но их процент ничтожно мал. Кстати, могу еще один пример привести — Visual Studio IDE, начиная с 2003. До сих пор с тоской вспоминаю VS6 — она летала на тогдашних машинах, а эта тормозит на нынешних, и памяти жрет неимоверно больше. А возможностей (для С++) добавилось хорошо если процентов 50.

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

JB>Да нет. Изменилось. ПО, распространяемое миллиардами копий, написано на html и прочих javascipt'ах. Добро пожаловать в интернет.

Спасибо за приглашение

. Остается подождать, когда это ПО будет по функциональности обеспечивать хотя бы 20% от того, что делают серьезные пакеты , написанные на нативном коде. Когда появится нечто похожее на Фотошоп, Автокад, Ворд и т.д. Вот тогда я готов буду принять, что подобное ПО можно писать не на нативных языках.

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

I>Глючат. Но таких проблем с указателями и близко нет.

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

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

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

O>>Нативные языки по своей природе ограниченны, потому что упираются в нижележащие
O>>возможности архитектуры и операционной системы.

M>Угу. А управляемым языкам доступны возможности квантовых вычислителей и бесконечная память.

Нет, ты не понял. Просто управляемые языки пока еще не настолько совершенны, чтобы упереться в ограничения железа и ОС. Когда-нибудь, возможно, они подтянутся к этому уровню, но пока — увы и ах.

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

Ф>>Ну и при чём здесь нативный/не нативный?
I>При том, что менеджет как правило не использует указатели. У многиъ программистов хронически не получается использовать указатели, софт тупо не взлетает или глючит. Эти же программисты худо бедно но рожают менеджет решения
Ты считаешь это хорошо? Ты считаешь, что непонимание одной из базовых концепций не то что программирования, а вообще — функцинирования компьютеров — это нормально для разработчика? Это отстой. Такие программисты и в managed нафиг не нужны, потому что на выходе все-равно получается хрень. Реальная отдача от подобных "разработчиков" — головная боль для вменяемых программеров, которым рано или поздно, но приходится переделывать глюкалово, написанное без подключения головы.

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

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

M>>В нативных Segmentation fault получить. Заметно проще, учитывая наличие почти во всех них Null Pointer'а. Есть исключения вроде Eiffel если не ошибаюсь, но они нафиг никому не нужны. В явах NPE получить тоже не проблема, но там хотя бы красивая трассировка стека будет вместо всяких "память не может быть read"

E__>В явах/шарпах еще, что очень важно, при почти любой ошибке максимум свалится текущий поток, а не все приложение. Если потоки практически независимы(а это именно так в подавляющем большинстве веб-приложений), то другие треды просто не заметят падения собрата. В тех же плюсах непойманное исключение в любом потоке ложит весь сервер.

Поэтому элементарное try-catch(...) в главной функции потока нормальные программеры ставят, не задумываясь, и горя не знают

А уж если нормальный С++ использовать (типа буста или C++11), то там вообще проблем нет, так как функция потока передается в виде boost/std::function, и ее вызов можно автоматом обернуть в try-catch(...) прозрачно для программера.
Это даже не говоря о том, что в С++11 предусмотрен механизм корректной передачи исключения из дочернего потока в родительский поток.

Причем обрати внимание, в С++ благодаря RAII рухнувший по исключению поток сразу же автоматически освободит все захваченные ресурсы (включая, например, локи мьютексов, открытые файлы/сокеты/соединения и т.п.).

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

I>Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.

дискредитировал себя не нативный код, а С'стайл в C++

http://www.cplusplus.com/reference/clibrary/cstring/strcpy/

(смотрим на название сайта)

--------------------------------------------------------
cpp — мутант переходного периода, и должен умереть

#include 
#include 

void process(char *str)
{
  char buffer[256];

  strcpy(buffer, str);
  printf("Длина строки = %d\n", strlen(buffer));
  return;
}

void main(int argc, char *argv[])
{
  if (argc == 2)
    process(argv[1]);
  else
    printf("Usage: %s some_string\n", argv[0]);
}

Пока будет C++, будут бесконечные патчи и вот такие апдейты.

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

L>>А я знаю. Зато я не знаю ни одного серьезного проекта на .NET, который бы по срокам не пролетел минимум в два раза. На нем же так просто и быстро разрабатывать!

I>Думаешь на С++ лучше ?

Думаешь? Я знаю. У нас сроки всегда выдерживаются.

L>>P.S. А эа выделенное в приличном обществе можно и канделябром огрести.

I>Это ж ты решил записать в профнепригодных людей, которые ошибки с указателями делают. Канделябр найдёшь или выслать ?

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

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

>>А баги они везде бывают, и нетовые программы тоже вылетают по ексцепшинам и бывает что память и них течет, это просто менее заметно ввиду малого распостранения подобных программ на десктопе.

I>В с++ коде есть такой класс багов, как баги с указателями. В менеджет его нет. В остальном все одинаково.

Нет такого класса багов. В принципе. Указатель — это просто число, накосячить с ним не просто.

Зато бывают баги, вызванные кривыми руками и мозгами, ниасилившими ручное управление ресурсами и продуманную архитектуру. Ну и, в качестве привета из каменного века, так всеми любимое переполнение буфера, которое в нынешнем С++ нужно еще постараться устроить.

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

I>>Я никого не пугаю, а говорю то, с чем пришлось сталкиваться копаясь в древних проектах писаными кем попало.
_>Язык и библиотеки на месте не стоят.

Древние проекты не показатель имхо.

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

I>>Да ладно, тут двое утверждают что багов не бывает годами и что де проблема не в указателях а в руках

Кому из вас верить ?
_>В данном случае можете верить обоим. Большинство багов на свете происходят по причине либо кривых рук либо кривых мозгов. Ваш кэп.

Все баги происходят по причине человеческого фактора. Вообще все. Потому когда речь про проблемы вроде с указателями, очевидно, имеется ввиду зависимость от этого ЧФ, которая у указателей много выше, чем с другими механизмами вроде ссылок.
Это следует из того, что одни и те же люди не могут заставить взлететь проект на С++ хотя менеджед версия летает.

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

L>Ты продолжаешь показывать свое чудовищное непонимание вопроса. Тебе точно не стоит собеседовать кандидатов на C++.
L>"New не будет" означает, что сущность, ответственная за корректное удаление некоего объекта, его сама не создает. Этот объест ей передается в полное владение извне, в конструкторе. Сам же объект создается, к примеру, в фабрике.

Это ж целая инфраструктура и только для того, что бы правильно работать с указателями ...

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

I>Для управления внешними ресурсами есть IDisposable и это не имеет отношения к GC.

Кстати, как по мне, IDisposable гораздо удобнее в плане читабельности кода(_чужого_), чем какие-то там скрытые ссылки на внешние ресурсы внутри классов, которые неявно открываются, и столь же неявно закрываются. Смотришь на код — и точно видишь, что есть внешний ресурс, и видишь его цикл жизни явно. А не какой-нибудь класс blablaFile, который на деле может вообще оказаться сущностью в памяти, и не содержать в себе ссылки на системный ресурс.

PS жду не дождусь, когда в жабе такое же сделают. Бо конструкции try-finally ну черезчур громоздкие.

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

PD>>Спасибо за приглашение

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

E__>А еще есть управление памятью. Которое очень сложный вопрос. В приложениях типа веба — шах и мат нативе.
Ох блин, опять эти сказки...

E__> Тут много факторов. И быстрая работа ГЦ при сборе юного поколения объектов(а при обработке запроса все туда попадают), и быстрейшее выделение памяти в жабошарпах(передвинуть указатель это быстро)
Ага, проходили мы это. Читай примерно тут: Re[20]: Внимание, Java!
Чтоб на жабе более менее быстро работало надо ещё чуть ли не ручками подбирать правильные параметры. Но простенький proof of concept аллокатор даёт ту же скорость что и оттюненая жаба. И это ещё не брались за оптимизацию.
Так что не надо нам рассказывать про чудеса, их не бывает.

E__>, и раздельность потоков(непойманное исключение в жабошарпах ложит текущий поток обработки с записью в логи, в плюсах — весь сервер; в жабе еще и чекед исключения убирают трясун типа "а вдруг что-то пойдет не так" — всегда знаешь, что именно может пойти не так, а рантайм исключения — это крах в 99% случаев, там по-другому решать надо).

E__>А реальные приложения вообще забавные. Мы тут замеры производили... Я офигел с самописного теста(пытался делать не особо однородный, получился такой говнокод, что самому страшно) — коре2дуо(2х2.2) проигрывает феному 1100(6х3.3) в однопоточке в 6 раз, выигрывает в многопоточке в 4 раза(как?)
Шота у вас там у теста в консерватории явно не в порядке.

E__>а новехонький топовый бульдозер от амд проигрывает в 8 раз феному по обоим тестам. И это тест за 20 минут написанный от фонаря. Реальные приложения еще труднее в оценке.
Это просто бульдозер весьма, гм, своеобразный получился.

PD>>Для обычного компилятора время не критично, и если проект компилируется минуты — переживем. JIT это себе позволить не может. Поэтому обычный компилятор может устроить какие угодно межмодульные оптимизации, в принципе его связка с линкером может перестраивать и оптимизировать код как угодно. JIT не может, по этой причине. Поэтому его развитие ограничено сложностью алгоритмов оптимизации — начиная с некоторой сложности, банально не хватит времени.

E__>Зато обычный компилятор оптимизирует вслепую.
Компиляторы уже давным давно умеют PGO, так что не в слепую.

E__> А джит только то, что реально нужно, и у него точные данные про возможности именно этого проца.
А толку, всё равно хуже чем у компилятора получается.

E__> Причем обычным компиляторам уже очень много, а джит, по сути, на начальной стадии развития.
У тех кто делал jit были все знания, накомпленные за время развития компиляторов. Так что возраст тут роли особой не играет.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>>Читаем "в менеджед отсутствует целый класс ошибок, которых в принципе нигде нет". Ты ведь так и не показал нам, что это за ошибки, связанные с указателями.

I>Показал. вам, сиплюсникам, надо определиться. Или проблем с указателями нет, тогда не ясно зачем вам valgrind, или...

Если ты не сиплюсплюсник, то что ты к указателям прицепился? Все уже поняли, что ты их ниасилил, ну прошел бы дальше, так нет, и зудит и зудит. Чего тебе плохого указатели сделали?
Валгринд удобен тем, что позволяет ткнуть ниасиливших работу с памятью в их собственное дерьмо. А также полезен тем, что помогает выявить наиболее охочие до памяти участки с целью их оптимизации. Экономии памяти для.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Эй, осторожнее. В местных специальных олимпиадах я лидирую!
S>>

НС>Разве что в количестве сливов, тут ты, бесспорно, лидер с большим отрывом.
Нет, я просто свои вины никогда не считаю, не запоминаю и поэтому не показываю. Впрочем, как и сливы. Мне положить и на то и на другое.

В теории красиво и правильно. Согласен полностью.
Но вот от стыковки C# с C++ я удовольствие испытал весьма сомнительное.

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

LVV>Здравствуйте, monax, Вы писали:
LVV>1. Трансляция в виртуальную машину много легче, чем в реальную железную. Так как виртуальную машину можно сделать настолько удобной, насколько вообще можно.

Трансляции в виртуальную машину нет. Есть трансляция в машинные команды или промежуточный язык. Кстати, в промежуточный язык можно транслировать и нативный код — АЛМО напомнить ?

LVV>2. Коды виртуальной машины можно обрабатывать как угодно — от чистой интерпретации до чистой компиляции в нативный код.

И что ? Одно из двух : либо промежуточный язык будет достаточно близок к машинному, либо просядет скорость и существенно.

LVV>3. Опять же если компиляция, то ее можно выполнять самыми разными способами, хоть макроподстановкой.

?

LVV>4. Реализация виртуальной машины на другой платформе гораздо легче, чем реализация полноценного компилятора. Отвязываемся от зависимости по формату исполняемого файла.

Формат исполняемого файла по сравнению с собственно компиляцией и линковкой — мелочи и пустяки, маленький участок линкера переписать.

LVV>5. Виртуальная машина позволяет писать разные части системы на разных языках, собирая их потом без проблем.

И обычная тоже. Это вообще свойство языков, а не машины. Например, С и Pascal , С и Fortran -77 сопрягались без проблем, C++ и Object Pascal — уже с проблемами из-за разного подхода к реализации объектов.

LVV>6. Для виртуальной машины легко реализовать сопутствующие вещи: отладчик, профайлер — у меня студенты на лабах делают.
LVV>И сборку мусора проще реализовать — это важно для прикладного программирования. Ошибок с памятью меньше будет.

Это свойство языка, а не виртуальной машины. Вполне можно представить себе (да наверное и существует) язык с нативным кодом и сборкой мусора. Просто в нем не должно быть указателей.

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

LVV>>2. Коды виртуальной машины можно обрабатывать как угодно — от чистой интерпретации до чистой компиляции в нативный код.

PD>И что ? Одно из двух : либо промежуточный язык будет достаточно близок к машинному, либо просядет скорость и существенно.

Хм. Насколько промежуточный жабовский язык поход на ассемблер х86? Практически никак. И тем не менее, в общем случае падение производительности не такое и большое. Плюс, JIT не стоит на месте, а очень даже развивается. А компилять код, зная контекст и аппаратное окружение, можно куда эффективнее, чем "для общего случая".

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

PD>Ничего нового не произошло. То же самое было 10 и 20 и 30 лет назад. И тогда были программисты, которые писали на Фортране и С/C++, и программисты, которые писали на Бейсике. И вторых всегда было больше, чем первых.
PD>ПО, которое продается в тысячах и миллионах копий, как писали на нативных языках, так и пишут. ПО, которое делается на заказ, как писали раньше на Бейсике, так и пишут сейчас на его духовных наследниках.
Да нет. Изменилось. ПО, распространяемое миллиардами копий, написано на html и прочих javascipt'ах. Добро пожаловать в интернет.

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

I>>При том, что менеджет как правило не использует указатели. У многиъ программистов хронически не получается использовать указатели, софт тупо не взлетает или глючит.
BBI>Не волнуйся ты так, этих криворучкек выпинывают с работы и они идут говнокодить на managed.

I>>Эти же программисты худо бедно но рожают менеджет решения
BBI>Да да. Наши говнокодеры уже все у вас. Что изрядно улучшило стабльность native софта.

Кстати, кроме шуток, но, похоже, что это именно так и есть. В некоторой окрестности меня в С++ подразделении уже лет пять не слышно про расстрелы памяти, утечки или AV. Вместо них — стабильные и своевременные релизы, а баги все больше по функциональности (это когда оказывается, что в спек попало не совсем то, что юзеры имели в виду). Лепота.

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

I>>Глючат. Но таких проблем с указателями и близко нет.

L>Проблем с указателями не бывает. Бывают проблемы с программистами, их ниасилившими и их кодом.

Это абсолютно несущественная разница. Если прогарммист не осилил указатели, то эта особенность указателей проявится во всех фрагментах его кода.

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

I>>>Цитирую : "чисто для демонстрации"
_>>Хиленькая такая демонстрация, совсем не показывающая всей сложности использования чистых указателей.

Ошибка-то легко обнаруживается еще на этапе компиляции.

I>Очень даже показывает проезд по памяти. Представь, что p инициализируется неправильно.

Вот что мне нравится в подобного рода дискуссиях так это предложения представить какой-то там гипотетический случай.

Мне-то зачем что-то представлять? Это Вы тут пытаетесь напугать сообщество ужасными голыми указателями. Вот и подгоняйте достоверные примеры неуловимых багов на указателях. Лично меня убеждать не нужно, я и так знаю с какими реальными багами приходится сталкиваться, и неправильная инициализация указателя вообще не входит в список часто встречающихся и трудно уловимых. Вы ж упорно пытаетесь убедить меня в обратном тупым примером. Думаете получится?

Коллеги реально пишушие на плюсах вам уже неоднократно говорили что указатели не более чем жупел, и проблемы с ними сильно преувеличены. Никто не говорит что проблемы польностью отсутствуют. Но это далеко не самый тормозящий фактор в плюсных проектах. Прямой доступ к памяти это преимущество с/c++, причем иногда абсолютно необходимое. Опасно? Конечно, но есть опробованные лекарства. Не нужен прямой доступ к памяти — пишите на менеджет.

_>>>Прямой доступ к памяти это преимущество с/c++, причем иногда абсолютно необходимое.

M>>Преимущество по сравнению с чем?
_>С языками которые этого не позволяют.

Голословно. В чем это преимущество выражается?

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

M>Ну дык. Указатели старательно упаковывают в GC для бедных — auto_ptr, shared_ptr и прочая *_ptr
Это не GC ни разу. Это RAII.

M> чтобы не дай бог кто-то не использовал голые указатели.
Отнюдь. Основная причина: упрощение управления времени жизни объекта. Уменьшение рукопашной.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>GC тоже "упрощение управления времени жизни объекта. Уменьшение рукопашной."
G>Именно поэтому все "умные указатели" и называют "GC для бедных".

Ох уж эта псевдоэлитарность.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

I>>>>Начнем сначала. Сколько нужно времени что бы старом проекте на 50-100мб кода заменить указатели на смартпоинтеры и тд.

L>>>Нисколько, потому что это не нужно.

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

L>Да пусть борется хоть с ветряными мельницами. Если в конторе половина сотрудников по ночам вскакивает в холодном поту от одной мысли об указателях, а другая допускает существование глючного кода годами, то пусть подписывается на что угодно. Результат, впрочем, будет предсказуемым.

I>>>>такое ощущение что большинство адептов С++ в этом топике не в курсе про legacy код. раньше на с++ писалось очень много того, что сейчас пишется на менеджед средствах. Куда деть такой код ? Может назвать его несиплюсным ? это резко снимет проблему указателей

L>>>Я не могу, он нам сейчас еще и про легаси код рассказывать будет. Давай уже, жги!

I>>А есть что сказать более внятного ?

L>Внятного? Мы с тобой на разных язаках разговариваем, как я посмотрю. Вообще-то приличные люди легаси кодом называют модули, хоть и написанные во времена царя горооха, но при этом стабильные, как Египетские пирамиды.

Легаси это просто код, который достался тебе по наследтсву от другой тимы. Всё.

>Единственная причина, по которой его трогают — это когда расширение или изменение функциональности становится неизбежным. Но даже тогда с бОльшей вероятностью функциональность просто заменяют новым кодом из соображений однородности и простоты поддержки. Юнит-тесты, опять же.

Есть такие страшные люди, математики. Могут писать простыни по 100кб и более и им там все понятно. Кроме них этот код никто не понимает.

L>Говнокод, в котором есть "проблемы с указателями" (сиречь падает на ровном месте) шансов стать легаси кодом не имеет. Разве что в какой-нить внутренней тулзе в какой-нить ООО "Рога и копыта"

Это по малолетству так кажется.

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

I>Что бы его переписать, нужен точно такой же специалист, а это как правило всегда проблема.

На самом деле проблема в том, что этот специалист перепишет код такими же 100-километровыму простынями.

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

I>>>И так во всех отраслях, правильно я тебя понимаю ?

L>>Назови одну, в которой можно продавать глюкало, падающее на ровном месте и при этом не растерять всех клиентов.

I>Любая отрасль, где цена ошибки не равняется потере бизнеса или, скажем, человеческой жизни. Всех клиентов не нужно терять, достаточно потерять долю рынка, например перейти из лидеров в аутсайдеры.

ну если для бизнеса потеря доли рынка — фигня, то у меня вопросов нет. Только название конторы назови, штоб случайно не вляпаться.

I>Ты или читай внимательно, или спрашивай, что непонятно. Я не говорил, что "переписали на жабе". Была кучка проектов, часть плюсовых, часть — джава. Плюсовые вымерли. Джава осталась в строю. Плюсовые вымерли из за обилия проблем внутри кода — утечки, указатели, исключения.

Так а я то говорю? плюсы ниасилили, там же указатели и исключения, а от них утечки. Руки кривые, что поделать?

>>говрит лишь о том, что инструмент был изначально выбран неверно, а проект писали криворучки. Как говорится, дело было не в бобине.

I>"проект писали криворучки" — не ты ли чуть не пеной брызгал и доказывал что все плюсовики суть мега-продвинутые девелоперы у которых годами не бывает багов с указателями ?

Все плюсовики, с которыми мне приходится работать, именно такие. Вы там можете хоть на клавиатуре плясать, но заявлять про "проблемы с указателями", когда на самом деле вы просто ниасилили плюсы несколько самонадеянно. Много на себя берете.

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

L>>Математики пусть алгоритмы на доске мелком рисуют. писать программы должны программисты.

I>Многи ли ты можешь назвать специалистов по теории доминирования которые занимаются этим лет 15-20 ? Выбирать, как видишь, не из чего.

Пофигу. Дайте своим специалистам маткад или матлаб, пусть ваяют нетленку в них. А интергировать будете сгенерированный код. Если они специалитсы по теории, то пусть и занимаются своей теорией, а код пусть оставят профессионалам.

I>>>Это по малолетству так кажется.

L>>Слив защитан.

I>О, ты у Пацака подсмотрел такой аргумент ?

Переход на личности -> неадекват -> слив защитан.

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

L>>New, может, и не будет, но delete будет явный.

I>Что значит "New, может, и не будет" ? Предполагается логику слежения за инстанцами переложить на пользователя дерева ?

Ты продолжаешь показывать свое чудовищное непонимание вопроса. Тебе точно не стоит собеседовать кандидатов на C++.
"New не будет" означает, что сущность, ответственная за корректное удаление некоего объекта, его сама не создает. Этот объест ей передается в полное владение извне, в конструкторе. Сам же объект создается, к примеру, в фабрике.

>>Из недавнего — собственная реализация дерева без использования умных указателей. Из-за дикого размера дерева и дикого количества оных одно оборачивание детей в умный указатель давало оверхед по памяти мегабайт в триста. Выкинули умные указатели, обучили ноду дерева делать delete в деструкторе. Профит.

I>И получается, если дерево не будет инстанцировать объект, то пользователь обязан знать кишки, т.е. что деструктор нода разрушает элемент

Получается, что ты ничерта не понял. Дерево — это интрузивный контейнер в данном случае.

I>Вот такие решения и создают проблемы на ровном месте

Дадададд, там же УКАЗАТЕЛИ!! Галактеко опасносте!

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

I>>Естественно, капитан, в понимании С++ нет никакого GC

ТКС>Вообще-то есть. Некоторые их даже применяли.

Ты про МС++ что ли ? Или про возможность написания квази-gc под нативнй с++ ? Естественно, и то и то это отстой.

I>>Такие вещи и нужно продумывать отдельно. Не все сводится к удалению, закрытию и тд. Это только малая часть ворклфоу.

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

Вероятно удаление файла у тебя выглядит так:

DeleteFile(string fileName)
{
  DeleteFileOperation operation(fileName);

  // в деструкторе будет удаление файла прибитое гвоздями к управлению жизни объекта DeleteFileOperation
}

I>>В с++ никто не напишет за тебя корректный воркфлоу, а совмещение _некоторых_ действий с управлением памяти ничего существенно не меняет.

ТКС>Не "некоторых действий", а всего управления внешними ресурсами.

Покажи на примере простого удаления файла из пекаджа который представляет собой простой зип.

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

ТКС>Т.е., ты хочешь сказать, что RAII не работает и указанное тобой невозможно реализовать средствами RAII?

Представь себе xml-конфиг где прописывается сценарий работы с ресурсом...

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

I>>>>С++ нужен для низкоуровневого контроля ресурсов. В силу отсутствия плюсовиков, эти вопросы вынуждены решать на менеджед.
_>>>Получается?

На самом деле могу порекомендовать только одно, платите достойную зарплату и спецы сами к вам потянутся.

I>>Это лажа. Или ты считаешь, что количество сиплюсников в регионе резко увеличится если одна из контор даст им топовую ЗП ?

_>В конторе давшей топовою зарплату количество спецов несомненно увеличится. А регион сегодня чуть менее чем вся планета, попробуйте удаленнщиков нанимать.

Это только краткосрочный вариант. Я чет смотрю, конторы которые заманивают топовыми ЗП, очень быстро дохнут.

I>>Пару штук ты заманишь. Но если на проект нужно хотя бы десяток это сразу провал. И бюджет раскидаешь и наёмешь летунов.
_>Труба. Менеджет побеждает ввиду вымирания и деградации плюсников.

Токого я раньше не слышал. А учить коллег не пробовали?

Это что же, ты отказываешься от мега-способа — заваливания деньгами ?

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

ТКС>GC вообще отстой. Толку на три копейки, издержек на рубль.

Зато есть алгоритмы которые рвут с++ именно за счет ГЦ. Да-да.

I>>>>Такие вещи и нужно продумывать отдельно. Не все сводится к удалению, закрытию и тд. Это только малая часть ворклфоу.

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

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

Зато файл является внешним ресурсом, а у тебя сказано "легко прибить гвоздями к управлению временем жизни объектов и нет ни одной причины, чтобы разделять их".
Раз причин разделять нет, то удаление файла должно делаться в деструкторе какого то класса.

ТКС>>>Не "некоторых действий", а всего управления внешними ресурсами.

I>>Покажи на примере простого удаления файла из пекаджа который представляет собой простой зип.

ТКС>А чего тебе непонятно? Что файл в деструкторе закрывать уместно или что?

Вот пример:
"удаления файла из пекаджа который представляет собой простой зип"

Жду примера кода.

I>>Представь себе xml-конфиг где прописывается сценарий работы с ресурсом...

ТКС>Сценарии в xml прописывать — жосткий мазохизм, для подобных целей есть языки и поудобнее

Ты скромно ушел от ответа.

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

E__>Если честно, то для человека, не осилившего указатели до уровня среднего собеседования по плюсам, у меня очень плохие прогнозы и для менеджед. Как минимум, это 100% означает, что человек не понимает(и так же с трудом будет понимать), как работает выделение памяти и ее сборка в менеджед, что может привести к нехорошим последствиям, особенно в нагруженных проектах.

Более того, тут сыграет свою роль эффект заметания проблем под ковер: спецэффекты вылезут в тот момент, когда уже поздно будет пить боржоми.

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

I>Если честно, то твой пост по ссылке это порожняя реакция в ответ на порожняк на собеседования.

Так и скажи, что английский ниасилил.

I>Расшифровываю — ты уже в который раз обвиняешь меня в проблемах, которые появились задолго до того, как я и мои товарищи занялись проектом

Проблемы в основном с указателями, которые мне и моим товарищам пришлось исправлять денно и нощно.

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

I>Если вы сиплюсники такие все крутые и избранные, то откуда берутся убитые в говно проекты, на которых нужно учиться как нельзя пользоваться указателями ?

Очень просто — крутые сипоюсплюсники таовю контору игнорируют, а говнокод рожают те, кому следовало бы сидеть под теплым крылом managed и не отсвечивать.

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

L>>Так а я то говорю? плюсы ниасилили, там же указатели и исключения, а от них утечки. Руки кривые, что поделать?

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

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

I>Всё, поезд ушел, С++ превращается в лавочку "для своих".

Для избранных, если так тебе будет угодно.

L>>Все плюсовики, с которыми мне приходится работать, именно такие. Вы там можете хоть на клавиатуре плясать, но заявлять про "проблемы с указателями", когда на самом деле вы просто ниасилили плюсы несколько самонадеянно. Много на себя берете.

I>Ага, в старом проекте проблемы в коде за 5-7 лет до того, как я в универ пошел, и основная причина — что я сейчас чего то не умею ? А ты, логик, аплодирую стоя

Кто-нибудь, расшифруйте это, пожалуйста.

Why IL

Меня иногда спрашивают о том, почему мы выбрали именно эту стратегию; почему компилятор C# не может напрямую генерировать машинный код без дополнительного промежуточного этапа? Зачем нам нужны два компилятора для преобразования кода на языке C# в машинные инструкции, когда достаточно было бы одного?

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

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

___>Все эти ваши лекарства (хоть в прямом, хоть в переносном смысле) лечат следствия, а не причину.
Естесвенно. Одной и той-же рукой можно и поэмы писать и бить. Давайте отрубим нафиг руку ввиду потенциальной опасности

Причины вызывающее проблемы в нативном коде мне просто абсолютно необходимы в работе, от них я избавиться не могу. Я уже устал от подобного рода споров. Еще раз для всех опонентов : я не призываю писать все на свете на плюсях( хотя я в принципе и не против

, я всего лишь утверждаю что есть реальные задачи, за которые платят деньги, где без нейтива не обойтись. Ну самый тупой пример : Нужен плагин для оперы, фокса и хрома задействующий некие возможности npapi . Очевидный выбор иструмента — с, поскольку сам api сишный насквозь, и достаточно универсальный чтобы написать один код для всех трех браузеров разом.

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

M>А что GC, по-твоему, делает с точки зрения программиста?
Это другой подход к аллокации и освобождению памяти, только и всего.

M> ВНЕЗАПНО упрощает управление временем жизни объекта.
Там вообще другой подход к времени жизни объекта чем в не-GC аллокации.
Сравнивать GC и RAII обёртки как то странно, они из разных опер.

M> Уменьшает рукопашную.
Ну дык все автоматизированные методы работы с памятью уменьшают рукопашную.

Их жеж для того и делают.
Впрочем с GC рукопашной кое где становится даже больше, например там, где надо заpinить область памяти, дабы не дать GC её переместить.

M> Но GC — это зло, а вот все остальное — это добро, агаага
Нет, почему?
GC для одних целей хорош, другие способы работы с памятью — для других.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Новые языки программирования растут как грибы после дождя. Старые набирают комьюнити. На вскидку популярные языки, которые на слуху: C, C++, C#, Java, VisualBasic, PHP, Python, Perl, JavaScript, lisp, scala, Deplhi, erlang, D, Dart, ObjectiveC, ActionScript, Lua, Ruby — какие-то из них мало используются (D), но всё равно на слуху. Так вот, большинство из этих языков интерпретируемые или компилятся в свой байт-код, нативный код из коробки дают C, C++, ObjC, Delphi, D и всё. Почему так мало языков, которые компилятся в нативный код?

F>Такой принцип уже применили к промышленности, и теперь практически всё делается в Китае.

И что? Ну стоила бы вся техника в 5 раз дороже без Китая. Китай Китаю к томуже рознь. Там весь ценовой спектр есть от паленых кросовок Panasonik до iPhone 4.

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

PD>>Ну-ну. Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее. На С++ пока не переписывал. Там чистая матричная алгебра.

J>Ты эти пакеты используешь "голыми" или под ними что-то лежит?

Ничего не лежит. Консольное приложение на Питоне, формирует матрицы, вызывает NumPy и SciPy. Как библиотеки реализованы — не интересовался, просто скачал их и вставил вызовы.

Windows.

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

P>Позанудствую: я не смог прикрутить MS Fortran 5.0 к Borland C не то 2.0, не то 3.1, не помню. За исключением простейшего случая: в вызываемую порпрограмму на Фортране не передавалось никаких параметров. А вот MS C — без проблем. Там С- и фортрановские модули шли вперемешку, и все работало.

+1. Я тоже на Борланд не пробовал, а VC6 с Fortan Compaq скрестил без проблем. Благо и IDE одна и та же. Отлаживалось на ура : F11 и мы из С попадаем в Фортран.

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

LVV>>6. Для виртуальной машины легко реализовать сопутствующие вещи: отладчик, профайлер — у меня студенты на лабах делают.
LVV>>И сборку мусора проще реализовать — это важно для прикладного программирования. Ошибок с памятью меньше будет.

PD>Это свойство языка, а не виртуальной машины. Вполне можно представить себе (да наверное и существует) язык с нативным кодом и сборкой мусора. Просто в нем не должно быть указателей.
Точней голых указателей. Умные могут быть. Причем даже не проблема в плюсах сделать менеджер памяти такой как в шарпе : с моментальным выделением памяти и отсутствием фрагментации. Но тогда и при удаленее он будет временами надолго подтупливать запуская сборку мусора.

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

PD>До сих пор с тоской вспоминаю VS6 — она летала на тогдашних машинах, а эта тормозит на нынешних, и памяти жрет неимоверно больше. А возможностей (для С++) добавилось хорошо если процентов 50.

А ты запускал VC6 на Pentium-100 с 16M оперативы? Особенно после Developer Studio 4.0 (5-ю я пропустил). Шестерка, по ощущениям, тормозила неслабо по сравнению с четверкой. А сейчас, на DualCore c 2Г, летает, а 2010 — тормозит.

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

J>>За шарп не скажу, но сам я недавно сопрягал С++ с Питоном (а лет 15 назад — с Tcl), особых проблем не заметил, кроме детских проблем самого питона (многопоточность — это смерть, лучше ею не пользоваться в питоне вообще) + его специфические вещи типа счетчиков ссылок.
J>>Но тут, конечно, Boost.Python сильно выручает, с ним очень приятно все программить.

M>Хз-хз. У меня был негативный опыт года 3 назад. Кроме Буста ещё SWIG пробовал. Всё равно геморроя куча.

Я тоже пробовал и SWIG, и буст. К свигу я больше на пушечный выстрел не подойду. А с бустом я особых проблем не испытывал.

M>Я вообще нормальный интероп видел только в связке Assembler->C->C++.
Ну, это интеропом сложно назвать

M>В остальных случаях игра не стоит свеч.
Ну здрасте. Типа не стоит свеч скриптование программы, лучше перекомпилировать на каждый чих, чем менять скрипты?
Посмотри на те же игры, в них же без скриптов никуда.

Плюс очень удобно питоном (и любыми другими скриптами, тем же VBA) тестировать свои компоненты в стиле "а если так?" — скорость тестирования на пару порядков возрастает по сравнению с написанием юнит-теста, требующим перекомпиляции на каждое плёвое изменение.

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

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

LS>Нет, ты не понял. Просто управляемые языки пока еще не настолько совершенны, чтобы упереться в ограничения железа и ОС.
LS>Когда-нибудь, возможно, они подтянутся к этому уровню, но пока — увы и ах.
что за ерунда. питон интерпретируемый? байт-код говорите? это у вас байт-код, а я юзаю транслятор питона в си, а си компилируется в машинный код. скорость существенно возрастает.

язык не знает о том какой он -- нативный или нет. можно написать интерпретатор си (правда непонятно зачем), а можно компилятор bat файлов. кстати, компилятор bat файлов во времена ms-dos существовал и пользовался популярностью (скорость возрастала в разы).

популярность управляемых языков (блин, какой неправильный термин) вызвана легкостью создания трансляторов. все прелести управляемых сред можно реализовать и в нативном коде. причем, более эффективно. например, если глобальный оптимизатор видит, что функция foo обращается к строкам по индексу _гарантированно_ не выходя за их границы, то проверки на этапе компиляции достаточно. если мы складываем a и b и язык гарантирует выброс исключения при переполнении, то компилятор опять-таки может прикинуть где переполнения гарантированно не будет, а где не избежать проверки в рантайме. а вот транслятор в байт-код будет тупить. т.к. исключение выбрасывает виртуальная машина при сложении и проверяет на переполнение при каждом вызове.

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

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

E__>Про числодробилки — да. Но и тем не менее не в 30 раз, как для Питона.

Конечно.

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

Python — интерпретатор, плагин к эклипсу для Python 2.7. Для Явы — эклпипс.

E__>А еще есть управление памятью. Которое очень сложный вопрос. В приложениях типа веба — шах и мат нативе.

Вот тут согласен, но частично. Шах и мат не нативе, а нативе с указателями. Натива может вполне быть без указателей и со сборкой мусора, а тогда никакого шаха и мата не будет. Дело не в нативе vs. управляемый код, а в наличии или отсутствии сборки мусора.

>(непойманное исключение в жабошарпах ложит текущий поток обработки с записью в логи, в плюсах — весь сервер;

Ну это совсем не обязательно, можно на С++ ловить необработанные исключения.

E__>А реальные приложения вообще забавные. Мы тут замеры производили... Я офигел с самописного теста(пытался делать не особо однородный, получился такой говнокод, что самому страшно) — коре2дуо(2х2.2) проигрывает феному 1100(6х3.3) в однопоточке в 6 раз, выигрывает в многопоточке в 4 раза(как?),

Что-то сомнительно. Надо смотреть, что за тест.

PD>>Для обычного компилятора время не критично, и если проект компилируется минуты — переживем. JIT это себе позволить не может. Поэтому обычный компилятор может устроить какие угодно межмодульные оптимизации, в принципе его связка с линкером может перестраивать и оптимизировать код как угодно. JIT не может, по этой причине. Поэтому его развитие ограничено сложностью алгоритмов оптимизации — начиная с некоторой сложности, банально не хватит времени.

E__>Зато обычный компилятор оптимизирует вслепую. А джит только то, что реально нужно, и у него точные данные про возможности именно этого проца. Причем обычным компиляторам уже очень много, а джит, по сути, на начальной стадии развития. Там еще непаханное поле, куда развиваться.

Там все равно очень мало времени на вспашку поля. Что же касается возможностей процессора, то это в принципе можно и для нативы сделать — не так уж их много. Другое дело, что практически не делают — так я и не уверен, что JIT делает.

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

I>>И потому глючат даже сишные проги и проги на дельфях всяких ?

Ф>И потому же глючат шарповые проги и проги на VBNet'ах всяких

Глючат. Но таких проблем с указателями и близко нет.

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

I>>Глючат. Но таких проблем с указателями и близко нет.

Ф>О!
Ф>Таки дошли/добрались до корня зла.

Я с этого и начинал. "Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.
"

Ф>Ну и при чём здесь нативный/не нативный?

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

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

I>>>Я с этого и начинал. "Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.
I>>>"

E__>>Еще в случаях, когда ресурсы ограничены. Если у тебя девайс с 64К оперативы(а таковых еще дочерта, на наш век хватит), то ни о каких жабошарпах речи нет.

I>Это как раз вписывается в "низкоуровневый контроль ресурсов". Низкий контроль нужен когда много всяких ограничений, объемы, скорость и тд и тд и тд при чем под эти ограничений нет готовых инструментов и все нужно делать руками.

Да нету там никакого контроля ресурсов(ну, кроме контроля модема через АТ команды, и принтера через POS), просто аккуратное написание кода на С, чтобы не вылезти за предел памяти. Учитывая, что графики нет, 64К хватает с головой.
А заказчики — люди, умеющие считать. Они лучше закажут девайс с 64К, слабым арм процом, но который прослужит годы, и не будет требовать зарядки каждые пару часов, чем.. Ну ты понял. А написать прогу я могу как под нативу, так и под Ведроид какой-нибудь, но это один раз. А девайсов нужно много, и желательно, чтобы они были долгоживущими во всех смыслах этого слова.

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

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

I>>Я с этого и начинал. "Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.
I>>"

E__>Еще в случаях, когда ресурсы ограничены. Если у тебя девайс с 64К оперативы(а таковых еще дочерта, на наш век хватит), то ни о каких жабошарпах речи нет.

Это очень маленький процент проектов в наше время. Думаю менее 0,001%. Так что абсолютно нет смысла его тут рассматривать.

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

G>Видишь, ты зная указатели не понимаешь ссылки в .NET.
Ой спасибо. Мне недавно еще посоветовали почитать книгу по WPF, мол, я в нем мало что понимаю. Посоветуй и ты мне книжку, которая учит приемам демагогии.

M>>Оперативная память — да. Работа с ней — нет.
BBI>Драсте.

Здрасте

M>>Понимание работы VM .NET'а может много в плане понимания работы компьютера и его оперативной памяти
BBI>Аха. Сколько дотнетчиков понимают как реально внутри устроена VM и как она работает? 1% или ещё меньше?

Столько же, сколько и С++'ников действительно понимающих, как работает CRT и указатели в С++

M>> безо всяких указателей вообще.
BBI>Да ты шо. Т.е. в .NET runtime нет ни единой переменной, в которой бы хранился адрес чего либо?
BBI>Просто фантастика. Пешы ищё!

Ну, если ты собираешься додумывать до меня то, что я не говорил, то, пожалуй, можно разговор прекращать.

M>>Ну или с указателями, но без участия С++ и его понимания указателей.
BBI>Расскажи нам лучше на чём написана VM дотнета.

Какое отношение этот вопрос имеет к необходимости знать указатели? Никакого.

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

I>Эдак все С++ программисты станут профнепригодными. Не знаю ни одного серьезного проекта где бы не было ошибок с указателями.
Вы мягко говоря преувеличиваете. Широко известные, нативные и довольно обьемные программы, как то известные браузеры, оффис и т.п уже давным давно не валяться из за "ошибок с указателями". А баги они везде бывают, и нетовые программы тоже вылетают по ексцепшинам и бывает что память и них течет, это просто менее заметно ввиду малого распостранения подобных программ на десктопе.

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

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

I>>Эдак все С++ программисты станут профнепригодными. Не знаю ни одного серьезного проекта где бы не было ошибок с указателями.
_>Вы мягко говоря преувеличиваете. Широко известные, нативные и довольно обьемные программы, как то известные браузеры, оффис и т.п уже давным давно не валяться из за "ошибок с указателями".

Понадобились многие годы что бы пофиксить

Но вообще — валятся. Смотри дыры в безопасности где всякие срывы стека.

>А баги они везде бывают, и нетовые программы тоже вылетают по ексцепшинам и бывает что память и них течет, это просто менее заметно ввиду малого распостранения подобных программ на десктопе.

В с++ коде есть такой класс багов, как баги с указателями. В менеджет его нет. В остальном все одинаково.

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

I>>Понадобились многие годы что бы пофиксить

Но вообще — валятся. Смотри дыры в безопасности где всякие срывы стека.
_>Ну так а говорите "не видел". И не только про браузеры речь, на десктопе хватает нативного достаточно стабильного софта.

Хватает. Сколько времени было затрачено на фиксы багов с указателями ?

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

g>>>>>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.

H>>>>>CLR является виртуальной машиной .NET

G>>>>Где такой бред прочитал? Runtime != VM. Ты еще скажи что CRT — виртуальная машина C.

M>>>

M>>>The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET framework and is responsible for managing the execution of .NET programs. In a process known as just-in-time (JIT) compilation, the CLR compiles the intermediate language code known as CIL into the machine instructions that in turn are executed by the computer's CPU.

M>>>Не?

G>>Это где написано? Не в википедии случайно?

M>В ней, родимой

M>С другой стороны, что там неправильно?

То же самое, только другими словами и старательно избегая слова виртуальная машина написано и тут: http://msdn.microsoft.com/en-us/library/8bs2ecf4.aspx

И ведь не зря "старательно избегая". Ведь CLR описан как спецификация для VM, хотя физически VM отсуствует. Все компилируется в нативный код JIT, который полностью удовлетворяет спецификации.

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

I>>>>Очень просто, чисто для демонстрации:
I>>>>

I>>>>char *p;
I>>>>strcpy(p,src);
I>>>>

_>>> Хороший пример

Ну и за какое время сия хрень обнаруживается и фиксится?

I>>Цитирую : "чисто для демонстрации"
_>Хиленькая такая демонстрация, совсем не показывающая всей сложности использования чистых указателей.

Ошибка-то легко обнаруживается еще на этапе компиляции.

Очень даже показывает проезд по памяти. Представь, что p инициализируется неправильно.

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

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

I>>>В с++ коде есть такой класс багов, как баги с указателями. В менеджет его нет. В остальном все одинаково.

L>>Нет такого класса багов. В принципе. Указатель — это просто число, накосячить с ним не просто.

I>Очень просто, чисто для демонстрации:
I>

I>char *p;
I>strcpy(p,src);
I>

Бага с указателем не видно. Видно баг в /dev/brain и отовсюду торчат кривые hands.sys
Не говоря уже о том, что сейчас делают так

std::string dst(pSrc);

L>>Зато бывают баги, вызванные кривыми руками и мозгами, ниасилившими ручное управление ресурсами и продуманную архитектуру. Ну и, в качестве привета из каменного века, так всеми любимое переполнение буфера, которое в нынешнем С++ нужно еще постараться устроить.

I>Не надо там пытаться. Пример не сложнее предыдущего.

В моей команде тебе придется на уши встать и гопака на потолке станцевать, чтобы что-то отдаленно напоминающее приведенный выше прикол прошел код ревью.

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

M>Голословно. В чем это преимущество выражается?

Сдается мне, когда говорят о прямом доступе к памяти, подразумевают старые добрые времена, реальный режим, MS DOS, Turbo C 2.0.

В MS DOS прямой доступ к памяти использовался постоянно. Кто в DOS не писал окошки, ставя указатель на видеопамять, предварительно проверив текущий видеорежим. Работало на порядки быстрее, чем через BIOS. Или проверить буфер клавиатуры и вообще область данных BIOS.
Но с тех пор, как я начал программировать под Винду, прямой доступ к памяти мне ни разу не понадобился.

_>>>>>Прямой доступ к памяти это преимущество с/c++, причем иногда абсолютно необходимое.

M>>>>Преимущество по сравнению с чем?
_>>>С языками которые этого не позволяют.

M>>Голословно. В чем это преимущество выражается?
_>Очевидно что иногда бывает сильно нужно пошарить по памяти:
_>Как обратиться в внешнему Grid`у через API
_>Re: Как узнать какой процесс создал объект в ROT
_>и т.п.

Очевидно, что это — неочевидно. И учитывая, что тут работа с COM, это является весьма специфичной задачей. Назвать это именно преимуществом над другими языками у меня рука не поднимается. Так, чпособ решить костыли другими костылями

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

M>>>>Преимущество по сравнению с чем?
_>>>С языками которые этого не позволяют.

M>>Голословно. В чем это преимущество выражается?
_>Очевидно что иногда бывает сильно нужно пошарить по памяти:
_>Как обратиться в внешнему Grid`у через API
_>Re: Как узнать какой процесс создал объект в ROT
_>и т.п.

Сомнительное преимущество.

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

I>Неправильно. Если он дожил, значит бюджет позволял жить. Рано или поздно это прекратится.

мне кажется, у нас фломастеры и масштабы разные. В нашей индустрии AV во время рантайма — это не просто critical, это имеет safety implications. Никакого бюджета не хватит дежать дерьмокод. Поэтому если код образца 91 года до сих пор входит в проект, значит он вылизан по самые помидоры. Другого кода там просто быть не может.

I>>>Если ваша команда работает только со своим кодом, то так и будет. А совсем недавно товарищу пришел убитый проект на лялих++... Надо продолжать ?

L>>Судя по тому, что тебе, по всей видимости, указатели снятся в кошмарах, тебе лучше не спрашивать, чем моя команда занимается. Можешь повторить шутку про Дартаньяна

I>Стало быть про убитый проект на лялих++ возражений нет. На том и закончим.

А откуда им взяться? Что тако лялих++ я не знаю, кто твой знакомый не ведаю и кто и зачем убивал этот проект понятия тоже не имею. Да и в чем вопрос, собственно, тоже не совсем понимаю.

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

I>>Начнем сначала. Сколько нужно времени что бы старом проекте на 50-100мб кода заменить указатели на смартпоинтеры и тд.
_>Вам же уже отвечали. Если удовлетворительно проект работает не нужно ничего менять. Если нет то смотрите сами что для вас будет быстрее переписать на менеджет или зачистить плюсный код.

Неудовлетворительно. Если нет низкоуровневой фигни, то обычно дешевле перевести на менеджед.

I>>такое ощущение что большинство адептов С++ в этом топике не в курсе про legacy код. раньше на с++ писалось очень много того, что сейчас пишется на менеджед средствах. Куда деть такой код ? Может назвать его несиплюсным ? это резко снимет проблему указателей

_>Еще как в курсе. Вы сами должны решать как с легаси бороться. Тут однозначного рецепта нет, если дешевле преписать на менедж переписывайте на здоровье, особенно если нужно дальнейшее развитие. Указатели тут не причем. На нете и джаве легаси разве не бывает?

Бывает. После сиплюсного легаси менеджед одно удовольствие

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

I>>>>Начнем сначала. Сколько нужно времени что бы старом проекте на 50-100мб кода заменить указатели на смартпоинтеры и тд.
_>>>Вам же уже отвечали. Если удовлетворительно проект работает не нужно ничего менять. Если нет то смотрите сами что для вас будет быстрее переписать на менеджет или зачистить плюсный код.

I>>Неудовлетворительно. Если нет низкоуровневой фигни, то обычно дешевле перевести на менеджед.
_>Странно что такой проект дожил до возраста легаси. Но чего в жизни не бывает.

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

I>>Бывает. После сиплюсного легаси менеджед одно удовольствие

_>Мне трудно оценить я такой фигней еще пока не занимался. Но коллеги однако плюются. Впрочем синдром когда "все что не нами написано глючит и требует переделки" от языка мало зависит...

На менеджед для легаси есть целый вагон инструментов. Пару часов и старый код свежее нового.

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

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

M>>Ну дык. Указатели старательно упаковывают в GC для бедных — auto_ptr, shared_ptr и прочая *_ptr
BBI>Это не GC ни разу. Это RAII.

M>> чтобы не дай бог кто-то не использовал голые указатели.
BBI>Отнюдь. Основная причина: упрощение управления времени жизни объекта. Уменьшение рукопашной.

GC тоже "упрощение управления времени жизни объекта. Уменьшение рукопашной."
Именно поэтому все "умные указатели" и называют "GC для бедных".

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

BBI>>Отнюдь. Основная причина: упрощение управления времени жизни объекта. Уменьшение рукопашной.

G>GC тоже "упрощение управления времени жизни объекта. Уменьшение рукопашной."
G>Именно поэтому все "умные указатели" и называют "GC для бедных".

Алегарх? Реализуй нам полноценный RAII на GC без деструкторов.
Это совершенно другая концепция, и называть ее "GC для бедных" позволительно только ниасилившим концепцию ручного контроля за ресурсами.

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

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

I>>>Начнем сначала. Сколько нужно времени что бы старом проекте на 50-100мб кода заменить указатели на смартпоинтеры и тд.

L>>Нисколько, потому что это не нужно.

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

Да пусть борется хоть с ветряными мельницами. Если в конторе половина сотрудников по ночам вскакивает в холодном поту от одной мысли об указателях, а другая допускает существование глючного кода годами, то пусть подписывается на что угодно. Результат, впрочем, будет предсказуемым.

I>>>такое ощущение что большинство адептов С++ в этом топике не в курсе про legacy код. раньше на с++ писалось очень много того, что сейчас пишется на менеджед средствах. Куда деть такой код ? Может назвать его несиплюсным ? это резко снимет проблему указателей

L>>Я не могу, он нам сейчас еще и про легаси код рассказывать будет. Давай уже, жги!

I>А есть что сказать более внятного ?

Внятного? Мы с тобой на разных язаках разговариваем, как я посмотрю. Вообще-то приличные люди легаси кодом называют модули, хоть и написанные во времена царя горооха, но при этом стабильные, как Египетские пирамиды. Единственная причина, по которой его трогают — это когда расширение или изменение функциональности становится неизбежным. Но даже тогда с бОльшей вероятностью функциональность просто заменяют новым кодом из соображений однородности и простоты поддержки. Юнит-тесты, опять же.
Говнокод, в котором есть "проблемы с указателями" (сиречь падает на ровном месте) шансов стать легаси кодом не имеет. Разве что в какой-нить внутренней тулзе в какой-нить ООО "Рога и копыта"

M>>Ну дык. Указатели старательно упаковывают в GC для бедных — auto_ptr, shared_ptr и прочая *_ptr
BBI>Это не GC ни разу. Это RAII.

Выделено.

M>> чтобы не дай бог кто-то не использовал голые указатели.
BBI>Отнюдь. Основная причина: упрощение управления времени жизни объекта. Уменьшение рукопашной.

А что GC, по-твоему, делает с точки зрения программиста? ВНЕЗАПНО упрощает управление временем жизни объекта. Уменьшает рукопашную. Но GC — это зло, а вот все остальное — это добро, агаага

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

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

S>>>То есть на прочих шарпах легче и бустрее писать, да плюс еще сразу без ошибок?

I>>В менеджед отсутствует целый класс ошибок связаных с указателями. А благодаря возможностям самого менеджед, есть вагон инструментов которые очень хорошо страхуют программиста или помогают локализовать ошибку максимально быстро.

L>Читаем "в менеджед отсутствует целый класс ошибок, которых в принципе нигде нет". Ты ведь так и не показал нам, что это за ошибки, связанные с указателями.

Показал. вам, сиплюсникам, надо определиться. Или проблем с указателями нет, тогда не ясно зачем вам valgrind, или...

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

L>>>Читаем "в менеджед отсутствует целый класс ошибок, которых в принципе нигде нет". Ты ведь так и не показал нам, что это за ошибки, связанные с указателями.

I>>Показал. вам, сиплюсникам, надо определиться. Или проблем с указателями нет, тогда не ясно зачем вам valgrind, или...
_>Уже определились

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

Ага, "я освоил потому проблем нет" зато бОльшая часть людей валится на собеседованиях именно из за этих указателей.

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

I>>Любая отрасль, где цена ошибки не равняется потере бизнеса или, скажем, человеческой жизни. Всех клиентов не нужно терять, достаточно потерять долю рынка, например перейти из лидеров в аутсайдеры.

L>ну если для бизнеса потеря доли рынка — фигня, то у меня вопросов нет. Только название конторы назови, штоб случайно не вляпаться.

Разве я пишу что потеря доли рынка это фигня ? Хватит додумывать.
Ты просил назвать контору "продавать глюкало, падающее на ровном месте и при этом не растерять всех клиентов".
Я тебе ответил "достаточно потерять долю рынка". То есть, контора, котоаря не может решить внутренние проблемы с продуктом, обязательно потеряет долю рынка. Таких контор пруд пруди, из гигантов — hp, sun, microsoft, ibm...

I>>Ты или читай внимательно, или спрашивай, что непонятно. Я не говорил, что "переписали на жабе". Была кучка проектов, часть плюсовых, часть — джава. Плюсовые вымерли. Джава осталась в строю. Плюсовые вымерли из за обилия проблем внутри кода — утечки, указатели, исключения.

L>Так а я то говорю? плюсы ниасилили, там же указатели и исключения, а от них утечки. Руки кривые, что поделать?

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

>>>говрит лишь о том, что инструмент был изначально выбран неверно, а проект писали криворучки. Как говорится, дело было не в бобине.

I>>"проект писали криворучки" — не ты ли чуть не пеной брызгал и доказывал что все плюсовики суть мега-продвинутые девелоперы у которых годами не бывает багов с указателями ?

L>Все плюсовики, с которыми мне приходится работать, именно такие. Вы там можете хоть на клавиатуре плясать, но заявлять про "проблемы с указателями", когда на самом деле вы просто ниасилили плюсы несколько самонадеянно. Много на себя берете.

Ага, в старом проекте проблемы в коде за 5-7 лет до того, как я в универ пошел, и основная причина — что я сейчас чего то не умею ? А ты, логик, аплодирую стоя

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

I>>Они так и делают. Более того — суровые сиплюсники тоже часто мигрируют в менеджед. Вот наоборот сильно вряд ли. например мигрируют потмоу что нужны более разнообразные задачи.
_>Ну и слова богу. Процесс в принципе естественный.

Процесс естественный, но для с++ ничего хорошего нет. Будет со временем задвинут на задворки как и ассемблер.

>Работы меньше. Плюсников сегодня нужно много меньше чем скажем лет 10 назад. Считаю что необходимое количество адекватных разработчиков наловить можно.

Наоборот, много больше, потому что количество проектов постоянно увеличивается. Многие проекты запускаются на менеджет именно по причине отсутствия плюсовиков.

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

M>>>А что GC, по-твоему, делает с точки зрения программиста? ВНЕЗАПНО упрощает управление временем жизни объекта. Уменьшает рукопашную. Но GC — это зло, а вот все остальное — это добро, агаага

ТКС>>Люди, ни разу не писавшие на языках с деструкторами и RAII, под временем жизни объекта понимают несколько другое, нежели люди, активно использующие RAII. Поэтому им не понятно, что GC НЕ упрощает управление временем жизни объекта в понимании С++. В плюсовой программе удаление одного объекта-хозяина часто приводит к целому каскаду событий, как-то закрытие файлов, сокетов, изменение имперсонации (логаут пользователя с точки зрения операционной системы, например) и .т.п.

M>Да не надо рассказывать сказки. Тут рядом, например, Шеридан показывает, как он это понимает, ага.

А при чем здесь Шеридан? Он что, на плюсах программировать умеет

В форум по плюсам он заходил пару раз, порол чушь. Про RAII его постов не припомню

ТКС>>В языках с GC все эти действия приходится продумывать отдельно от управления памятью. Сложно назвать это упрощением.

M>Расскажи мне, что происходит при вызове delete на shared_ptr, например? Да ничего не происходит до тех пор, пока счетчик ссылок не обнулится. И тогда пойдет тот самый «каскад» который обломится на очередном shared_ptr со счетчиком > 0 ну и т.п.

Это желаемое поведение. Все что надо отработает ровно в тот момент, как только объект перестанет быть нужен. А не через три секунды или полчаса.

M>Но это жы RAII!!!!одинодинодин

Что такое "одинодинодин"?

M>Что в языках с GC что без GC надо достаточно строго следить за внешними к программе ресурсами — файлами, сокетами и т.п. Для всего остального так называемый «современный С++» всеми силами стремится избавится от указателй за *_ptr, которые обеспечивают ровно то, что обеспечивает GC — своевременное удаление этих объектов из памяти.

GC не обеспечивает своевременное удаление объектов из памяти.

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

L>>>Если ты не сиплюсплюсник, то что ты к указателям прицепился?

I>>Я занимаюсь в т.ч. набором и периодически приходится проводить собеседования по С++. бОльшая часть кандидатов валится там где ты и другие утверждают что проблем якобы нет никаких.

L>Это не они валятся, это ты некомпетентен.

Скучные у тебя аргументы, смотри сюда, классика жанра:

IComObject *pObj = ... ;
void **pUnknown = NULL;

pObj->QueryInterface(IID_IUnknown, temp);

Тебе объяснить, где тут ошибка ?

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

G>>Что значит своевременное?

ТКС>А что, кому-то из контекста обсуждения это не понятно? Если речь идет об управлении внешними ресурсами (а именно об этом речь и идет), то "своевременно" означает "немедленно".

Для управления внешними ресурсами есть IDisposable и это не имеет отношения к GC.

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

I>>>Процесс естественный, но для с++ ничего хорошего нет. Будет со временем задвинут на задворки как и ассемблер.
_>>Почему то меня это не пугает.

I>Это и не должно пугать. Главное четко понимать причины этого явления.
Зачем? Мне все равно. Вопросы распостранненности того или иного языка, как и подбора кадров меня абсолютно не беспокоят.
>>>>Работы меньше. Плюсников сегодня нужно много меньше чем скажем лет 10 назад. Считаю что необходимое количество адекватных разработчиков наловить можно.

I>>>Наоборот, много больше, потому что количество проектов постоянно увеличивается. Многие проекты запускаются на менеджет именно по причине отсутствия плюсовиков.
_>>Ну и нафига вам плюсники если можно писать на менеджет? На нем и пишите. Сами же говорите проблем меньше.

I>С++ нужен для низкоуровневого контроля ресурсов. В силу отсутствия плюсовиков, эти вопросы вынуждены решать на менеджед.
Получается?

На самом деле могу порекомендовать только одно, платите достойную зарплату и спецы сами к вам потянутся.

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

ТКС>>>А что, кому-то из контекста обсуждения это не понятно? Если речь идет об управлении внешними ресурсами (а именно об этом речь и идет), то "своевременно" означает "немедленно".

I>>Для управления внешними ресурсами есть IDisposable и это не имеет отношения к GC.

ТКС>Мамуту это сначала объясни

Он это и сам знает, а ты путаешь управление памятью и управление ресурсами. У тебя под управлением почему то понимается "закрытие", "освободждение" и

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

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

S>>>То есть на прочих шарпах легче и бустрее писать, да плюс еще сразу без ошибок?

I>>В менеджед отсутствует целый класс ошибок связаных с указателями. А благодаря возможностям самого менеджед, есть вагон инструментов которые очень хорошо страхуют программиста или помогают локализовать ошибку максимально быстро.

S>Тоесть по большому счету все ништяки не в языке, а в инструментах?

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

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

I>>>Естественно, капитан, в понимании С++ нет никакого GC

ТКС>>Вообще-то есть. Некоторые их даже применяли.

I>Ты про МС++ что ли ? Или про возможность написания квази-gc под нативнй с++ ?

Естественно, про С++.

I> Естественно, и то и то это отстой.

GC вообще отстой. Толку на три копейки, издержек на рубль.

I>>>Такие вещи и нужно продумывать отдельно. Не все сводится к удалению, закрытию и тд. Это только малая часть ворклфоу.

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

I>Вероятно удаление файла у тебя выглядит так:
I>

I>DeleteFile(string fileName)
I>{
I>  DeleteFileOperation operation(fileName);

I>  // в деструкторе будет удаление файла прибитое гвоздями к управлению жизни объекта DeleteFileOperation
I>} 
I>

Ты, я гляжу, не вполне понимаешь, что является внешним ресурсом. Поэтому поясню — операция удаления файла ресурсом не является. Вследствии чего никакой необходимости заводить класс DeleteFileOperation, в деструкторе которого удаляется файл, нету, и предложенный тобой код является полнейшим идиотизмом.

I>>>В с++ никто не напишет за тебя корректный воркфлоу, а совмещение _некоторых_ действий с управлением памяти ничего существенно не меняет.

ТКС>>Не "некоторых действий", а всего управления внешними ресурсами.

I>Покажи на примере простого удаления файла из пекаджа который представляет собой простой зип.

А чего тебе непонятно? Что файл в деструкторе закрывать уместно или что?

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

ТКС>>Т.е., ты хочешь сказать, что RAII не работает и указанное тобой невозможно реализовать средствами RAII?

I>Представь себе xml-конфиг где прописывается сценарий работы с ресурсом...

Сценарии в xml прописывать — жосткий мазохизм, для подобных целей есть языки и поудобнее

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

I>Указатель и ссылка это две большие разницы.
Даааа. Ссылка это сахар над указателем. Вот и вся разница.

I>Ссылка это просто возможность работать с конкретным объектом.
Надо полагать что ты считаешь что тут в отличие от указателя к объекту доступ осуществляется не по адресу а путём божественного вмешательства.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>>Куда деть такой код?
BBI>>Зависит от качества кода. Хороший в реюз. Плохой или чинить или выкинуть.

I>Выкинуть как правило слишком дорого. Например потому, что код писал некото с большим матбеграундом и большими способностями запоминать неструктурированый код. Ему было легко работать с простынями в 100кб и более . Этот код работает, более того, является ключевым.
I>Что бы его переписать, нужен точно такой же специалист, а это как правило всегда проблема.

Ок. Тогда сесть и итерационно отрефакторить с прогоном regression tests после каждой итерации. Выйдет всё одно дешевле в долгосрочной перспективе.
Если код действительно ключевой то его принципы работы должен понимать хотя бы один человек в конторе, он должен находится в состоянии, когда его можно развивать и поддерживать. Иначе проект неминуемо скатится в говно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

ТКС>>GC вообще отстой. Толку на три копейки, издержек на рубль.
I>Зато есть алгоритмы которые рвут с++ именно за счет ГЦ. Да-да.
Померяемся?

Уже как то оказалось что GC медленнее чем native аллокация.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

L>>Ты продолжаешь показывать свое чудовищное непонимание вопроса. Тебе точно не стоит собеседовать кандидатов на C++.
L>>"New не будет" означает, что сущность, ответственная за корректное удаление некоего объекта, его сама не создает. Этот объест ей передается в полное владение извне, в конструкторе. Сам же объект создается, к примеру, в фабрике.

I>Это ж целая инфраструктура и только для того, что бы правильно работать с указателями ...

Ты серьезно ничего не понял или придуриваешься?
Я тебе на пальцах только что описал архитектуру одного модуля системы с пояснениями, а ты увидел только указатели. Это уже комплекс.

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

L>>Это не они валятся, это ты некомпетентен.

I>Скучные у тебя аргументы, смотри сюда, классика жанра:
I>

I>IComObject *pObj = ... ;   // Это не скомпилируется
I>void **pUnknown = NULL;

pObj->>QueryInterface(IID_IUnknown, temp);   // Где объявление переменной temp?
I>

I>Тебе объяснить, где тут ошибка ?

В 13 строке, скорее всего.

Это не из собеседования часом? Даже если опустить комментарии выше, то твой вопрос звучит так "угадай, где мы еще могли накосячить". Так можно только телепатов набирать, но никак не программистов.

P.S. Нормальные C++ программисты прадигму строгого контроля за ресурсами и жизнью объектов считают как нечто само собой разумеющееся. Поэтому когда ты снисходительно заявляешь, что pObj нужно проверять на null и нужно не забыть сделать ему Release (только причем тут C++? Это COM) и неплохо бы проверить, не будет ли там где исключений каких, не удивляйся, что в ответ на тебя посмотрят как на, эээ, альтернативно одаренного.

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

I>>Скучные у тебя аргументы, смотри сюда, классика жанра:
I>>

I>>IComObject *pObj = ... ;   // Это не скомпилируется

// спасибо, капитан очевидность, это указание что объект будет инициализирован.  Я догадался, а ты - нет.

I>>void **pUnknown = NULL;

pObj->>>QueryInterface(IID_IUnknown, temp);   // Где объявление переменной temp?

// тут было начеркано и я перенес как было, pUnknown  и есть temp

I>>

I>>Тебе объяснить, где тут ошибка ?

L>В 13 строке, скорее всего.
L>Это не из собеседования часом? Даже если опустить комментарии выше, то твой вопрос звучит так "угадай, где мы еще могли накосячить". Так можно только телепатов набирать, но никак не программистов.

Это код который выдал кандидат на просьбу запросить IUnknown через имеющийся указатель на интерфейс.

L>P.S. Нормальные C++ программисты прадигму строгого контроля за ресурсами и жизнью объектов считают как нечто само собой разумеющееся. Поэтому когда ты снисходительно заявляешь, что pObj нужно проверять на null и нужно не забыть сделать ему Release (только причем тут C++? Это COM) и неплохо бы проверить, не будет ли там где исключений каких, не удивляйся, что в ответ на тебя посмотрят как на, эээ, альтернативно одаренного.

У тебя бурная фантазия — я нигде не говорил того, что ты мне приписываешь, т.е. выделеная часть это твоя отсебятина

похоже, нужно объяснить для тебя что к чему

Вот уже годный ответ:

IComObject *pObj = ... ;  

IUnknown *pUnknown = NULL;

pObj->QueryInterface(IID_IUnknown, (void**)&pUnknown);

Выделил специально для тебя

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

I>>Указатель и ссылка это две большие разницы.
BBI>Даааа. Ссылка это сахар над указателем. Вот и вся разница.

Ссылка она есть в даже там где нет никакого АП. Указатель существует только для АП.
Ссылка это не сахар, ибо никогда ни при каких условиях не имеет отношения к адресной арифметике,а реализация чз указатели есть частный случай.

I>>Ссылка это просто возможность работать с конкретным объектом.
BBI>Надо полагать что ты считаешь что тут в отличие от указателя к объекту доступ осуществляется не по адресу а путём божественного вмешательства.

Надо полагать реализация такой вещи как "ссылка" зависит от платформы. Т.е. это высокоуровневая вещь. Реализация ч.з. указатели это только частный случай.

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

I>Вот уже годный ответ:
I>

I>IComObject *pObj = ... ;  

I>IUnknown *pUnknown = NULL;

pObj->>QueryInterface(IID_IUnknown, (void**)&pUnknown);  
I>

Годный ответ на какой вопрос? Куда делась temp, и на кой хрен она была нужна в первом варианте кода?

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

L>>В 13 строке, скорее всего.
L>>Это не из собеседования часом? Даже если опустить комментарии выше, то твой вопрос звучит так "угадай, где мы еще могли накосячить". Так можно только телепатов набирать, но никак не программистов.

I>Это код который выдал кандидат на просьбу запросить IUnknown через имеющийся указатель на интерфейс.

То есть это я должен был об этом догадаться?

L>>P.S. Нормальные C++ программисты прадигму строгого контроля за ресурсами и жизнью объектов считают как нечто само собой разумеющееся. Поэтому когда ты снисходительно заявляешь, что pObj нужно проверять на null и нужно не забыть сделать ему Release (только причем тут C++? Это COM) и неплохо бы проверить, не будет ли там где исключений каких, не удивляйся, что в ответ на тебя посмотрят как на, эээ, альтернативно одаренного.

I>У тебя бурная фантазия — я нигде не говорил того, что ты мне приписываешь, т.е. выделеная часть это твоя отсебятина

Ну ты же задал телепатическую задачу. Вот тебе ответ.

I>похоже, нужно объяснить для тебя что к чему

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

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

I>"Это код который выдал кандидат на просьбу запросить IUnknown через имеющийся указатель на интерфейс."

Что-то ты не договвариваешь. При просьбы запросить чего-то через указатель, человек пишет:

ptr->get_something(IUknown);

А тот код, что ты показал, делает что-то ещё.

I>Ну и дела, уже третий мега=-сиплюсник в одном топике и тоже не умеет читать. Или вы все только правильный С++ код умеет читать ?

Это где я такое про себя писал?

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

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

M>>Новые языки программирования растут как грибы после дождя. Старые набирают комьюнити. На вскидку популярные языки, которые на слуху: C, C++, C#, Java, VisualBasic, PHP, Python, Perl, JavaScript, lisp, scala, Deplhi, erlang, D, Dart, ObjectiveC, ActionScript, Lua, Ruby — какие-то из них мало используются (D), но всё равно на слуху. Так вот, большинство из этих языков интерпретируемые или компилятся в свой байт-код, нативный код из коробки дают C, C++, ObjC, Delphi, D и всё. Почему так мало языков, которые компилятся в нативный код?

A>А нафига новые языки с компиляцией в нативный код? Всё чаще нужна именно скорость разработаки и удобство сопровождения, а не скорость расчётов. Вот у меня в коллекции есть хорошая ссылочка:

А разве компиляция в нативный код противоречит скорости разработки? Как?

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

L> Из недавнего — собственная реализация дерева без использования умных указателей. Из-за дикого размера дерева и дикого количества оных одно оборачивание детей в умный указатель давало оверхед по памяти мегабайт в триста. Выкинули умные указатели, обучили ноду дерева делать delete в деструкторе. Профит.

А ещё можно было обучить людей, размещающих в памяти деревья из восьмизначного количества узлов, использовать специализированный аллокатор.
А то знаете, ещё по восемь байт на каждую ноду, которые запоминает malloc... Растраты, сплошные растраты! всюду суеверия и мракобесие.

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

b-3>А ещё можно было обучить людей, размещающих в памяти деревья из восьмизначного количества узлов, использовать специализированный аллокатор.

А ты смейся-смейся. Аллокатор, кстати, тоже был на повестке дня, но до этого не дошло, выигрыш от простого рефакторинга дерева позволил отыграть почти 500 мегабайт для системы в целом.

b-3>А то знаете, ещё по восемь байт на каждую ноду, которые запоминает malloc... Растраты, сплошные растраты! всюду суеверия и мракобесие.

32-битному процессу в Виндовс доступно лишь 2 гигабайта памяти. 300 мег туда, 300 мег сюда и приехали.

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

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

I>>>>Указатель и ссылка это две большие разницы.
BBI>>>Даааа. Ссылка это сахар над указателем. Вот и вся разница.

___>>Налицо непонимание.
BBI>Давай разъясню если не понимаешь.
Себе разъясни.

___>>Как насчет адресной арифметики?
BBI>Запрещена "сахаром"

___>> Или ссылка на ссылку?
BBI>Запрещена "сахаром"

По итогу имеем ссылка != указатель

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

I>>Ссылка никак не относится к адресам. Указатель это именно номер байта в АП, то есть, самый что ни есть, адрес и отсюда следует адресная арифметика и тд.
BBI>Скажи, а как происходит обращение к объекту по ссылке? Как его находят, если по-твоему в ссылке в отличие от указателя адреса нету?

На каждой аппаратной/программной платформе по разному.

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

ТКС>>>GC вообще отстой. Толку на три копейки, издержек на рубль.
I>>Зато есть алгоритмы которые рвут с++ именно за счет ГЦ. Да-да.
BBI>Померяемся?

Уже как то оказалось что GC медленнее чем native аллокация.

Оказалось, что GC быстрее чем с++ аллокация искаропки, особенно с учетом фрагментации. А что бы всунуть нормальный аллокатор нужно еще поискать нормального спеца, таких нынче днём с огнём искать надо.
Ну и снова ссылка — http://morepypy.blogspot.com/2010/06/jit-for-regular-expression-matching.html

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

I>>То есть, если файл не временный, то надо придумывать другой способ управления ресурсами ?

ТКС>Нет. Если объекта, по время жизни соответствующего файлу, нет, никакого особого способа управления ресурсами выдумывать не надо. Потому что ресурса тут нет.

Файл есть, а ресурса нет. Ну и дела

У тебя какое то уникальное понятие ресурса.

I>>Я так понял, тебе не нравится пекадж

Оно и ясно — в деструкторе не надо ничего удалять.

ТКС>Я слова такого — "пекадж" не знаю. Нет его в русском языке. Поэтому жду пример кода.

Ты не знаешь что такое зип ? Бывает. Есть некоторая структура фолдеров с файлами которая уложена в архив в формате zip. Это называется пекадж.

I>>Берем такой случай управления внешним ресурсом, как перенос файла:
I>>File.Move(source, dest);

I>>Жду демонстрации твоей мега идеи "легко прибить гвоздями к управлению временем жизни объектов и нет ни одной причины, чтобы разделять их".

ТКС>Очевидно, что у нас разное понимание слова "ресурс". С моей точки зрения файл, вся работа программы с которым ограничивается единократным перемещением, ресурсом для этой программы не является.

Я понял твою идею — если в деструкторе удаляем файл, то это ресурс

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

I>>>Зато файл является внешним ресурсом, а у тебя сказано "легко прибить гвоздями к управлению временем жизни объектов и нет ни одной причины, чтобы разделять их".
I>>>Раз причин разделять нет, то удаление файла должно делаться в деструкторе какого то класса.

ТКС>>Конечно. Если у тебя есть объект, соотвествующий файлу. Для временных файлов это вполне нормальное решение.

I>То есть, если файл не временный, то надо придумывать другой способ управления ресурсами ?

Нет. Если объекта, по время жизни соответствующего файлу, нет, никакого особого способа управления ресурсами выдумывать не надо. Потому что ресурса тут нет.

>>Если же у тебя такого объекта нет, то придумывать его тоже нет причин. Соответственно, и прибивать гвоздями нечего.

I>Опаньки ! Сначала ты вещал, что управление ресурсов "легко прибить гвоздями к управлению временем жизни объектов и нет ни одной причины, чтобы разделять их".
I>Щас ты начал задним числом уточнять своё утверждение

Кто хотел, тот понял. Но, естественно, нашлись тролли, которые под управление ресурсами пытаются всякую пургу подогнать. С нетерпением жду, когда кто-нибудь вспомнит про так называемые "строковые ресурсы" и будет их сюда же мешать.

I>>>Вот пример:
I>>>"удаления файла из пекаджа который представляет собой простой зип"

I>>>Жду примера кода.

ТКС>>Я не вполне понимаю, что именно ты хочешь увидеть. Поэтому жду примера кода на C#, потом представлю аналог на плюсах.

I>Я так понял, тебе не нравится пекадж

Оно и ясно — в деструкторе не надо ничего удалять.

Я слова такого — "пекадж" не знаю. Нет его в русском языке. Поэтому жду пример кода.

I>Берем такой случай управления внешним ресурсом, как перенос файла:
I>File.Move(source, dest);

I>Жду демонстрации твоей мега идеи "легко прибить гвоздями к управлению временем жизни объектов и нет ни одной причины, чтобы разделять их".

Очевидно, что у нас разное понимание слова "ресурс". С моей точки зрения файл, вся работа программы с которым ограничивается единократным перемещением, ресурсом для этой программы не является.

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

I>А дай-ка пример готовой либы которая умеет дефрагментировать память как это умеет GC ?
А зачем её дефрагментировать? Нормальный аллокатор позволяет свести фрагментацию к мизеру.

I>>>Ну и снова ссылка — http://morepypy.blogspot.com/2010/06/jit-for-regular-expression-matching.html
BBI>>А что мешает написать JIT для regex для дёргания из native?
I>Очевидно, сложность задачи увеличивается, при чем сильно нелинейно.
Да ну? По мне так один фиг.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

BBI>>>На какой это аппаратной платформе есть ссылки?
I>>Ты сам то понял что спросил ?
BBI>Разумеется.
BBI>Ответы будут?

Ссылки реализуемы на всех аппаратных платформах.

BBI>>>Или обращение к объектам в памяти происходит не по адресам.
I>>Вот-вот

BBI>Если не по адресам то как? Сумеешь объяснить как это на уровне проца работает?

Ассоциативная организация памяти, делов то.

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

ТКС>>Например, обращение по хэндлу может осуществляться на одном компьютере, а обращение по соответствующему этому хэндлу адресу — на другом. Соответственно, ни о какой адресной арифметике речь не идет.
BBI>Результат то всё равно прилетит на эту машину. И вычитывать ты его будешь из локальной памяти.

Угу, только не по тому указателю и уж точно без адресной арифметики. И вообще на клиенте у меня 32 бита, а на сервере 64. На сервере хэндл как-то транслируется в 64 битный указатель, а на клиенте это просто число.

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

ТКС>>Например, обращение по хэндлу может осуществляться на одном компьютере, а обращение по соответствующему этому хэндлу адресу — на другом. Соответственно, ни о какой адресной арифметике речь не идет.
BBI>Результат то всё равно прилетит на эту машину. И вычитывать ты его будешь из локальной памяти.

Это не важно. Главное что ссылка может быть реализована хоть указателем, хоть GUID, хоть просто строкой, хоть целой иерархией взаимодействующих объектов. Указатель это всегда указатель и ничего более.

A>Вот представь, что ты хочешь написать что-то для ARMа, а твой SuperNativeCSharp умеет генерировать код только для x86,

есть mono. отлично работает на iOS и Android

A>причём у него даже есть некие проблемы с 64 разрядными приложениями.

пруф

А откуда такая любовь к нативному коду? Очень много программ, которые проще было бы реализовать меньшими силами на той же/*том же?*/ Java.

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

TSP>А откуда такая любовь к нативному коду? Очень много программ, которые проще было бы реализовать меньшими силами на той же/*том же?*/ Java.
Да. Но есть задачи где без нейтива никак не обойтись. Отсюда и любовь, на нейтиве можно написать вообще все что угодно, конечно, возможно что с большими трудозатратами.

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

TSP>А откуда такая любовь к нативному коду? Очень много программ, которые проще было бы реализовать меньшими силами на той же/*том же?*/ Java.

Некоторые ценят скорость исполнения. Не всегда обоснованно правда.

ПС. Только не надо приводить ссылки на шатауты где явисты прыгают через собственную голову чтобы совсем не отставать от плюсистов.

M>ПС. Только не надо приводить ссылки на шатауты где явисты прыгают через собственную голову чтобы совсем не отставать от плюсистов.
Да я сам на плюсах пишу сейчас под несколько платформ. Все java потуги провалились из за критической нехватки производительности.

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

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

TSP>>А откуда такая любовь к нативному коду? Очень много программ, которые проще было бы реализовать меньшими силами на той же/*том же?*/ Java.
_>Да. Но есть задачи где без нейтива никак не обойтись. Отсюда и любовь, на нейтиве можно написать вообще все что угодно, конечно, возможно что с большими трудозатратами.

Да. Но есть задачи где без ассемблера никак не обойтись. Отсюда и любовь, на ассемблере можно написать вообще все что угодно, конечно, возможно что с большими трудозатратами.

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

TSP>проще было бы реализовать меньшими силами

Такой принцип уже применили к промышленности, и теперь практически всё делается в Китае.

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

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

TSP>>>А откуда такая любовь к нативному коду? Очень много программ, которые проще было бы реализовать меньшими силами на той же/*том же?*/ Java.
_>>Да. Но есть задачи где без нейтива никак не обойтись. Отсюда и любовь, на нейтиве можно написать вообще все что угодно, конечно, возможно что с большими трудозатратами.

Ops>Да. Но есть задачи где без ассемблера никак не обойтись. Отсюда и любовь, на ассемблере можно написать вообще все что угодно, конечно, возможно что с большими трудозатратами.
Точно, есть и задачи ислючительно для ассемблера.

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

O>Нативные языки по своей природе ограниченны, потому что упираются в нижележащие возможности архитектуры и операционной системы.

Скорее, в их несовместимность при обромном разнообразии.

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

TSP>В теории красиво и правильно. Согласен полностью.
TSP>Но вот от стыковки C# с C++ я удовольствие испытал весьма сомнительное.

За шарп не скажу, но сам я недавно сопрягал С++ с Питоном (а лет 15 назад — с Tcl), особых проблем не заметил, кроме детских проблем самого питона (многопоточность — это смерть, лучше ею не пользоваться в питоне вообще) + его специфические вещи типа счетчиков ссылок.
Но тут, конечно, Boost.Python сильно выручает, с ним очень приятно все программить.

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

J>Тот же питон — дичайшее тормозилово, но его можно (сюрприз!) использовать в научных вычислениях, потому что есть нативные библиотеки, написанные на Си, которые делают все быстро (NumPy、SciPy),

Ну-ну. Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее. На С++ пока не переписывал. Там чистая матричная алгебра.

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

O>Нативные языки по своей природе ограниченны, потому что упираются в нижележащие
O>возможности архитектуры и операционной системы. Плюс некоторый "сахар" в виде
O>языковых средств (шаблоны в С++) и набора библиотек, но не больше.
O>Концепция компилируемых языков во многих отношениях свой ресурс исчерпала и дальше
O>двигаться просто некуда. Новые задачи не решаются совершенствованием компилятора и
O>добавлением новых библиотек.

Не трогая C# с его LINQ и лямбдой, ограничусь Явой и С++. Что такое есть в Яве, чего нет в С++ ?

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

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

O>>Нативные языки по своей природе ограниченны, потому что упираются в нижележащие
O>>возможности архитектуры и операционной системы. Плюс некоторый "сахар" в виде
O>>языковых средств (шаблоны в С++) и набора библиотек, но не больше.
O>>Концепция компилируемых языков во многих отношениях свой ресурс исчерпала и дальше
O>>двигаться просто некуда. Новые задачи не решаются совершенствованием компилятора и
O>>добавлением новых библиотек.

PD>Не трогая C# с его LINQ и лямбдой, ограничусь Явой и С++. Что такое есть в Яве, чего нет в С++ ?
виртуальная машина (бинарный стандарт как следствие)
рантайм-рефлексия
рантайм-подмена/подгрузка кода

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

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

J>>Тот же питон — дичайшее тормозилово, но его можно (сюрприз!) использовать в научных вычислениях, потому что есть нативные библиотеки, написанные на Си, которые делают все быстро (NumPy、SciPy),

PD>Ну-ну. Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее. На С++ пока не переписывал. Там чистая матричная алгебра.

Ты эти пакеты используешь "голыми" или под ними что-то лежит?
Они ж работают поверх всяких нативных лапаков/атласов/MKL и т.д, а это все дюже скоростные библиотеки.

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

PD>Это свойство языка, а не виртуальной машины. Вполне можно представить себе (да наверное и существует) язык с нативным кодом и сборкой мусора.
Прошу прощения, что вмешиваюсь, похоже очень на D.

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

PD>>Не трогая C# с его LINQ и лямбдой, ограничусь Явой и С++. Что такое есть в Яве, чего нет в С++ ?
J>виртуальная машина (бинарный стандарт как следствие)

С этим соглашусь, но я имел в виду возможности языка.

J>рантайм-рефлексия

Да, в С++ убого. Но могло бы быть лучше.

J>рантайм-подмена/подгрузка кода

Она таки часто нужна ?

В общем, кое-что есть, согласен, но по большому счету мало отличий.

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

PD>И обычная тоже. Это вообще свойство языков, а не машины. Например, С и Pascal , С и Fortran -77 сопрягались без проблем, C++ и Object Pascal — уже с проблемами из-за разного подхода к реализации объектов.

Позанудствую: я не смог прикрутить MS Fortran 5.0 к Borland C не то 2.0, не то 3.1, не помню. За исключением простейшего случая: в вызываемую порпрограмму на Фортране не передавалось никаких параметров. А вот MS C — без проблем. Там С- и фортрановские модули шли вперемешку, и все работало.

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

PD>ПО, которое продается в тысячах и миллионах копий, как писали на нативных языках, так и пишут. ПО, которое делается на заказ, как писали раньше на Бейсике, так и пишут сейчас на его духовных наследниках.
Не скажите. Тиражные вещи также пишутся и не на нативном коде. Даже для программистов. Например ide от jetbrains. Просто увеличивается отношение объем задачи / время, затраченное на выполнение этой задачи. Поэтому там, где есть смысл пожертвовать временем машины — жертвуют. Там, где нет, — нет. немножко кэпствую, простите.

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

PD>Я не спорю, что такие программы есть, но их процент ничтожно мал. Кстати, могу еще один пример привести — Visual Studio IDE, начиная с 2003. До сих пор с тоской вспоминаю VS6 — она летала на тогдашних машинах, а эта тормозит на нынешних, и памяти жрет неимоверно больше. А возможностей (для С++) добавилось хорошо если процентов 50.
Да, действительно. У меня на домашнем до сих пор 6 стоит

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

PD>+1. Я тоже на Борланд не пробовал, а VC6 с Fortan Compaq скрестил без проблем. Благо и IDE одна и та же. Отлаживалось на ура : F11 и мы из С попадаем в Фортран.

Единственная вещь, которую я так и не сделал — доступ из C к безымянному COMMON-блоку. Правда, у меня есть отмазка: у нас никто безымянных COMMON-блоков не использовал.

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

P>Единственная вещь, которую я так и не сделал — доступ из C к безымянному COMMON-блоку. Правда, у меня есть отмазка: у нас никто безымянных COMMON-блоков не использовал.

У меня другое не получилось. Строки в Фортране

CHARACTER S(100)

и в скобках константа. А я очень хотел размер вычислять, и мог — в C-части, но вот вернуть обратно в Фортран не мог. Пришлось по максимуму заказать.

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

M>В нативных Segmentation fault получить. Заметно проще, учитывая наличие почти во всех них Null Pointer'а. Есть исключения вроде Eiffel если не ошибаюсь, но они нафиг никому не нужны. В явах NPE получить тоже не проблема, но там хотя бы красивая трассировка стека будет вместо всяких "память не может быть read"

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

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

J>А нативщикам остается писать начинку, которой будет рулить какой-нть скрипт, и этот скрипт предоставит удобный и прозрачный DSL для решаемой задачи.
J>И это хорошо.
J>И пусть таких языков будет больше — людям жить будет легче, и программить смогут даже админы (перл, питон), которым для их поделок нафиг не нужны вяские петтерны и прочие радости "настоящего" программирования.
Легкость разработки и компиляция/интерпретация это вообще ортогональные понятия.

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

J>Тот же питон — дичайшее тормозилово, но его можно (сюрприз!) использовать в научных вычислениях, потому что есть нативные библиотеки, написанные на Си, которые делают все быстро (NumPy、SciPy), а скриптовый язык просто предоставляет клей, которому нафиг не нужно быть супербыстрым и уж тем более компилиться в машкод.
Все это очень правильно и красиво пока не дошло дело до суровой реальности, в которой из-за нехватки или неадекватности существующих нативных библиотек, или из-за стремления все сделать самому, на тормозных скриптах пишется большая часть логики с соответствующим результатом.

Взять тот же php, штатные библиотеки иногда настолько неадекватны, что даже CRC приходилось считать скриптом.

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

LF>Why IL
LF>

LF>Меня иногда спрашивают о том, почему мы выбрали именно эту стратегию; почему компилятор C# не может напрямую генерировать машинный код без дополнительного промежуточного этапа? Зачем нам нужны два компилятора для преобразования кода на языке C# в машинные инструкции, когда достаточно было бы одного?

LF>Существует несколько причин, но все они более или менее сводятся к одному: в нашем случае система, построенная на основе промежуточного языка, существенно дешевле.

По ссылке объяснено, почему используется промежуточный язык, т.е. C# -> IL -> Native вместо C# -> Native.
А вопрос был про рантайм-исполнение промежуточного кода вместо нейтив.

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

M>Точней голых указателей. Умные могут быть. Причем даже не проблема в плюсах сделать менеджер памяти такой как в шарпе : с моментальным выделением памяти и отсутствием фрагментации. Но тогда и при удаленее он будет временами надолго подтупливать запуская сборку мусора.

А тут в принципе никуда не денешься. память надо выделять и освобождать, если это не Фортран-77 и не GW-Basic

. Выделять всегда надо, когда требуется (есть хитрости, но о них не будем), а вот освобождать можно либо сразу, когда стал ненужен, либо периодически всех, которые стали не нужны после прошлого удаления. Поэтому в С++ нет таких тормозов, там удаляется более или менее равномерно по времени, а в системах со сборкой мусора есть. Ну и еще учти, что при удалении в С++ никто ничего не дефрагментирует, так как нельзя. А на дефрагментацию тоже время требуется. Зато да, в С++ нужно врем на выделение, так как поиск свободного блока и его расщепление. И фрагментация там тоже, да, хотя и не фатально это.

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

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

TSP>>В теории красиво и правильно. Согласен полностью.
TSP>>Но вот от стыковки C# с C++ я удовольствие испытал весьма сомнительное.

J>За шарп не скажу, но сам я недавно сопрягал С++ с Питоном (а лет 15 назад — с Tcl), особых проблем не заметил, кроме детских проблем самого питона (многопоточность — это смерть, лучше ею не пользоваться в питоне вообще) + его специфические вещи типа счетчиков ссылок.
J>Но тут, конечно, Boost.Python сильно выручает, с ним очень приятно все программить.

Хз-хз. У меня был негативный опыт года 3 назад. Кроме Буста ещё SWIG пробовал. Всё равно геморроя куча. Я вообще нормальный интероп видел только в связке Assembler->C->C++. В остальных случаях игра не стоит свеч.

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

M>В нативных Segmentation fault получить. Заметно проще, учитывая наличие почти во всех них Null Pointer'а. Есть исключения вроде Eiffel если не ошибаюсь, но они нафиг никому не нужны. В явах NPE получить тоже не проблема, но там хотя бы красивая трассировка стека будет вместо всяких "память не может быть read"

В явах/шарпах еще, что очень важно, при почти любой ошибке максимум свалится текущий поток, а не все приложение. Если потоки практически независимы(а это именно так в подавляющем большинстве веб-приложений), то другие треды просто не заметят падения собрата. В тех же плюсах непойманное исключение в любом потоке ложит весь сервер.

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

А как летала VC++ 1.52! А среда VB (хоть и нативная) — всегда подтормаживала...

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

A>А как летала VC++ 1.52!

Не застал. Я тогда на BC++ работал.

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

E__>Хм. Насколько промежуточный жабовский язык поход на ассемблер х86? Практически никак. И тем не менее, в общем случае падение производительности не такое и большое.

Смотря на чем. Для матричных операций я получил 2-3 раза.

>Плюс, JIT не стоит на месте, а очень даже развивается. А компилять код, зная контекст и аппаратное окружение, можно куда эффективнее, чем "для общего случая".

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

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

PD>У меня другое не получилось. Строки в Фортране

PD>CHARACTER S(100)

PD>и в скобках константа. А я очень хотел размер вычислять, и мог — в C-части, но вот вернуть обратно в Фортран не мог. Пришлось по максимуму заказать.

ЕМНИП, и нельзя было это сделать. Фортран длины строк во время выполнения не вычислял, а просто возвращал то, что указывалось при объявлении. Деталей уже не помню.
Непонятно только, а на фига тебе надо было строки в Фортран возвращать, он же не заточен на работу со строками. Точнее, там кое-что можно было сделать, но, по-моему, со строкой удобнее было работать как со скалярной переменной, в не массивом символов. Разумеется, в Фортране-77, в Ф4 существовали, ЕМНИП, только строковые константы.

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

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

J>>Тот же питон — дичайшее тормозилово, но его можно (сюрприз!) использовать в научных вычислениях, потому что есть нативные библиотеки, написанные на Си, которые делают все быстро (NumPy、SciPy), а скриптовый язык просто предоставляет клей, которому нафиг не нужно быть супербыстрым и уж тем более компилиться в машкод.
Q>Все это очень правильно и красиво пока не дошло дело до суровой реальности, в которой из-за нехватки или неадекватности существующих нативных библиотек, или из-за стремления все сделать самому, на тормозных скриптах пишется большая часть логики с соответствующим результатом.
Ну так я о том и говорю, что нужны быстрые нативные компоненты, типа того же NumPy и SciPy. Не было бы их — мы бы пользовались питоном сильно меньше, а то и перешли бы на другой скриптовый язык (Луа, например), ибо в Питоне уж очень много несуразностей.

Q>Взять тот же php, штатные библиотеки иногда настолько неадекватны, что даже CRC приходилось считать скриптом.
Ну так а кто мешает самому написать CRC на плюсах и юзать из php?

Но вообще ты правильную проблему озвучиваешь. Я много раз видел, когда человек добавляет скриптование для своей нативной подсистемы (небольшое и к месту), и оно всем настолько нравится, что этот скрипт начинает использоваться не по назначению, далеко за пределами, предполагаемыми изначально автором, и через пару-тройку лет все превращается в помойку (потому что, к примеру, нет в помине модульности, ибо какая нафиг модульность для однострочных (изначально) скриптов), а в результате все ругают автора скрипта, типа говноязык соорудил.

Но это социальная проблема, не зависящая от конкретного скриптового языка.

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

JB>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Ничего нового не произошло. То же самое было 10 и 20 и 30 лет назад. И тогда были программисты, которые писали на Фортране и С/C++, и программисты, которые писали на Бейсике. И вторых всегда было больше, чем первых.
PD>>ПО, которое продается в тысячах и миллионах копий, как писали на нативных языках, так и пишут. ПО, которое делается на заказ, как писали раньше на Бейсике, так и пишут сейчас на его духовных наследниках.
JB>Да нет. Изменилось. ПО, распространяемое миллиардами копий, написано на html и прочих javascipt'ах. Добро пожаловать в интернет.

А ведь правда... Гмыло теперь у миллиардов, и уже не скажешь, что это просто сайт — это приложение. На 100 мегабитах инета и хорошем проце оно грузится быстрее локального клиента с диска(или то у меня тормозной жесткий — хз, но инет точно быстрее, тем более, что местный вообще гигабит, а там возможны флюктуации до 300-400 мегабит с мира засчет хитрой загрузки через ua-ix, этого в тарифах нет, но в реале бывает). Особенно это видно на документах — офис(хоть опен под лин, хоть мс под вин) тупо дольше загружает нативу, чем открывание документа онлайн — оно моментальное, а приложение пока загрузится, несколько секунд! Да, у оффлайна больше фич, но в 99% они мне не упились — мне просмотреть в основном надо, ну да чутка поменять. Я уже не говорю про совместную обработку.

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

F>>Такой принцип уже применили к промышленности, и теперь практически всё делается в Китае.

TSP>И что? Ну стоила бы вся техника в 5 раз дороже без Китая.

А может быть, просто у кого-то бонусы были бы раз в 50 меньше. Кто знает?

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

P>А ты запускал VC6 на Pentium-100 с 16M оперативы?

Да. Вполне нормально было. У меня студенты на этой конфигурации года 3 работали.

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

P>ЕМНИП, и нельзя было это сделать.

Ну да. А хотелось.

P>Непонятно только, а на фига тебе надо было строки в Фортран возвращать, он же не заточен на работу со строками. Точнее, там кое-что можно было сделать, но, по-моему, со строкой удобнее было работать как со скалярной переменной, в не массивом символов. Разумеется, в Фортране-77, в Ф4 существовали, ЕМНИП, только строковые константы.

Просто надо было создать Фортран-интерфейс к С-коду, то есть вызывать все С-функции из фортрана. А одна из функций какую-то строку возвращала.

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

PD>Спасибо за приглашение

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

PD>Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее.

А может стоило попробовать реализацию питона под джаву: Jython?

Мне кстати самому интересно, как соотносятся про производительности Jython и Java.

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

DL>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее.

DL>А может стоило попробовать реализацию питона под джаву: Jython?

DL>Мне кстати самому интересно, как соотносятся про производительности Jython и Java.

А мне интересно, во что скомпилится этот Jython. Напиши какой-нибудь код под него(пусть будет простой — с математикой, хотя можно добавить пару фирменных фишек Питона), скомпиль в жабовский байткод, декомпиль(не в жабу, а в читабельный вид — асм байткода — http://www.varaneckas.com/jad), листинги в студию.
А я напишу это же на жабе, и сделаю то же самое. И сравним на низком уровне, что вышло. Там сразу видно будет, байткод очень простой для понимания.

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

E__>Здравствуйте, D.Lans, Вы писали:

DL>>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее.

DL>>А может стоило попробовать реализацию питона под джаву: Jython?

DL>>Мне кстати самому интересно, как соотносятся про производительности Jython и Java.

E__>А мне интересно, во что скомпилится этот Jython. Напиши какой-нибудь код под него(пусть будет простой — с математикой, хотя можно добавить пару фирменных фишек Питона), скомпиль в жабовский байткод, декомпиль(не в жабу, а в читабельный вид — асм байткода — http://www.varaneckas.com/jad), листинги в студию.
E__>А я напишу это же на жабе, и сделаю то же самое. И сравним на низком уровне, что вышло. Там сразу видно будет, байткод очень простой для понимания.

Не, лично я с ним ещё не работал. Пока просто интересуюсь.

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

PD>>>>Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее.

DL>>>А может стоило попробовать реализацию питона под джаву: Jython?

DL>>>Мне кстати самому интересно, как соотносятся про производительности Jython и Java.

E__>>А мне интересно, во что скомпилится этот Jython. Напиши какой-нибудь код под него(пусть будет простой — с математикой, хотя можно добавить пару фирменных фишек Питона), скомпиль в жабовский байткод, декомпиль(не в жабу, а в читабельный вид — асм байткода — http://www.varaneckas.com/jad), листинги в студию.
E__>>А я напишу это же на жабе, и сделаю то же самое. И сравним на низком уровне, что вышло. Там сразу видно будет, байткод очень простой для понимания.

DL>Не, лично я с ним ещё не работал. Пока просто интересуюсь.

А с Питоном? Я просто в нем ни бум-бум, и мой первый код врядли будет адекватен. Если есть просто код на Питоне, я сам займусь, мне же интересно. А на дворе пятница, спать я долго не планирую.

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

E__>Здравствуйте, D.Lans, Вы писали:

PD>>>>>Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее.

DL>>>>А может стоило попробовать реализацию питона под джаву: Jython?

DL>>>>Мне кстати самому интересно, как соотносятся про производительности Jython и Java.

E__>>>А мне интересно, во что скомпилится этот Jython. Напиши какой-нибудь код под него(пусть будет простой — с математикой, хотя можно добавить пару фирменных фишек Питона), скомпиль в жабовский байткод, декомпиль(не в жабу, а в читабельный вид — асм байткода — http://www.varaneckas.com/jad), листинги в студию.
E__>>>А я напишу это же на жабе, и сделаю то же самое. И сравним на низком уровне, что вышло. Там сразу видно будет, байткод очень простой для понимания.

DL>>Не, лично я с ним ещё не работал. Пока просто интересуюсь.

E__>А с Питоном? Я просто в нем ни бум-бум, и мой первый код врядли будет адекватен. Если есть просто код на Питоне, я сам займусь, мне же интересно. А на дворе пятница, спать я долго не планирую.

Только начинаю изучать.

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

DL>А может стоило попробовать реализацию питона под джаву: Jython?

В моей задаче не стоило. Надо было просто перевести код на Яву. Python code в production не пойдет.

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

TSP>>А откуда такая любовь к нативному коду? Очень много программ, которые проще было бы реализовать меньшими силами на той же/*том же?*/ Java.
_>Да. Но есть задачи где без нейтива никак не обойтись. Отсюда и любовь, на нейтиве можно написать вообще все что угодно, конечно, возможно что с большими трудозатратами.

Вот представь, что ты хочешь написать что-то для ARMа, а твой SuperNativeCSharp умеет генерировать код только для x86, причём у него даже есть некие проблемы с 64 разрядными приложениями. Те, кто развивают этот язык говорят, что лет через 7 может добавят поддержку ещё какой-нибудь платформы.

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

A>А нафига новые языки с компиляцией в нативный код? Всё чаще нужна именно скорость разработаки и удобство сопровождения, а не скорость расчётов. Вот у меня в коллекции есть хорошая ссылочка:
A>http://www.stockme.ru/rus/blogs/document3110.phtml

Внутренняя задержка 500 микросекунд

Что-то очень на враньё похоже, щедулер при 1000Hz даст время переключения 1 мл.сек. + нужно ещё посчитать квант процесса + нужно добавить погрешность переключения (в среднем от 0.5 до 1 тика) т.е. до 1 мл.сек. + время задержки в TCP/IP стеке (алгоритм Нагла может задержать пакеты, установка соединения и т.п.). Итого, не может быть внутренняя задержка меньше 2 мл.сек.

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

Ф>дискредитировал себя не нативный код, а С'стайл в C++

И потому глючат даже сишные проги и проги на дельфях всяких ?

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

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

J>>А нативщикам остается писать начинку, которой будет рулить какой-нть скрипт, и этот скрипт предоставит удобный и прозрачный DSL для решаемой задачи.
J>>И это хорошо.
J>>И пусть таких языков будет больше — людям жить будет легче, и программить смогут даже админы (перл, питон), которым для их поделок нафиг не нужны вяские петтерны и прочие радости "настоящего" программирования.
SN>Легкость разработки и компиляция/интерпретация это вообще ортогональные понятия.

Оно, конечно, да, только вот о компиляции/интерпретации тут никто не говорит, речь идет о нативности.
А нативность означает, что язык должен иметь дело с потрохами платформы, иначе это не нативность никакая, а просто компилируемость в машкоды.
А это никогда легким не назовешь, если только платформа не заточена под это специально (см. послание Лаптева о виртуальных машинах рядом).

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

I>Здравствуйте, Философ, Вы писали:

Ф>>дискредитировал себя не нативный код, а С'стайл в C++

I>И потому глючат даже сишные проги и проги на дельфях всяких ?

И потому же глючат шарповые проги и проги на VBNet'ах всяких

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

I>Здравствуйте, Философ, Вы писали:

I>>>И потому глючат даже сишные проги и проги на дельфях всяких ?

Ф>>И потому же глючат шарповые проги и проги на VBNet'ах всяких

I>Глючат. Но таких проблем с указателями и близко нет.

О!
Таки дошли/добрались до корня зла.
Ну и при чём здесь нативный/не нативный?

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

S>Что-то очень на враньё похоже, щедулер при 1000Hz даст время переключения 1 мл.сек. + нужно ещё посчитать квант процесса + нужно добавить погрешность переключения (в среднем от 0.5 до 1 тика) т.е. до 1 мл.сек. + время задержки в TCP/IP стеке (алгоритм Нагла может задержать пакеты, установка соединения и т.п.). Итого, не может быть внутренняя задержка меньше 2 мл.сек.

Сорри, не специалист в этом.

Опять же — тут неясно точно что они имели в виду под этим параметром — тут есть варианты.

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

A>Опять же — тут неясно точно что они имели в виду под этим параметром — тут есть варианты.

Тут всё однозначно, внутренняя задержка и время реакции разные вещи и перепутать человек который знает о чём говорит их не мог.

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

Ф>cpp — мутант переходного периода, и должен умереть

Тестовое задание C++ win

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

Скрытый текст

A>Здравствуйте.
A>При попытке устроится в одну фирму прислали "удалённое" тестовое задание.

A>

A>Какие проблемы Вы видите в этих фрагментах кода и как предлагаете их решать?
A>1.
A>void g( char *, char *, size_t );
A>void f( size_t n )
A>{
A> char *a = new char[n];
A> char *b = new char[n];
A> g( a, b, n );
A> delete [] b;
A> delete [] a;
A>}

A>2.
A>int main(int argc, char* argv[])
A>{
A> if( argc > 1 )
A>  printf( argv[1] );
A> return 0;
A>}

A>

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

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

I>>Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.

Ф>дискредитировал себя не нативный код, а С'стайл в C++
+1

Ф>cpp — мутант переходного периода, и должен умереть
А это к чему?
Ты таки считаешь, что должен умереть С'стайл в C++ (с чем я полностью согласен), или весь С++ (с чем я не согласен)?

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

P>А ты запускал VC6 на Pentium-100 с 16M оперативы?
запускал на 486dx 100MHz с 24М, работало дововольно шустро, но сравнивать с 2010й студией не стоит

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

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

PD>Python — интерпретатор, плагин к эклипсу для Python 2.7. Для Явы — эклпипс.

Я имел ввиду, жаба с ключиком -server или нет? Это в числодробилках очень важно.

E__>>А еще есть управление памятью. Которое очень сложный вопрос. В приложениях типа веба — шах и мат нативе.

PD>Вот тут согласен, но частично. Шах и мат не нативе, а нативе с указателями. Натива может вполне быть без указателей и со сборкой мусора, а тогда никакого шаха и мата не будет. Дело не в нативе vs. управляемый код, а в наличии или отсутствии сборки мусора.

Ну да, как-то так.

>>(непойманное исключение в жабошарпах ложит текущий поток обработки с записью в логи, в плюсах — весь сервер;

PD>Ну это совсем не обязательно, можно на С++ ловить необработанные исключения.

Можно. Но в общем случае у жабы поведение по умолчанию при непойманном исключении — сваливается проблемный поток, остальные ничего про это не знают. У плюсов — ну ты в курсе. То есть, даже если код одной странички на жабе писал студент, это не повлияет на код рядом, написанный профи.

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

Ф>>>Ну и при чём здесь нативный/не нативный?
I>>При том, что менеджет как правило не использует указатели. У многиъ программистов хронически не получается использовать указатели, софт тупо не взлетает или глючит. Эти же программисты худо бедно но рожают менеджет решения
MM>Ты считаешь это хорошо?

Я считаю, что бизнес в состоянии запустить столько проектов, сколько ему, бизнесу, требуется.

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

См. выше. Сколько будет проектов в разработке, решают вообще не разработчики, а люди из бизнеса.

>Такие программисты и в managed нафиг не нужны, потому что на выходе все-равно получается хрень. Реальная отдача от подобных "разработчиков" — головная боль для вменяемых программеров, которым рано или поздно, но приходится переделывать глюкалово, написанное без подключения головы.

Бизнес всё равно запустит проекты

I>>Эти же программисты худо бедно но рожают менеджет решения
BBI>Да да. Наши говнокодеры уже все у вас. Что изрядно улучшило стабльность native софта.

Ваших говнокодеров у нас нет

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

I>Я с этого и начинал. "Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.
I>"

Еще в случаях, когда ресурсы ограничены. Если у тебя девайс с 64К оперативы(а таковых еще дочерта, на наш век хватит), то ни о каких жабошарпах речи нет. Только чистый С. Но там и сложность не та. Никто не требует от портативного автомата по печати билетов, например(для кондуктора) 3Д интерфейса и всяких плюшек. Там хватит обычного текста. И в таких девайсах не будет еще долго гигабайт памяти и супер-пупер проца. Потому что батарейка. Ну и цена.

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

I>>Я с этого и начинал. "Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.
I>>"

E__>Еще в случаях, когда ресурсы ограничены. Если у тебя девайс с 64К оперативы(а таковых еще дочерта, на наш век хватит), то ни о каких жабошарпах речи нет.

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

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

A>Вот представь, что ты хочешь написать что-то для ARMа, а твой SuperNativeCSharp умеет генерировать код только для x86, причём у него даже есть некие проблемы с 64 разрядными приложениями. Те, кто развивают этот язык говорят, что лет через 7 может добавят поддержку ещё какой-нибудь платформы.
Вот что мне нравится в подобного рода дискуссиях так это предложения представить какой-то там гипотетический случай. А нафига? Не сомневаюсь что есть случаи когда управляемый код рулит. Однако у меня есть в наличии реальнейшие задачи где в обозримом будущем нейтив непобедим как чак норрис. В основном это работа со сторонними аппликациями в целях интеграции и автоматизации, хуки, перехваты api (причем не только системных) и т.п. Есть клиент с программой на QT, написаной и поддерживаемой какими-то там индусами. Нужно пошерудить в ее гуе на предмет получения информации и автоматизации. Мне хук на джаве писать что-ли?

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

I>>Это как раз вписывается в "низкоуровневый контроль ресурсов". Низкий контроль нужен когда много всяких ограничений, объемы, скорость и тд и тд и тд при чем под эти ограничений нет готовых инструментов и все нужно делать руками.

E__>Да нету там никакого контроля ресурсов(ну, кроме контроля модема через АТ команды, и принтера через POS), просто аккуратное написание кода на С, чтобы не вылезти за предел памяти. Учитывая, что графики нет, 64К хватает с головой.

И давно на 64к память перестала быть ресурсом ?

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

E__>В явах/шарпах еще, что очень важно, при почти любой ошибке максимум свалится текущий поток, а не все приложение. Если потоки практически независимы(а это именно так в подавляющем большинстве веб-приложений), то другие треды просто не заметят падения собрата. В тех же плюсах непойманное исключение в любом потоке ложит весь сервер.

Насколько понимаю, в С/С++ это можно победить при помощи форка процесса и передачи информации между процессами при помощи сообщений?

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

A>>Вот представь, что ты хочешь написать что-то для ARMа, а твой SuperNativeCSharp умеет генерировать код только для x86, причём у него даже есть некие проблемы с 64 разрядными приложениями. Те, кто развивают этот язык говорят, что лет через 7 может добавят поддержку ещё какой-нибудь платформы.
_>Вот что мне нравится в подобного рода дискуссиях так это предложения представить какой-то там гипотетический случай. А нафига? Не сомневаюсь что есть случаи когда управляемый код рулит.

Это не гипотетический случай, а очень важный вопрос, который обязательно должны рассматривать разработчики языка. И вся поддержка других платформ (а они сейчас становятся более популярными всвязи с наличием кучи мобильных устройств) ложится на плечи разработчиков. Так что проще генерировать что-то промежуточное. Хотя бы тот же LLVM.

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

A>>>Вот представь, что ты хочешь написать что-то для ARMа, а твой SuperNativeCSharp умеет генерировать код только для x86, причём у него даже есть некие проблемы с 64 разрядными приложениями. Те, кто развивают этот язык говорят, что лет через 7 может добавят поддержку ещё какой-нибудь платформы.
_>>Вот что мне нравится в подобного рода дискуссиях так это предложения представить какой-то там гипотетический случай. А нафига? Не сомневаюсь что есть случаи когда управляемый код рулит.

A>Это не гипотетический случай, а очень важный вопрос, который обязательно должны рассматривать разработчики языка. И вся поддержка других платформ (а они сейчас становятся более популярными всвязи с наличием кучи мобильных устройств) ложится на плечи разработчиков. Так что проще генерировать что-то промежуточное. Хотя бы тот же LLVM.
Для меня неважный и гипотетический. Разработчики языков и разработчики пытающиеся писать разом для всех платформ пусть этим и озадачиваются. А пока в итерпрайзе на десктопах рулит windows. Настоящая кросплатформенность нужна имхо в очень редких случаях, и тут безусловно java вполне оправданный выбор.

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

I>>Это абсолютно несущественная разница. Если прогарммист не осилил указатели, то эта особенность указателей проявится во всех фрагментах его кода.

L>Нет, разница существенная. Ниасиливший простейшую концепцию контроля за ресурсами программист банально профнепригоден.

Эдак все С++ программисты станут профнепригодными. Не знаю ни одного серьезного проекта где бы не было ошибок с указателями.

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

L>>Нет, разница существенная. Ниасиливший простейшую концепцию контроля за ресурсами программист банально профнепригоден.

I>Эдак все С++ программисты станут профнепригодными. Не знаю ни одного серьезного проекта где бы не было ошибок с указателями.

А я знаю. Зато я не знаю ни одного серьезного проекта на .NET, который бы по срокам не пролетел минимум в два раза. На нем же так просто и быстро разрабатывать!

P.S. А эа выделенное в приличном обществе можно и канделябром огрести.

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

I>>Эдак все С++ программисты станут профнепригодными. Не знаю ни одного серьезного проекта где бы не было ошибок с указателями.

L>А я знаю. Зато я не знаю ни одного серьезного проекта на .NET, который бы по срокам не пролетел минимум в два раза. На нем же так просто и быстро разрабатывать!

Думаешь на С++ лучше ?

L>P.S. А эа выделенное в приличном обществе можно и канделябром огрести.

Это ж ты решил записать в профнепригодных людей, которые ошибки с указателями делают. Канделябр найдёшь или выслать ?

Ф>>>Ну и при чём здесь нативный/не нативный?
I>>При том, что менеджет как правило не использует указатели. У многиъ программистов хронически не получается использовать указатели, софт тупо не взлетает или глючит. Эти же программисты худо бедно но рожают менеджет решения
MM>Ты считаешь это хорошо? Ты считаешь, что непонимание одной из базовых концепций не то что программирования,

Каким боком указатели относятся к базовым концепциям программирования?

MM>а вообще — функцинирования компьютеров — это нормально для разработчика?

Каким боком указатели относятся к базовым концепциям работы компьютера?

MM>Это отстой. Такие программисты и в managed нафиг не нужны, потому что на выходе все-равно получается хрень. Реальная отдача от подобных "разработчиков" — головная боль для вменяемых программеров, которым рано или поздно, но приходится переделывать глюкалово, написанное без подключения головы.

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

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

M>Каким боком указатели относятся к базовым концепциям программирования?
Указатель это адресация памяти.

MM>>а вообще — функцинирования компьютеров — это нормально для разработчика?
M>Каким боком указатели относятся к базовым концепциям работы компьютера?
Оперативная память и работа с ней — базовые понятия работы компа.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

M>>Каким боком указатели относятся к базовым концепциям программирования?
BBI>Указатель это адресация памяти.

И? Это не ответ на мой вопрос.

MM>>>а вообще — функцинирования компьютеров — это нормально для разработчика?
M>>Каким боком указатели относятся к базовым концепциям работы компьютера?
BBI>Оперативная память и работа с ней — базовые понятия работы компа.

Оперативная память — да. Работа с ней — нет. Понимание работы VM .NET'а может много в плане понимания работы компьютера и его оперативной памяти ... безо всяких указателей вообще. Ну или с указателями, но без участия С++ и его понимания указателей.

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

MM>>Ты считаешь это хорошо? Ты считаешь, что непонимание одной из базовых концепций не то что программирования,
M>Каким боком указатели относятся к базовым концепциям программирования?
Послушай, ты же прекрасно понимаешь, что я имею ввиду. Давай возьмем хотя-бы C# — уж самый что ни на есть managed язык. Ну и? Даже в нем требуется понимание указателей. Ну, или ссылок, в этой терминологии я всегда плаваю. Человек должен уметь отличать Value type от Reference type, а это уже требует понимание сути указателя: есть адрес, а есть значение по этому адресу.

MM>>а вообще — функцинирования компьютеров — это нормально для разработчика?
M>Каким боком указатели относятся к базовым концепциям работы компьютера?
Дык, елы-палы. А какой был смысл в переходе на x64? Помнишь, что означает цифра 64?

M>Отстой получается из программистов, которые не знают реально базовых концепций программирования.
Вот это как раз не столь критично, потому что для большинства алгоритмов код давно уже написан.

MM>>>Ты считаешь это хорошо? Ты считаешь, что непонимание одной из базовых концепций не то что программирования,
M>>Каким боком указатели относятся к базовым концепциям программирования?
MM>Послушай, ты же прекрасно понимаешь, что я имею ввиду.

Нет, не понимаю.

MM> Давай возьмем хотя-бы C# — уж самый что ни на есть managed язык. Ну и? Даже в нем требуется понимание указателей. Ну, или ссылок, в этой терминологии я всегда плаваю. Человек должен уметь отличать Value type от Reference type, а это уже требует понимание сути указателя: есть адрес, а есть значение по этому адресу.

Эти понятия немного отличаются от указателей/ссылок в С++, не находишь? Настолько, что ты сам плаваешь в понятиях указатель/ссылка

MM>>>а вообще — функцинирования компьютеров — это нормально для разработчика?
M>>Каким боком указатели относятся к базовым концепциям работы компьютера?
MM>Дык, елы-палы. А какой был смысл в переходе на x64? Помнишь, что означает цифра 64?

Расширение адресного пространства, доступного приложениям. Да-да-да, указатели. Только отношения к указателям в C/C++ и другим языкам они не имеют вообще никакого.

M>>Отстой получается из программистов, которые не знают реально базовых концепций программирования.
MM>Вот это как раз не столь критично, потому что для большинства алгоритмов код давно уже написан.

Угу. Вот и получим в итоге говнопрограммистов, которые только и умеют делать, что копипастить/дергать чужой код без понимания, как он работает. Не говоря уже о том, что любая программа — это набор алгоритмов. Скажешь, для всех программ уже есть готовый код? Тогда чем мы занимаемся?

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

M>>Каким боком указатели относятся к базовым концепциям программирования?
MM>Послушай, ты же прекрасно понимаешь, что я имею ввиду. Давай возьмем хотя-бы C# — уж самый что ни на есть managed язык. Ну и? Даже в нем требуется понимание указателей. Ну, или ссылок, в этой терминологии я всегда плаваю. Человек должен уметь отличать Value type от Reference type, а это уже требует понимание сути указателя: есть адрес, а есть значение по этому адресу.

Ссылка и указатель это две большие разницы. Указатель включает в себя ссылки. А вот адреса и всякой всячины с этим связаной в ссылках нет и быть не может. Есть идентити — т.е. ответ на вопрос, две ссылки это один и тот же объект или разные. Все.

M>>Отстой получается из программистов, которые не знают реально базовых концепций программирования.
MM>Вот это как раз не столь критично, потому что для большинства алгоритмов код давно уже написан.

Нужно решение задач, а не написание кода алгоритмов. Специфика работы программиста в тмо, что надо решать новые задачи. А код для алгоритмов можешь брать где угодно.

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

M>Оперативная память — да. Работа с ней — нет.
Драсте.

M>Понимание работы VM .NET'а может много в плане понимания работы компьютера и его оперативной памяти
Аха. Сколько дотнетчиков понимают как реально внутри устроена VM и как она работает? 1% или ещё меньше?

M> безо всяких указателей вообще.
Да ты шо. Т.е. в .NET runtime нет ни единой переменной, в которой бы хранился адрес чего либо?
Просто фантастика. Пешы ищё!

M>Ну или с указателями, но без участия С++ и его понимания указателей.
Расскажи нам лучше на чём написана VM дотнета.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

M>>>Каким боком указатели относятся к базовым концепциям программирования?
MM>>Послушай, ты же прекрасно понимаешь, что я имею ввиду.
M>Нет, не понимаю.
В этом то и проблема.

MM>> Давай возьмем хотя-бы C# — уж самый что ни на есть managed язык. Ну и? Даже в нем требуется понимание указателей. Ну, или ссылок, в этой терминологии я всегда плаваю. Человек должен уметь отличать Value type от Reference type, а это уже требует понимание сути указателя: есть адрес, а есть значение по этому адресу.
M>Эти понятия немного отличаются от указателей/ссылок в С++, не находишь?
Суть та же.

M>Расширение адресного пространства, доступного приложениям. Да-да-да, указатели.
M>Только отношения к указателям в C/C++ и другим языкам они не имеют вообще никакого.
И каким это образом?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

MM>> Давай возьмем хотя-бы C# — уж самый что ни на есть managed язык. Ну и? Даже в нем требуется понимание указателей. Ну, или ссылок, в этой терминологии я всегда плаваю. Человек должен уметь отличать Value type от Reference type, а это уже требует понимание сути указателя: есть адрес, а есть значение по этому адресу.
M>Эти понятия немного отличаются от указателей/ссылок в С++, не находишь? Настолько, что ты сам плаваешь в понятиях указатель/ссылка

Ikemefula написал про указатели в общем смысле, никакого уточнения о специфике С++ сказано не было

Если он имеет ввиду какие-то особенности, то стоит уточнить

M>>>Отстой получается из программистов, которые не знают реально базовых концепций программирования.
MM>>Вот это как раз не столь критично, потому что для большинства алгоритмов код давно уже написан.
M>Угу. Вот и получим в итоге говнопрограммистов, которые только и умеют делать, что копипастить/дергать чужой код без понимания, как он работает. Не говоря уже о том, что любая программа — это набор алгоритмов. Скажешь, для всех программ уже есть готовый код? Тогда чем мы занимаемся?
Скажу, что это не отменяет проблему непонимания указателей.

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

L>Много чести. Ниасилившие указатели прекрасно справляются со стрельбой по собственным ногам даже в управлямых языках.

Указатели, вроде как, осилил, проблем никогда не было. Но вот за несколько лет программирования на скриптовых языках под веб мне ни разу указатели не помогли.

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

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

Ф>>>Ну и при чём здесь нативный/не нативный?
I>>При том, что менеджет как правило не использует указатели. У многиъ программистов хронически не получается использовать указатели, софт тупо не взлетает или глючит. Эти же программисты худо бедно но рожают менеджет решения
MM>Ты считаешь это хорошо? Ты считаешь, что непонимание одной из базовых концепций не то что программирования, а вообще — функцинирования компьютеров — это нормально для разработчика? Это отстой. Такие программисты и в managed нафиг не нужны, потому что на выходе все-равно получается хрень. Реальная отдача от подобных "разработчиков" — головная боль для вменяемых программеров, которым рано или поздно, но приходится переделывать глюкалово, написанное без подключения головы.

Лучше готовая и работающая, хоть и глючная программа, чем то что падает при старте.

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

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

A>>Вот представь, что ты хочешь написать что-то для ARMа, а твой SuperNativeCSharp умеет генерировать код только для x86, причём у него даже есть некие проблемы с 64 разрядными приложениями. Те, кто развивают этот язык говорят, что лет через 7 может добавят поддержку ещё какой-нибудь платформы.
_>Вот что мне нравится в подобного рода дискуссиях так это предложения представить какой-то там гипотетический случай. А нафига? Не сомневаюсь что есть случаи когда управляемый код рулит. Однако у меня есть в наличии реальнейшие задачи где в обозримом будущем нейтив непобедим как чак норрис. В основном это работа со сторонними аппликациями в целях интеграции и автоматизации, хуки, перехваты api (причем не только системных) и т.п. Есть клиент с программой на QT, написаной и поддерживаемой какими-то там индусами. Нужно пошерудить в ее гуе на предмет получения информации и автоматизации. Мне хук на джаве писать что-ли?

Хук можно написать на .NET. Вернее создать либу на C++\CLI, сделать в ней хук (или взять готовую), а из нее вызывать C#.

Кстати может лучше не гуй ковырять, а хранимые данные?

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

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

MM>>>Ты считаешь это хорошо? Ты считаешь, что непонимание одной из базовых концепций не то что программирования,
M>>Каким боком указатели относятся к базовым концепциям программирования?
MM>Послушай, ты же прекрасно понимаешь, что я имею ввиду. Давай возьмем хотя-бы C# — уж самый что ни на есть managed язык. Ну и? Даже в нем требуется понимание указателей. Ну, или ссылок, в этой терминологии я всегда плаваю. Человек должен уметь отличать Value type от Reference type, а это уже требует понимание сути указателя: есть адрес, а есть значение по этому адресу.

Ссылка, и значение по ссылке. В отличие от указателей не может быть ссылок на ссылки, арифметики ссылок итп. То что ссылка == адрес в документации ничего не фигурирует. Это оставляет возможность проводить многие оптимизации, например размещение объектов в стеке. Если понимать ссылку как адрес в управляемой куче, то это во многом ограничивает CLR.

Видишь, ты зная указатели не понимаешь ссылки в .NET.

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

M>>Понимание работы VM .NET'а может много в плане понимания работы компьютера и его оперативной памяти
BBI>Аха. Сколько дотнетчиков понимают как реально внутри устроена VM и как она работает? 1% или ещё меньше?

M>>Ну или с указателями, но без участия С++ и его понимания указателей.
BBI>Расскажи нам лучше на чём написана VM дотнета.

Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.

MM>>> Давай возьмем хотя-бы C# — уж самый что ни на есть managed язык. Ну и? Даже в нем требуется понимание указателей. Ну, или ссылок, в этой терминологии я всегда плаваю. Человек должен уметь отличать Value type от Reference type, а это уже требует понимание сути указателя: есть адрес, а есть значение по этому адресу.
M>>Эти понятия немного отличаются от указателей/ссылок в С++, не находишь? Настолько, что ты сам плаваешь в понятиях указатель/ссылка

MM>Ikemefula написал про указатели в общем смысле, никакого уточнения о специфике С++ сказано не было

Если он имеет ввиду какие-то особенности, то стоит уточнить

ТОгда забываем слово указатели и говорим об архитектуре компьютера.

M>>>>Отстой получается из программистов, которые не знают реально базовых концепций программирования.
MM>>>Вот это как раз не столь критично, потому что для большинства алгоритмов код давно уже написан.
M>>Угу. Вот и получим в итоге говнопрограммистов, которые только и умеют делать, что копипастить/дергать чужой код без понимания, как он работает. Не говоря уже о том, что любая программа — это набор алгоритмов. Скажешь, для всех программ уже есть готовый код? Тогда чем мы занимаемся?
MM>Скажу, что это не отменяет проблему непонимания указателей.

При чем тут указатели?

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

A>>>Вот представь, что ты хочешь написать что-то для ARMа, а твой SuperNativeCSharp умеет генерировать код только для x86, причём у него даже есть некие проблемы с 64 разрядными приложениями. Те, кто развивают этот язык говорят, что лет через 7 может добавят поддержку ещё какой-нибудь платформы.
_>>Вот что мне нравится в подобного рода дискуссиях так это предложения представить какой-то там гипотетический случай. А нафига? Не сомневаюсь что есть случаи когда управляемый код рулит. Однако у меня есть в наличии реальнейшие задачи где в обозримом будущем нейтив непобедим как чак норрис. В основном это работа со сторонними аппликациями в целях интеграции и автоматизации, хуки, перехваты api (причем не только системных) и т.п. Есть клиент с программой на QT, написаной и поддерживаемой какими-то там индусами. Нужно пошерудить в ее гуе на предмет получения информации и автоматизации. Мне хук на джаве писать что-ли?

G>Хук можно написать на .NET. Вернее создать либу на C++\CLI, сделать в ней хук (или взять готовую), а из нее вызывать C#.
Можно конечно, но зачем? Нафига тянуть с собой все дллки нета если сама таргет-аппликация их не использует? Тем более в случае с QT, тут хук должен быть qt-длл. Есть у нас нетовые хуки и джавовые, они используються там где это необходимо.
G>Кстати может лучше не гуй ковырять, а хранимые данные?
Конечно лучше, но во первых практически никогда этого не разрешают, а в вторых иногда бывает нужно автоматизировать гуй или вмешаться во взаимодействие ползователя с гуем, контролировать ввод до того как он сохранился и т.п. Кроме того есть чисто политические моменты, опыт показывает что любой доступ к данным помимо гуя требует согласования с отделом IT клиента на слишком ранних стадиях проекта. Для IT лишний гемор не нужен у них и так все работает и новые приблуды им не нужны, поэтому часто бывает что преждевременный контакт с IT губит проект на корню. Проще через бизнес все сделать, показать бизнес-менеджерам возможность добавить необходимую им бизнес функциональность всего-лишь установив на десктопе маленькую программу.

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

L>>>А я знаю. Зато я не знаю ни одного серьезного проекта на .NET, который бы по срокам не пролетел минимум в два раза. На нем же так просто и быстро разрабатывать!

I>>Думаешь на С++ лучше ?

L>Думаешь? Я знаю. У нас сроки всегда выдерживаются.

У нас тоже

L>>>P.S. А эа выделенное в приличном обществе можно и канделябром огрести.
I>>Это ж ты решил записать в профнепригодных людей, которые ошибки с указателями делают. Канделябр найдёшь или выслать ?
L>Много чести. Ниасилившие указатели прекрасно справляются со стрельбой по собственным ногам даже в управлямых языках.

Это мягко говоря далеко от истины.

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

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

L>>Много чести. Ниасилившие указатели прекрасно справляются со стрельбой по собственным ногам даже в управлямых языках.

M>Указатели, вроде как, осилил, проблем никогда не было. Но вот за несколько лет программирования на скриптовых языках под веб мне ни разу указатели не помогли.

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

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

I>>>Думаешь на С++ лучше ?

L>>Думаешь? Я знаю. У нас сроки всегда выдерживаются.

I>У нас тоже

Поздравляю.

L>>Много чести. Ниасилившие указатели прекрасно справляются со стрельбой по собственным ногам даже в управлямых языках.

I>Это мягко говоря далеко от истины.

Выборка, наверное, нерепрезентативная.

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

I>Понадобились многие годы что бы пофиксить

Но вообще — валятся. Смотри дыры в безопасности где всякие срывы стека.
Ну так а говорите "не видел". И не только про браузеры речь, на десктопе хватает нативного достаточно стабильного софта.
>>А баги они везде бывают, и нетовые программы тоже вылетают по ексцепшинам и бывает что память и них течет, это просто менее заметно ввиду малого распостранения подобных программ на десктопе.

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

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

L>>>Много чести. Ниасилившие указатели прекрасно справляются со стрельбой по собственным ногам даже в управлямых языках.
M>>Указатели, вроде как, осилил, проблем никогда не было. Но вот за несколько лет программирования на скриптовых языках под веб мне ни разу указатели не помогли.
L>Скриптовые языки и веб, где скоп живет считанные миллисекунды есть весьма отдельный случай. Но и там стрельба по ногам встречается чаще, чем хотелось бы.

Такая стрельба это норма у свежемигрировавших сиплюсников

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

I>Хватает. Сколько времени было затрачено на фиксы багов с указателями ?
Ну слава богу хоть удалось разглядеть серьезные нативные стабильные проекты

"Сколько времени" это важно? Полагаю что это время не определялось только фиксом багов именно с указателями. Тот кто оные программы делал мог себе позволить столько времени сколько нужно, и пока не видно особой тенденции на менеджет переписывать(разве что VS2010).

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

G>Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.
Это ты Мамуту тайны открывай.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

g> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.

CLR является виртуальной машиной .NET

avalon 1.0rc3 build 428, zlib 1.2.3

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

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

g>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.

H>CLR является виртуальной машиной .NET

Где такой бред прочитал? Runtime != VM. Ты еще скажи что CRT — виртуальная машина C.

g>>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.

H>>CLR является виртуальной машиной .NET

G>Где такой бред прочитал? Runtime != VM. Ты еще скажи что CRT — виртуальная машина C.

The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET framework and is responsible for managing the execution of .NET programs. In a process known as just-in-time (JIT) compilation, the CLR compiles the intermediate language code known as CIL into the machine instructions that in turn are executed by the computer's CPU.

Не?

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

g>>>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.

H>>>CLR является виртуальной машиной .NET

G>>Где такой бред прочитал? Runtime != VM. Ты еще скажи что CRT — виртуальная машина C.

M>

M>The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET framework and is responsible for managing the execution of .NET programs. In a process known as just-in-time (JIT) compilation, the CLR compiles the intermediate language code known as CIL into the machine instructions that in turn are executed by the computer's CPU.

M>Не?

Это где написано? Не в википедии случайно?

g>>>>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.

H>>>>CLR является виртуальной машиной .NET

G>>>Где такой бред прочитал? Runtime != VM. Ты еще скажи что CRT — виртуальная машина C.

M>>

M>>The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET framework and is responsible for managing the execution of .NET programs. In a process known as just-in-time (JIT) compilation, the CLR compiles the intermediate language code known as CIL into the machine instructions that in turn are executed by the computer's CPU.

M>>Не?

G>Это где написано? Не в википедии случайно?

В ней, родимой

С другой стороны, что там неправильно?

То же самое, только другими словами и старательно избегая слова виртуальная машина написано и тут: http://msdn.microsoft.com/en-us/library/8bs2ecf4.aspx

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

I>>Хватает. Сколько времени было затрачено на фиксы багов с указателями ?
_>Ну слава богу хоть удалось разглядеть серьезные нативные стабильные проекты

"Сколько времени" это важно? Полагаю что это время не определялось только фиксом багов именно с указателями.

"на фиксы багов с указателями " время определялось не токльо фиксом таких багов ? Ну и дела

>Тот кто оные программы делал мог себе позволить столько времени сколько нужно, и пока не видно особой тенденции на менеджет переписывать(разве что VS2010).

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

g>>>>>>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.

H>>>>>>CLR является виртуальной машиной .NET

G>>>>>Где такой бред прочитал? Runtime != VM. Ты еще скажи что CRT — виртуальная машина C.

M>>>>

M>>>>The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET framework and is responsible for managing the execution of .NET programs. In a process known as just-in-time (JIT) compilation, the CLR compiles the intermediate language code known as CIL into the machine instructions that in turn are executed by the computer's CPU.

M>>>>Не?

G>>>Это где написано? Не в википедии случайно?

M>>В ней, родимой

M>>С другой стороны, что там неправильно?

То же самое, только другими словами и старательно избегая слова виртуальная машина написано и тут: http://msdn.microsoft.com/en-us/library/8bs2ecf4.aspx

G>И ведь не зря "старательно избегая". Ведь CLR описан как спецификация для VM, хотя физически VM отсуствует. Все компилируется в нативный код JIT, который полностью удовлетворяет спецификации.

Ну тут уже начинаются философские споры, на самом деле

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

I>>>Хватает. Сколько времени было затрачено на фиксы багов с указателями ?
_>>Ну слава богу хоть удалось разглядеть серьезные нативные стабильные проекты

"Сколько времени" это важно? Полагаю что это время не определялось только фиксом багов именно с указателями.

I>"на фиксы багов с указателями " время определялось не токльо фиксом таких багов ? Ну и дела

Ну да, дела.

Есть какая-то статистика о количестве времени потраченном на фиксы багов связанных именно с памятью хотя-бы по какому либо продукту? Ваш вопрос "Сколько времени было затрачено на фиксы багов с указателями ?" смысла не имеет, и даже сами производители вряд-ли на него точно ответят. Можете считать что вся команда VS или хрома от релиза к релизу только и занималась тем что боролась с указателями.

>>Тот кто оные программы делал мог себе позволить столько времени сколько нужно, и пока не видно особой тенденции на менеджет переписывать(разве что VS2010).

I>Это не из за того, что С++ такой крутой, а потому что большие проекты переписывать слишком дорого с любого языка на любой.
Естественно, это тоже вполне себе причина, как и то что менеджет недостаточно крут что бы использовать его универсальное лекарство от всех проблем.

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

g> g>> Открою тайну. В.NET нету VM. Весь .NET код компилируется в native перед исполнением.

g> H>CLR является виртуальной машиной .NET

g> Где такой бред прочитал? Runtime != VM.

Одно уже наличие байткода говорит об этом. Попробуй подумать. Наличие виртуальной машины ни коим образом не указывает на интерпретацию байткода (если ты, вдруг, об этом), это, вообще говоря, сугубо личное дело самой ВМ, как его исполнять. CLR джитит, и Java тоже джитит. Хоть википедию почитай, что ли

g> Ты еще скажи что CRT — виртуальная машина C.

Ты не отличаешь исполняющую среду (CLR) от библиотеки времени исполнения (CRT)?

Скрытый текст

Ходим сюда и видим прикольные такие пути:

AppDomain    \sscli\clr\src\vm\appdomain.hpp
AppDomainStringLiteralMap    \sscli\clr\src\vm\stringliteralmap.h
BaseDomain    \sscli\clr\src\vm\appdomain.hpp
ClassLoader    \sscli\clr\src\vm\clsload.hpp
EEClass    \sscli\clr\src\vm\class.h
FieldDescs    \sscli\clr\src\vm\field.h
GCHeap    \sscli\clr\src\vm\gc.h
GlobalStringLiteralMap    \sscli\clr\src\vm\stringliteralmap.h
HandleTable    \sscli\clr\src\vm\handletable.h
InterfaceVTableMapMgr    \sscli\clr\src\vm\appdomain.hpp
Large Object Heap    \sscli\clr\src\vm\gc.h
LayoutKind    \sscli\clr\src\bcl\system\runtime\interopservices\layoutkind.cs
LoaderHeaps    \sscli\clr\src\inc\utilcode.h
MethodDescs    \sscli\clr\src\vm\method.hpp
MethodTables    \sscli\clr\src\vm\class.h
OBJECTREF    \sscli\clr\src\vm\typehandle.h
SecurityContext    \sscli\clr\src\vm\security.h
SecurityDescriptor    \sscli\clr\src\vm\security.h
SharedDomain    \sscli\clr\src\vm\appdomain.hpp
StructLayoutAttribute    \sscli\clr\src\bcl\system\runtime\interopservices\attributes.cs
SyncTableEntry    \sscli\clr\src\vm\syncblk.h 
System namespace    \sscli\clr\src\bcl\system
SystemDomain    \sscli\clr\src\vm\appdomain.hpp
TypeHandle    \sscli\clr\src\vm\typehandle.h

с такими говорящими vm

avalon 1.0rc3 build 428, zlib 1.2.3

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

G>И ведь не зря "старательно избегая". Ведь CLR описан как спецификация для VM, хотя физически VM отсуствует. Все компилируется в нативный код JIT, который полностью удовлетворяет спецификации.

В mono же и интерпретатор есть, так что зависит от реализации.

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

I>>В с++ коде есть такой класс багов, как баги с указателями. В менеджет его нет. В остальном все одинаково.

L>Нет такого класса багов. В принципе. Указатель — это просто число, накосячить с ним не просто.

Очень просто, чисто для демонстрации:

char *p;
strcpy(p,src);

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

во.

L>>Нет такого класса багов. В принципе. Указатель — это просто число, накосячить с ним не просто.

I>Очень просто, чисто для демонстрации:
I>

I>char *p;
I>strcpy(p,src);
I>

Хороший пример

Ну и за какое время сия хрень обнаруживается и фиксится?
Кстати если ms компилятором пользуетесь то нужно warning-и читать научиться. Есть там С4700 : "You used the local variable name without first assigning it a value, which could lead to unpredictable results."

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

I>>Очень просто, чисто для демонстрации:
I>>

I>>char *p;
I>>strcpy(p,src);
I>>

_> Хороший пример

Ну и за какое время сия хрень обнаруживается и фиксится?

Цитирую : "чисто для демонстрации"

_>Кстати если ms компилятором пользуетесь то нужно warning-и читать научиться. Есть там С4700 : "You used the local variable name without first assigning it a value, which could lead to unpredictable results."

Спасибо, капитан.

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

I>>>Очень просто, чисто для демонстрации:
I>>>

I>>>char *p;
I>>>strcpy(p,src);
I>>>

_>> Хороший пример

Ну и за какое время сия хрень обнаруживается и фиксится?

I>Цитирую : "чисто для демонстрации"
Хиленькая такая демонстрация, совсем не показывающая всей сложности использования чистых указателей.

Ошибка-то легко обнаруживается еще на этапе компиляции.

_>>Кстати если ms компилятором пользуетесь то нужно warning-и читать научиться. Есть там С4700 : "You used the local variable name without first assigning it a value, which could lead to unpredictable results."

I>Спасибо, капитан.
Пожайлуста.

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

_>Мне-то зачем что-то представлять? Это Вы тут пытаетесь напугать сообщество ужасными голыми указателями.

Я никого не пугаю, а говорю то, с чем пришлось сталкиваться копаясь в древних проектах писаными кем попало.

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

"убедить меня в обратном" — чушь. Я привел простейший пример для демонстрации проблемы.

>Никто не говорит что проблемы польностью отсутствуют.

Да ладно, тут двое утверждают что багов не бывает годами и что де проблема не в указателях а в руках

Кому из вас верить ?

I>>Очень просто, чисто для демонстрации:
I>>

I>>char *p;
I>>strcpy(p,src);
I>>

L>Бага с указателем не видно. Видно баг в /dev/brain и отовсюду торчат кривые hands.sys
L>Не говоря уже о том, что сейчас делают так

L>

L>std::string dst(pSrc);
L>

Ну а я что говорю?

_>Прямой доступ к памяти это преимущество с/c++, причем иногда абсолютно необходимое.

Преимущество по сравнению с чем?

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

_>>Прямой доступ к памяти это преимущество с/c++, причем иногда абсолютно необходимое.

M>Преимущество по сравнению с чем?
С языками которые этого не позволяют.

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

L>>Не говоря уже о том, что сейчас делают так

L>>

L>>std::string dst(pSrc);
L>>

M>Ну а я что говорю?

Несмотря на то, что std::string называть умным указателем это несколько неортодоксально, но разве кто-то возражает?

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

L>>>Нет такого класса багов. В принципе. Указатель — это просто число, накосячить с ним не просто.

I>>Очень просто, чисто для демонстрации:
I>>

I>>char *p;
I>>strcpy(p,src);
I>>

L>Бага с указателем не видно. Видно баг в /dev/brain и отовсюду торчат кривые hands.sys

д'Артаньян детектед

L>Не говоря уже о том, что сейчас делают так

L>

L>std::string dst(pSrc);
L>

Сколько тебе понадобится времени, что бы в древнем проекте 50-100мб пофиксить строки и прикрутить std:string ?

I>>Не надо там пытаться. Пример не сложнее предыдущего.
L>В моей команде тебе придется на уши встать и гопака на потолке станцевать, чтобы что-то отдаленно напоминающее приведенный выше прикол прошел код ревью.

Если ваша команда работает только со своим кодом, то так и будет. А совсем недавно товарищу пришел убитый проект на лялих++... Надо продолжать ?

L>>>Не говоря уже о том, что сейчас делают так

L>>>

L>>>std::string dst(pSrc);
L>>>

M>>Ну а я что говорю?

L>Несмотря на то, что std::string называть умным указателем это несколько неортодоксально, но разве кто-то возражает?

Ну, я возражаю против утверждений типа «почти никогда не видел в С++ проблем с указателями». Если не видел, обычно это значит, что используются любые средства, лишь бы таки не использовать эти самые указатели

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

I>Я никого не пугаю, а говорю то, с чем пришлось сталкиваться копаясь в древних проектах писаными кем попало.
Язык и библиотеки на месте не стоят.

Древние проекты не показатель имхо.
>>Вот и подгоняйте достоверные примеры неуловимых багов на указателях. Лично меня убеждать не нужно, я и так знаю с какими реальными багами приходится сталкиваться, и неправильная инициализация указателя вообще не входит в список часто встречающихся и трудно уловимых. Вы ж упорно пытаетесь убедить меня в обратном тупым примером.

I>"убедить меня в обратном" — чушь. Я привел простейший пример для демонстрации проблемы.

>>Никто не говорит что проблемы польностью отсутствуют.

I>Да ладно, тут двое утверждают что багов не бывает годами и что де проблема не в указателях а в руках

Кому из вас верить ?
В данном случае можете верить обоим. Большинство багов на свете происходят по причине либо кривых рук либо кривых мозгов. Ваш кэп. Я вполне могу поверить что в плюсовом проекте годами может не быть багов связанных с памятью.

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

L>>Несмотря на то, что std::string называть умным указателем это несколько неортодоксально, но разве кто-то возражает?

M>Ну, я возражаю против утверждений типа «почти никогда не видел в С++ проблем с указателями». Если не видел, обычно это значит, что используются любые средства, лишь бы таки не использовать эти самые указатели

Не совсем так. Используется устройство /dev/brain для определения правил владения объектами, их временем жизни и видимостью. Динамически создается только то, что должно создаваться динамически, а умные указатели используются для автоматического контроля временем жизни подобных объектов. Причем практически только в случаях совместного владения или когда владение должно передаваться, в остальных случаях достаточно RAII.

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

_>>>>Прямой доступ к памяти это преимущество с/c++, причем иногда абсолютно необходимое.

M>>>Преимущество по сравнению с чем?
_>>С языками которые этого не позволяют.

M>Голословно. В чем это преимущество выражается?
Очевидно что иногда бывает сильно нужно пошарить по памяти:
Как обратиться в внешнему Grid`у через API
Re: Как узнать какой процесс создал объект в ROT
и т.п.

L>>>Несмотря на то, что std::string называть умным указателем это несколько неортодоксально, но разве кто-то возражает?

M>>Ну, я возражаю против утверждений типа «почти никогда не видел в С++ проблем с указателями». Если не видел, обычно это значит, что используются любые средства, лишь бы таки не использовать эти самые указатели

L>Не совсем так. Используется устройство /dev/brain для определения правил владения объектами, их временем жизни и видимостью.

Ну это нужно вне зависимости от языка

L>Динамически создается только то, что должно создаваться динамически, а умные указатели используются для автоматического контроля временем жизни подобных объектов.

Ну дык

GC для бедных

L>Причем практически только в случаях совместного владения или когда владение должно передаваться, в остальных случаях достаточно RAII.

Пример можно?

Боюсь, в примере не будет

X *p = new X();
...
...
...
delete p;

а будет что-то типа

smart_ptr<X> p = new X();
...
...

Потому что именно так рекомендовано лучшими собаководами ©

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

L>>Бага с указателем не видно. Видно баг в /dev/brain и отовсюду торчат кривые hands.sys

I>д'Артаньян детектед

То есть по поводу кривых рук возражений не будет?

L>>Не говоря уже о том, что сейчас делают так

L>>

L>>std::string dst(pSrc);
L>>

I>Сколько тебе понадобится времени, что бы в древнем проекте 50-100мб пофиксить строки и прикрутить std:string ?

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

I>>>Не надо там пытаться. Пример не сложнее предыдущего.
L>>В моей команде тебе придется на уши встать и гопака на потолке станцевать, чтобы что-то отдаленно напоминающее приведенный выше прикол прошел код ревью.

I>Если ваша команда работает только со своим кодом, то так и будет. А совсем недавно товарищу пришел убитый проект на лялих++... Надо продолжать ?

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

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

I>>Сколько тебе понадобится времени, что бы в древнем проекте 50-100мб пофиксить строки и прикрутить std:string ?

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

Неправильно. Если он дожил, значит бюджет позволял жить. Рано или поздно это прекратится.

I>>Если ваша команда работает только со своим кодом, то так и будет. А совсем недавно товарищу пришел убитый проект на лялих++... Надо продолжать ?

L>Судя по тому, что тебе, по всей видимости, указатели снятся в кошмарах, тебе лучше не спрашивать, чем моя команда занимается. Можешь повторить шутку про Дартаньяна

Стало быть про убитый проект на лялих++ возражений нет. На том и закончим.

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

I>Все баги происходят по причине человеческого фактора. Вообще все. Потому когда речь про проблемы вроде с указателями, очевидно, имеется ввиду зависимость от этого ЧФ, которая у указателей много выше, чем с другими механизмами вроде ссылок.
Спасибо кэп

Вам это и пытаются втолковать, что борьба с человеческим фактором может заключаться не только в переходе на управляемые языки но и использовании более безопасных техник на неуправляемых, как то применения умные указатели, разумные coding conventions и т.п.
I>Это следует из того, что одни и те же люди не могут заставить взлететь проект на С++ хотя менеджед версия летает.
Это в первую очередь говорит о том что скорее всего и персонал и язык для проекта подобраны не правильно.

И опять хочется примеров чего это такого удалось на менеджед сделать и не удалось на плюсах.

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

M>Очевидно, что это — неочевидно. И учитывая, что тут работа с COM, это является весьма специфичной задачей. Назвать это именно преимуществом над другими языками у меня рука не поднимается. Так, чпособ решить костыли другими костылями

И чего мне делать-то если у клиента его апликация использует грид или rоt? Обьяснять ему что он лошара и должен весь свой софт немедленно на java переписать? Так ведь пошлет и денег не даст. Именно такие специфические задачи и требуют сответствующего инструмента. И С/C++ позволяет такие задачи решать достаточно быстро и эффективно в отличии от других языков.

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

I>>Все баги происходят по причине человеческого фактора. Вообще все. Потому когда речь про проблемы вроде с указателями, очевидно, имеется ввиду зависимость от этого ЧФ, которая у указателей много выше, чем с другими механизмами вроде ссылок.
_>Спасибо кэп

Вам это и пытаются втолковать, что борьба с человеческим фактором может заключаться не только в переходе на управляемые языки но и использовании более безопасных техник на неуправляемых, как то применения умные указатели, разумные coding conventions и т.п.

Начнем сначала. Сколько нужно времени что бы старом проекте на 50-100мб кода заменить указатели на смартпоинтеры и тд.

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

И опять хочется примеров чего это такого удалось на менеджед сделать и не удалось на плюсах.

такое ощущение что большинство адептов С++ в этом топике не в курсе про legacy код. раньше на с++ писалось очень много того, что сейчас пишется на менеджед средствах. Куда деть такой код ? Может назвать его несиплюсным ? это резко снимет проблему указателей

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

M>>Очевидно, что это — неочевидно. И учитывая, что тут работа с COM, это является весьма специфичной задачей. Назвать это именно преимуществом над другими языками у меня рука не поднимается. Так, чпособ решить костыли другими костылями

_>И чего мне делать-то если у клиента его апликация использует грид или rоt? Обьяснять ему что он лошара и должен весь свой софт немедленно на java переписать? Так ведь пошлет и денег не даст. Именно такие специфические задачи и требуют сответствующего инструмента. И С/C++ позволяет такие задачи решать достаточно быстро и эффективно в отличии от других языков.

О, уже лушче. Скоро клиент окажется во всём виноватым

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

I>Начнем сначала. Сколько нужно времени что бы старом проекте на 50-100мб кода заменить указатели на смартпоинтеры и тд.

Нисколько, потому что это не нужно.

I>такое ощущение что большинство адептов С++ в этом топике не в курсе про legacy код. раньше на с++ писалось очень много того, что сейчас пишется на менеджед средствах. Куда деть такой код ? Может назвать его несиплюсным ? это резко снимет проблему указателей

Я не могу, он нам сейчас еще и про легаси код рассказывать будет. Давай уже, жги!

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

I>>Неправильно. Если он дожил, значит бюджет позволял жить. Рано или поздно это прекратится.

L>мне кажется, у нас фломастеры и масштабы разные. В нашей индустрии AV во время рантайма — это не просто critical, это имеет safety implications. Никакого бюджета не хватит дежать дерьмокод. Поэтому если код образца 91 года до сих пор входит в проект, значит он вылизан по самые помидоры. Другого кода там просто быть не может.

И так во всех отраслях, правильно я тебя понимаю ?

I>>Стало быть про убитый проект на лялих++ возражений нет. На том и закончим.

L>А откуда им взяться? Что тако лялих++ я не знаю, кто твой знакомый не ведаю и кто и зачем убивал этот проект понятия тоже не имею. Да и в чем вопрос, собственно, тоже не совсем понимаю.

лялих++ это я так обозвал проект под лялих на с++. Знакомый — тимлид на аутсорсинговой конторе. Проект пришел по тендеру. У меня, кстати говоря, случай был похожий. наша контора выросла в самостоятельную из нескольких убитых проектов, которые перед тем как попасть к нам были трижды завалены в разных странах. Java что характерно осталась в строю. С++ умер окончательно.

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

I>>Начнем сначала. Сколько нужно времени что бы старом проекте на 50-100мб кода заменить указатели на смартпоинтеры и тд.

L>Нисколько, потому что это не нужно.

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

I>>такое ощущение что большинство адептов С++ в этом топике не в курсе про legacy код. раньше на с++ писалось очень много того, что сейчас пишется на менеджед средствах. Куда деть такой код ? Может назвать его несиплюсным ? это резко снимет проблему указателей

L>Я не могу, он нам сейчас еще и про легаси код рассказывать будет. Давай уже, жги!

А есть что сказать более внятного ?

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

I>Начнем сначала. Сколько нужно времени что бы старом проекте на 50-100мб кода заменить указатели на смартпоинтеры и тд.
Вам же уже отвечали. Если удовлетворительно проект работает не нужно ничего менять. Если нет то смотрите сами что для вас будет быстрее переписать на менеджет или зачистить плюсный код.

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

И опять хочется примеров чего это такого удалось на менеджед сделать и не удалось на плюсах.

I>такое ощущение что большинство адептов С++ в этом топике не в курсе про legacy код. раньше на с++ писалось очень много того, что сейчас пишется на менеджед средствах. Куда деть такой код ? Может назвать его несиплюсным ? это резко снимет проблему указателей

Еще как в курсе. Вы сами должны решать как с легаси бороться. Тут однозначного рецепта нет, если дешевле преписать на менедж переписывайте на здоровье, особенно если нужно дальнейшее развитие. Указатели тут не причем. На нете и джаве легаси разве не бывает?

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

M>>>>>Преимущество по сравнению с чем?
_>>>>С языками которые этого не позволяют.

M>>>Голословно. В чем это преимущество выражается?
_>>Очевидно что иногда бывает сильно нужно пошарить по памяти:
_>>Как обратиться в внешнему Grid`у через API
_>>Re: Как узнать какой процесс создал объект в ROT
_>>и т.п.

I>Сомнительное преимущество.
Кому как, сделайте то же самое на jаvа

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

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

M>>>>Голословно. В чем это преимущество выражается?
_>>>Очевидно что иногда бывает сильно нужно пошарить по памяти:
_>>>Как обратиться в внешнему Grid`у через API
_>>>Re: Как узнать какой процесс создал объект в ROT
_>>>и т.п.

I>>Сомнительное преимущество.
_>Кому как, сделайте то же самое на jаvа

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

Задачи это найти объект в ROT или имеется ввиду бизнес задача ?

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

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

M>>>>>Голословно. В чем это преимущество выражается?
_>>>>Очевидно что иногда бывает сильно нужно пошарить по памяти:
_>>>>Как обратиться в внешнему Grid`у через API
_>>>>Re: Как узнать какой процесс создал объект в ROT
_>>>>и т.п.

I>>>Сомнительное преимущество.
_>>Кому как, сделайте то же самое на jаvа

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

I>Задачи это найти объект в ROT или имеется ввиду бизнес задача ?
Обьект в RОТ найти легко.

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

I>>Задачи это найти объект в ROT или имеется ввиду бизнес задача ?
_>Обьект в RОТ найти легко.

Есть несколько одинаковых обьектов в RОT, созданных несколькими инстансами одной и тойже аппликации. Нужно выяснить какой из них какому процессу принадлежит для того чтобы в потом приконектиться к нужному инстансу и пошерудить в его гуе.
_>Бизнес задача в основном такая : Обеспечить возможность получения информации из гуя любой аппликации у клиента, а также атоматизация гуя любой аппликации.

Итого — необходимо и достаточно компонента в 1000 строчек на С++ в виде плагина для _готовой_ менеджед аппликачки ...

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

M>>>Очевидно, что это — неочевидно. И учитывая, что тут работа с COM, это является весьма специфичной задачей. Назвать это именно преимуществом над другими языками у меня рука не поднимается. Так, чпособ решить костыли другими костылями

_>>И чего мне делать-то если у клиента его апликация использует грид или rоt? Обьяснять ему что он лошара и должен весь свой софт немедленно на java переписать? Так ведь пошлет и денег не даст. Именно такие специфические задачи и требуют сответствующего инструмента. И С/C++ позволяет такие задачи решать достаточно быстро и эффективно в отличии от других языков.

I>О, уже лушче. Скоро клиент окажется во всём виноватым

О коллега.

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

I>>>Начнем сначала. Сколько нужно времени что бы старом проекте на 50-100мб кода заменить указатели на смартпоинтеры и тд.
_>>Вам же уже отвечали. Если удовлетворительно проект работает не нужно ничего менять. Если нет то смотрите сами что для вас будет быстрее переписать на менеджет или зачистить плюсный код.

I>Неудовлетворительно. Если нет низкоуровневой фигни, то обычно дешевле перевести на менеджед.
Странно что такой проект дожил до возраста легаси. Но чего в жизни не бывает.

I>>>такое ощущение что большинство адептов С++ в этом топике не в курсе про legacy код. раньше на с++ писалось очень много того, что сейчас пишется на менеджед средствах. Куда деть такой код ? Может назвать его несиплюсным ? это резко снимет проблему указателей

_>>Еще как в курсе. Вы сами должны решать как с легаси бороться. Тут однозначного рецепта нет, если дешевле преписать на менедж переписывайте на здоровье, особенно если нужно дальнейшее развитие. Указатели тут не причем. На нете и джаве легаси разве не бывает?

I>Бывает. После сиплюсного легаси менеджед одно удовольствие

Мне трудно оценить я такой фигней еще пока не занимался. Но коллеги однако плюются. Впрочем синдром когда "все что не нами написано глючит и требует переделки" от языка мало зависит...

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

I>>>Задачи это найти объект в ROT или имеется ввиду бизнес задача ?
_>>Обьект в RОТ найти легко.

Есть несколько одинаковых обьектов в RОT, созданных несколькими инстансами одной и тойже аппликации. Нужно выяснить какой из них какому процессу принадлежит для того чтобы в потом приконектиться к нужному инстансу и пошерудить в его гуе.
_>>Бизнес задача в основном такая : Обеспечить возможность получения информации из гуя любой аппликации у клиента, а также атоматизация гуя любой аппликации.

I>Итого — необходимо и достаточно компонента в 1000 строчек на С++ в виде плагина для _готовой_ менеджед аппликачки ...
Ну да, примерно так и делается. Я что призывал все на свете на плюсах переписать?

Я вроде говорил что есть задачи в которых без нейтива не обойдешься. На самом деле обычно не плагин на плюсах пишется, а внедряемый в чужой процесс хук. Есть и управляемые хуки для java и net.

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

I>>О, уже лушче. Скоро клиент окажется во всём виноватым

_>О коллега.

Вы не в курсе что клиент источник не только денег но и проблем? Как я могу автоматизировать апликацию клиента написанную на PowerBuilder, QT, SmallTalk, VB и прочей хрени ? Очевидно что самый простой способ использовать аpi этой самой аппликации ,если он конечно имеется, если не имеется то все становится гораздо сложнее ( иногда даже не возможно). Вы даже не представляете с какими извращения иногда приходится работать.

Представляю. Двое товарией несколько лет майнтейнили как раз такую вот прожку, как ты говоришь, но она была на вся дотнетная. Кое что, в соновном хуки и всякая пакость для ROT, GIT была на ++.

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

L>>Проблем с указателями не бывает. Бывают проблемы с программистами, их ниасилившими и их кодом.
I>Это абсолютно несущественная разница. Если прогарммист не осилил указатели, то эта особенность указателей проявится во всех фрагментах его кода.
Ой, мы конечно догадывались про тебя, но зачем же так прямо?

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

I>Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.

То есть на прочих шарпах легче и бустрее писать, да плюс еще сразу без ошибок?
Ну и где в таком случае сингулярити?? Ауууу-ууу.

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

MM>Вот это как раз не столь критично, потому что для большинства алгоритмов код давно уже написан.

Эй, осторожнее. В местных специальных олимпиадах я лидирую!

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

I>Ссылка и указатель это две большие разницы. Указатель включает в себя ссылки. А вот адреса и всякой всячины с этим связаной в ссылках нет и быть не может. Есть идентити — т.е. ответ на вопрос, две ссылки это один и тот же объект или разные. Все.

Это не автобус. Это просто большая машина, а внутри сидения и окна по бокам.

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

I>Чисто между прочим, ты в курсе, что старого кода на порядки больше чем нового и от него никто не собирается отказываться ?
Я вижу что старый код постоянно устаревает и выбрасывается. А глючный старый код — в первую очередь.

I>Это следует из того, что одни и те же люди не могут заставить взлететь проект на С++ хотя менеджед версия летает.
Это лишь говорит об их квалификации.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Начнем сначала. Сколько нужно времени что бы старом проекте на 50-100мб кода заменить указатели на смартпоинтеры и тд.
Коду с багами поможет только их исправление. Ну а говнокоду или рефакторинг или может оказаться что дешевле вынести его на помоечку.

I>такое ощущение что большинство адептов С++ в этом топике не в курсе про legacy код.
Мы не юзаем древний и кривой legacy код. Ибо хватает не такого древнего и кривого.

I>Куда деть такой код?
Зависит от качества кода. Хороший в реюз. Плохой или чинить или выкинуть.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

_>Еще как в курсе. Вы сами должны решать как с легаси бороться. Тут однозначного рецепта нет, если дешевле преписать на менедж переписывайте на здоровье, особенно если нужно дальнейшее развитие. Указатели тут не причем. На нете и джаве легаси разве не бывает?

На джаве легаси мало отличается от не легаси. Язык с самого рождения и до текщего момента мало менялся, и никаких принципиально новых концепций не вносилось(если говорить о языке, не либах). Ну да, добавились штуки вроде java.util.concurrent, но оно в основном синтаксический сахар.

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

L>Говнокод, в котором есть "проблемы с указателями" (сиречь падает на ровном месте) шансов стать легаси кодом не имеет.
Именно!

L>Разве что в какой-нить внутренней тулзе в какой-нить ООО "Рога и копыта"
Есть ещё отличное "НИИ Говна и Торфа" (С) Belnetmon

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>>мне кажется, у нас фломастеры и масштабы разные. В нашей индустрии AV во время рантайма — это не просто critical, это имеет safety implications. Никакого бюджета не хватит дежать дерьмокод. Поэтому если код образца 91 года до сих пор входит в проект, значит он вылизан по самые помидоры. Другого кода там просто быть не может.

I>И так во всех отраслях, правильно я тебя понимаю ?

Назови одну, в которой можно продавать глюкало, падающее на ровном месте и при этом не растерять всех клиентов.

I>>>Стало быть про убитый проект на лялих++ возражений нет. На том и закончим.

L>>А откуда им взяться? Что тако лялих++ я не знаю, кто твой знакомый не ведаю и кто и зачем убивал этот проект понятия тоже не имею. Да и в чем вопрос, собственно, тоже не совсем понимаю.

I>лялих++ это я так обозвал проект под лялих на с++. Знакомый — тимлид на аутсорсинговой конторе. Проект пришел по тендеру. У меня, кстати говоря, случай был похожий. наша контора выросла в самостоятельную из нескольких убитых проектов, которые перед тем как попасть к нам были трижды завалены в разных странах. Java что характерно осталась в строю. С++ умер окончательно.

Что такое лялих, я не знаю. Ну а то, что проект "был завален в разных странах" и в итоге переписан на жабе, говрит лишь о том, что инструмент был изначально выбран неверно, а проект писали криворучки. Как говорится, дело было не в бобине.

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

L>Назови одну, в которой можно продавать глюкало, падающее на ровном месте и при этом не растерять всех клиентов.

Windows 98

Правда, его времена прошли давно.

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

_>Конечно, но есть опробованные лекарства.

Все эти ваши лекарства (хоть в прямом, хоть в переносном смысле) лечат следствия, а не причину.

M>>Очевидно, что это — неочевидно. И учитывая, что тут работа с COM, это является весьма специфичной задачей. Назвать это именно преимуществом над другими языками у меня рука не поднимается. Так, чпособ решить костыли другими костылями
_>И чего мне делать-то если у клиента его апликация использует грид или rоt? Обьяснять ему что он лошара и должен весь свой софт немедленно на java переписать? Так ведь пошлет и денег не даст. Именно такие специфические задачи и требуют сответствующего инструмента. И С/C++ позволяет такие задачи решать достаточно быстро и эффективно в отличии от других языков.

Выделил еще раз.

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

M>>>Очевидно, что это — неочевидно. И учитывая, что тут работа с COM, это является весьма специфичной задачей. Назвать это именно преимуществом над другими языками у меня рука не поднимается. Так, чпособ решить костыли другими костылями
_>>И чего мне делать-то если у клиента его апликация использует грид или rоt? Обьяснять ему что он лошара и должен весь свой софт немедленно на java переписать? Так ведь пошлет и денег не даст. Именно такие специфические задачи и требуют сответствующего инструмента. И С/C++ позволяет такие задачи решать достаточно быстро и эффективно в отличии от других языков.

M>Выделил еще раз.
Увы подобные костыли существуют помимо моего желания, и есть необходимость с ними как-то бороться.

Есть похожий код и не для комов. Ну например нужно получить указатель на неэкспортируемую функцию виртуальной машины VB или PowerBuildera в чужом процессе и т.п. В сях это делается достаточно просто. Как нечто подбное сделать на jаvа или net я не знаю. Еще раз : именно с/c++ предоставляет мне возможности решать подобные задачи быстро и не особенно напрягаясь. Да, эти задачи очень часто связаны в плотную с особенностями сторонных программ/технологий, однако решать мне их все равно нужно. Этот спор вообще бессмысленен. Дополнительные возможности любого языка(даже потенциально опасные) вряд-ли можно назвать недостатком. Не нужно — не пользуйтесь, но лучше что-бы было на случай всякого рода костылей. Для задач без костылей выбирайте более безопасные языки.

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

I>>ничего странного, жизнь проекта определяется не количеством багов, а размером бюджета. Если бизнес считает, что N млн долларов в год это не деньги, то проект будет жить до тех пор, пока затраты не превысят это N.
_>Ну не знаю.

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

Еще раз — зависит от бюджета и некоторых других факторов, например цена ошибки для бизнеса.

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

L>>Назови одну, в которой можно продавать глюкало, падающее на ровном месте и при этом не растерять всех клиентов.

E__>Windows 98

E__>Правда, его времена прошли давно.

Годный вброс

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

L>>>Проблем с указателями не бывает. Бывают проблемы с программистами, их ниасилившими и их кодом.
I>>Это абсолютно несущественная разница. Если прогарммист не осилил указатели, то эта особенность указателей проявится во всех фрагментах его кода.
S>Ой, мы конечно догадывались про тебя, но зачем же так прямо?

Не сцы, в моем коде все в порядке.

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

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

I>>Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.

S>То есть на прочих шарпах легче и бустрее писать, да плюс еще сразу без ошибок?

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

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

I>>Ссылка и указатель это две большие разницы. Указатель включает в себя ссылки. А вот адреса и всякой всячины с этим связаной в ссылках нет и быть не может. Есть идентити — т.е. ответ на вопрос, две ссылки это один и тот же объект или разные. Все.

S>Это не автобус. Это просто большая машина, а внутри сидения и окна по бокам.

Указатель и ссылка это две большие разницы. Указатель == номер байта в АП + адресная арифметика. Ссылка это просто возможность работать с конкретным объектом.

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

I>>Чисто между прочим, ты в курсе, что старого кода на порядки больше чем нового и от него никто не собирается отказываться ?
BBI>Я вижу что старый код постоянно устаревает и выбрасывается. А глючный старый код — в первую очередь.

Выбрасывать старый код — слишком дорогое удовольствие. Выбрасывать нужно только рудименты всякие, т.е. код который уже не используется но сидит в репе.

I>>Это следует из того, что одни и те же люди не могут заставить взлететь проект на С++ хотя менеджед версия летает.
BBI>Это лишь говорит об их квалификации.

Нет, это говорит о том, что для продукта критично не понимание указателей, а умение решать проблемы.

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

S>>То есть на прочих шарпах легче и бустрее писать, да плюс еще сразу без ошибок?

I>В менеджед отсутствует целый класс ошибок связаных с указателями. А благодаря возможностям самого менеджед, есть вагон инструментов которые очень хорошо страхуют программиста или помогают локализовать ошибку максимально быстро.

Тоесть по большому счету все ништяки не в языке, а в инструментах?

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

S>>То есть на прочих шарпах легче и бустрее писать, да плюс еще сразу без ошибок?

I>В менеджед отсутствует целый класс ошибок связаных с указателями. А благодаря возможностям самого менеджед, есть вагон инструментов которые очень хорошо страхуют программиста или помогают локализовать ошибку максимально быстро.

Читаем "в менеджед отсутствует целый класс ошибок, которых в принципе нигде нет". Ты ведь так и не показал нам, что это за ошибки, связанные с указателями.

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

I>>>Ссылка и указатель это две большие разницы. Указатель включает в себя ссылки. А вот адреса и всякой всячины с этим связаной в ссылках нет и быть не может. Есть идентити — т.е. ответ на вопрос, две ссылки это один и тот же объект или разные. Все.

S>>Это не автобус. Это просто большая машина, а внутри сидения и окна по бокам.

I>Указатель и ссылка это две большие разницы. Указатель == номер байта в АП + адресная арифметика. Ссылка это просто возможность работать с конкретным объектом.

Это не звезда. Просто большой шар из преимущественно водорода. Настолько большой, что внутрях, изза гравитации, запустились и идут термоядерные реакции.

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

I>>такое ощущение что большинство адептов С++ в этом топике не в курсе про legacy код.
BBI>Мы не юзаем древний и кривой legacy код. Ибо хватает не такого древнего и кривого.

Про что я и говорю.

I>>Куда деть такой код?
BBI>Зависит от качества кода. Хороший в реюз. Плохой или чинить или выкинуть.

Выкинуть как правило слишком дорого. Например потому, что код писал некото с большим матбеграундом и большими способностями запоминать неструктурированый код. Ему было легко работать с простынями в 100кб и более . Этот код работает, более того, является ключевым.
Что бы его переписать, нужен точно такой же специалист, а это как правило всегда проблема.

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

I>>И так во всех отраслях, правильно я тебя понимаю ?

L>Назови одну, в которой можно продавать глюкало, падающее на ровном месте и при этом не растерять всех клиентов.

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

I>>>>Стало быть про убитый проект на лялих++ возражений нет. На том и закончим.

L>>>А откуда им взяться? Что тако лялих++ я не знаю, кто твой знакомый не ведаю и кто и зачем убивал этот проект понятия тоже не имею. Да и в чем вопрос, собственно, тоже не совсем понимаю.

I>>лялих++ это я так обозвал проект под лялих на с++. Знакомый — тимлид на аутсорсинговой конторе. Проект пришел по тендеру. У меня, кстати говоря, случай был похожий. наша контора выросла в самостоятельную из нескольких убитых проектов, которые перед тем как попасть к нам были трижды завалены в разных странах. Java что характерно осталась в строю. С++ умер окончательно.

L>Что такое лялих, я не знаю. Ну а то, что проект "был завален в разных странах" и в итоге переписан на жабе,

Ты или читай внимательно, или спрашивай, что непонятно. Я не говорил, что "переписали на жабе". Была кучка проектов, часть плюсовых, часть — джава. Плюсовые вымерли. Джава осталась в строю. Плюсовые вымерли из за обилия проблем внутри кода — утечки, указатели, исключения.

>говрит лишь о том, что инструмент был изначально выбран неверно, а проект писали криворучки. Как говорится, дело было не в бобине.

"проект писали криворучки" — не ты ли чуть не пеной брызгал и доказывал что все плюсовики суть мега-продвинутые девелоперы у которых годами не бывает багов с указателями ?

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

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

S>>>То есть на прочих шарпах легче и бустрее писать, да плюс еще сразу без ошибок?

I>>В менеджед отсутствует целый класс ошибок связаных с указателями. А благодаря возможностям самого менеджед, есть вагон инструментов которые очень хорошо страхуют программиста или помогают локализовать ошибку максимально быстро.

S>Тоесть по большому счету все ништяки не в языке, а в инструментах?

Конечно. Зато эти ништяки становятся возможными благодаря поддержке в языке. Например такая вещь как рефлексия позволяет создавать инструменты без необходимости наворачивать тонны кода или использовать какой парсер для простых вещей.
А в сиплюсе тебе надо уже парсер использовать, а поскольку это тяжкое дело, то парсер или работает медленно, или возможности ограничины, или же инструмент будет часто промахиваься. Ну и такой парсер делает задачу на порядок сложнее, т.е. люди будут тратить больше времени а стало быть выхлоп будет меньше.

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

I>>Что бы его переписать, нужен точно такой же специалист, а это как правило всегда проблема.

P>На самом деле проблема в том, что этот специалист перепишет код такими же 100-километровыму простынями.

С этим сложно чтото поделать

Матаматичи часто пишут код который никто кроме них понять не может.

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

L>>Внятного? Мы с тобой на разных язаках разговариваем, как я посмотрю. Вообще-то приличные люди легаси кодом называют модули, хоть и написанные во времена царя горооха, но при этом стабильные, как Египетские пирамиды.

I>Легаси это просто код, который достался тебе по наследтсву от другой тимы. Всё.

На этой оптимистичной ноте разговор можно завершать. Мы с тобой с разных весовых категориях, все равно не поймешь.

>>Единственная причина, по которой его трогают — это когда расширение или изменение функциональности становится неизбежным. Но даже тогда с бОльшей вероятностью функциональность просто заменяют новым кодом из соображений однородности и простоты поддержки. Юнит-тесты, опять же.

I>Есть такие страшные люди, математики. Могут писать простыни по 100кб и более и им там все понятно. Кроме них этот код никто не понимает.

Математики пусть алгоритмы на доске мелком рисуют. писать программы должны программисты.

L>>Говнокод, в котором есть "проблемы с указателями" (сиречь падает на ровном месте) шансов стать легаси кодом не имеет. Разве что в какой-нить внутренней тулзе в какой-нить ООО "Рога и копыта"

I>Это по малолетству так кажется.

Слив защитан.

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

I>>Есть такие страшные люди, математики. Могут писать простыни по 100кб и более и им там все понятно. Кроме них этот код никто не понимает.

L>Математики пусть алгоритмы на доске мелком рисуют. писать программы должны программисты.

Многи ли ты можешь назвать специалистов по теории доминирования которые занимаются этим лет 15-20 ? Выбирать, как видишь, не из чего.

I>>Это по малолетству так кажется.

L>Слив защитан.

О, ты у Пацака подсмотрел такой аргумент ?

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

I>>>Показал. вам, сиплюсникам, надо определиться. Или проблем с указателями нет, тогда не ясно зачем вам valgrind, или...
_>>Уже определились

I>Ага, "я освоил потому проблем нет" зато бОльшая часть людей валится на собеседованиях именно из за этих указателей.
Ага, вот пусть эта большая часть людей дружным строем марширует в сторону менеджет.

M>>>>Ну дык. Указатели старательно упаковывают в GC для бедных — auto_ptr, shared_ptr и прочая *_ptr
BBI>>>Это не GC ни разу. Это RAII.

M>>Выделено.

M>>>> чтобы не дай бог кто-то не использовал голые указатели.
BBI>>>Отнюдь. Основная причина: упрощение управления времени жизни объекта. Уменьшение рукопашной.

M>>А что GC, по-твоему, делает с точки зрения программиста? ВНЕЗАПНО упрощает управление временем жизни объекта. Уменьшает рукопашную. Но GC — это зло, а вот все остальное — это добро, агаага

ТКС>Люди, ни разу не писавшие на языках с деструкторами и RAII, под временем жизни объекта понимают несколько другое, нежели люди, активно использующие RAII. Поэтому им не понятно, что GC НЕ упрощает управление временем жизни объекта в понимании С++. В плюсовой программе удаление одного объекта-хозяина часто приводит к целому каскаду событий, как-то закрытие файлов, сокетов, изменение имперсонации (логаут пользователя с точки зрения операционной системы, например) и .т.п.

Да не надо рассказывать сказки. Тут рядом, например, Шеридан показывает, как он это понимает, ага.

ТКС>В языках с GC все эти действия приходится продумывать отдельно от управления памятью. Сложно назвать это упрощением.

Расскажи мне, что происходит при вызове delete на shared_ptr, например? Да ничего не происходит до тех пор, пока счетчик ссылок не обнулится. И тогда пойдет тот самый «каскад» который обломится на очередном shared_ptr со счетчиком > 0 ну и т.п.

Но это жы RAII!!!!одинодинодин

Что в языках с GC что без GC надо достаточно строго следить за внешними к программе ресурсами — файлами, сокетами и т.п. Для всего остального так называемый «современный С++» всеми силами стремится избавится от указателй за *_ptr, которые обеспечивают ровно то, что обеспечивает GC — своевременное удаление этих объектов из памяти.

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

I>>Показал. вам, сиплюсникам, надо определиться. Или проблем с указателями нет, тогда не ясно зачем вам valgrind, или...

L>Если ты не сиплюсплюсник, то что ты к указателям прицепился?

Я занимаюсь в т.ч. набором и периодически приходится проводить собеседования по С++. бОльшая часть кандидатов валится там где ты и другие утверждают что проблем якобы нет никаких.

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

I>>Многи ли ты можешь назвать специалистов по теории доминирования которые занимаются этим лет 15-20 ? Выбирать, как видишь, не из чего.

L>Пофигу. Дайте своим специалистам маткад или матлаб, пусть ваяют нетленку в них. А интергировать будете сгенерированный код. Если они специалитсы по теории, то пусть и занимаются своей теорией, а код пусть оставят профессионалам.

Ты похоже так и не понял, что речь про легаси, то есть про проблемы которые были созданы еще до того, как проект пришел на нашу контору.

I>>О, ты у Пацака подсмотрел такой аргумент ?

L>Переход на личности -> неадекват -> слив защитан.

Да,да, иди погуляй.

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

I>>Ага, "я освоил потому проблем нет" зато бОльшая часть людей валится на собеседованиях именно из за этих указателей.
_>Ага, вот пусть эта большая часть людей дружным строем марширует в сторону менеджет.

Они так и делают. Более того — суровые сиплюсники тоже часто мигрируют в менеджед. Вот наоборот сильно вряд ли. например мигрируют потмоу что нужны более разнообразные задачи.

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

L>>Причем практически только в случаях совместного владения или когда владение должно передаваться, в остальных случаях достаточно RAII.

M>Пример можно?

Боюсь, в примере не будет
M>

M>X *p = new X();
M>...
M>...
M>...
M>delete p;
M>

New, может, и не будет, но delete будет явный. Из недавнего — собственная реализация дерева без использования умных указателей. Из-за дикого размера дерева и дикого количества оных одно оборачивание детей в умный указатель давало оверхед по памяти мегабайт в триста. Выкинули умные указатели, обучили ноду дерева делать delete в деструкторе. Профит.

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

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

G>>Видишь, ты зная указатели не понимаешь ссылки в .NET.
MM>Ой спасибо. Мне недавно еще посоветовали почитать книгу по WPF, мол, я в нем мало что понимаю. Посоветуй и ты мне книжку, которая учит приемам демагогии.

Из твоей формулировки как раз и следует непонимание ссылок. Путаница в терминологии отражает путаницу в мыслях.

Ссылка никак не относится к адресам. Указатель это именно номер байта в АП, то есть, самый что ни есть, адрес и отсюда следует адресная арифметика и тд.

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

L>>Если ты не сиплюсплюсник, то что ты к указателям прицепился?

I>Я занимаюсь в т.ч. набором и периодически приходится проводить собеседования по С++. бОльшая часть кандидатов валится там где ты и другие утверждают что проблем якобы нет никаких.

Это не они валятся, это ты некомпетентен.

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

I>>>Ага, "я освоил потому проблем нет" зато бОльшая часть людей валится на собеседованиях именно из за этих указателей.
_>>Ага, вот пусть эта большая часть людей дружным строем марширует в сторону менеджет.

I>Они так и делают. Более того — суровые сиплюсники тоже часто мигрируют в менеджед. Вот наоборот сильно вряд ли. например мигрируют потмоу что нужны более разнообразные задачи.
Ну и слова богу. Процесс в принципе естественный. Работы меньше. Плюсников сегодня нужно много меньше чем скажем лет 10 назад. Считаю что необходимое количество адекватных разработчиков наловить можно.

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

M>>Пример можно?

Боюсь, в примере не будет
M>>

M>>X *p = new X();
M>>...
M>>...
M>>...
M>>delete p;
M>>

L>New, может, и не будет, но delete будет явный.

Что значит "New, может, и не будет" ? Предполагается логику слежения за инстанцами переложить на пользователя дерева ?

>Из недавнего — собственная реализация дерева без использования умных указателей. Из-за дикого размера дерева и дикого количества оных одно оборачивание детей в умный указатель давало оверхед по памяти мегабайт в триста. Выкинули умные указатели, обучили ноду дерева делать delete в деструкторе. Профит.

И получается, если дерево не будет инстанцировать объект, то пользователь обязан знать кишки, т.е. что деструктор нода разрушает элемент

Вот такие решения и создают проблемы на ровном месте

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

ТКС>GC не обеспечивает своевременное удаление объектов из памяти.

Что значит своевременное?

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

ТКС>>GC не обеспечивает своевременное удаление объектов из памяти.

G>Что значит своевременное?

А что, кому-то из контекста обсуждения это не понятно? Если речь идет об управлении внешними ресурсами (а именно об этом речь и идет), то "своевременно" означает "немедленно".

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

I>>>Они так и делают. Более того — суровые сиплюсники тоже часто мигрируют в менеджед. Вот наоборот сильно вряд ли. например мигрируют потмоу что нужны более разнообразные задачи.
_>>Ну и слова богу. Процесс в принципе естественный.

I>Процесс естественный, но для с++ ничего хорошего нет. Будет со временем задвинут на задворки как и ассемблер.
Почему то меня это не пугает.

>>Работы меньше. Плюсников сегодня нужно много меньше чем скажем лет 10 назад. Считаю что необходимое количество адекватных разработчиков наловить можно.

I>Наоборот, много больше, потому что количество проектов постоянно увеличивается. Многие проекты запускаются на менеджет именно по причине отсутствия плюсовиков.
Ну и нафига вам плюсники если можно писать на менеджет? На нем и пишите. Сами же говорите проблем меньше.

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

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

ТКС>>>GC не обеспечивает своевременное удаление объектов из памяти.

G>>Что значит своевременное?

ТКС>А что, кому-то из контекста обсуждения это не понятно? Если речь идет об управлении внешними ресурсами (а именно об этом речь и идет), то "своевременно" означает "немедленно".

Ты пишешь про удаление из памяти. Так вот что значит своевременное?

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

I>>Процесс естественный, но для с++ ничего хорошего нет. Будет со временем задвинут на задворки как и ассемблер.
_>Почему то меня это не пугает.

Это и не должно пугать. Главное четко понимать причины этого явления.

>>>Работы меньше. Плюсников сегодня нужно много меньше чем скажем лет 10 назад. Считаю что необходимое количество адекватных разработчиков наловить можно.

I>>Наоборот, много больше, потому что количество проектов постоянно увеличивается. Многие проекты запускаются на менеджет именно по причине отсутствия плюсовиков.
_>Ну и нафига вам плюсники если можно писать на менеджет? На нем и пишите. Сами же говорите проблем меньше.

С++ нужен для низкоуровневого контроля ресурсов. В силу отсутствия плюсовиков, эти вопросы вынуждены решать на менеджед.

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

ТКС>>>>GC не обеспечивает своевременное удаление объектов из памяти.

G>>>Что значит своевременное?

ТКС>>А что, кому-то из контекста обсуждения это не понятно? Если речь идет об управлении внешними ресурсами (а именно об этом речь и идет), то "своевременно" означает "немедленно".

G>Ты пишешь про удаление из памяти. Так вот что значит своевременное?

Ну и какой смысл мне тебе отвечать, если ты понимать написанное не желаешь?

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

ТКС>Люди, ни разу не писавшие на языках с деструкторами и RAII, под временем жизни объекта понимают несколько другое, нежели люди, активно использующие RAII. Поэтому им не понятно, что GC НЕ упрощает управление временем жизни объекта в понимании С++.

Естественно, капитан, в понимании С++ нет никакого GC

>В плюсовой программе удаление одного объекта-хозяина часто приводит к целому каскаду событий, как-то закрытие файлов, сокетов, изменение имперсонации (логаут пользователя с точки зрения операционной системы, например) и .т.п. В языках с GC все эти действия приходится продумывать отдельно от управления памятью. Сложно назвать это упрощением.

Такие вещи и нужно продумывать отдельно. Не все сводится к удалению, закрытию и тд. Это только малая часть ворклфоу.
В с++ никто не напишет за тебя корректный воркфлоу, а совмещение _некоторых_ действий с управлением памяти ничего существенно не меняет.

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

И вот, внезапно, оказывается что и в С++ ничем не лучше, только дополнительно надо еще и память контролировать.

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

G>>>Что значит своевременное?

ТКС>>А что, кому-то из контекста обсуждения это не понятно? Если речь идет об управлении внешними ресурсами (а именно об этом речь и идет), то "своевременно" означает "немедленно".

I>Для управления внешними ресурсами есть IDisposable и это не имеет отношения к GC.

Мамуту это сначала объясни

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

I>>Это и не должно пугать. Главное четко понимать причины этого явления.
_>Зачем? Мне все равно. Вопросы распостранненности того или иного языка, как и подбора кадров меня абсолютно не беспокоят.

я вот

I>>>>Наоборот, много больше, потому что количество проектов постоянно увеличивается. Многие проекты запускаются на менеджет именно по причине отсутствия плюсовиков.
_>>>Ну и нафига вам плюсники если можно писать на менеджет? На нем и пишите. Сами же говорите проблем меньше.

I>>С++ нужен для низкоуровневого контроля ресурсов. В силу отсутствия плюсовиков, эти вопросы вынуждены решать на менеджед.
_>Получается?

На самом деле могу порекомендовать только одно, платите достойную зарплату и спецы сами к вам потянутся.

Это лажа. Или ты считаешь, что количество сиплюсников в регионе резко увеличится если одна из контор даст им топовую ЗП ?

Пару штук ты заманишь. Но если на проект нужно хотя бы десяток это сразу провал. И бюджет раскидаешь и наёмешь летунов.

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

ТКС>>Люди, ни разу не писавшие на языках с деструкторами и RAII, под временем жизни объекта понимают несколько другое, нежели люди, активно использующие RAII. Поэтому им не понятно, что GC НЕ упрощает управление временем жизни объекта в понимании С++.

I>Естественно, капитан, в понимании С++ нет никакого GC

Вообще-то есть. Некоторые их даже применяли.

>>В плюсовой программе удаление одного объекта-хозяина часто приводит к целому каскаду событий, как-то закрытие файлов, сокетов, изменение имперсонации (логаут пользователя с точки зрения операционной системы, например) и .т.п. В языках с GC все эти действия приходится продумывать отдельно от управления памятью. Сложно назвать это упрощением.

I>Такие вещи и нужно продумывать отдельно. Не все сводится к удалению, закрытию и тд. Это только малая часть ворклфоу.

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

I>В с++ никто не напишет за тебя корректный воркфлоу, а совмещение _некоторых_ действий с управлением памяти ничего существенно не меняет.

Не "некоторых действий", а всего управления внешними ресурсами.

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

Т.е., ты хочешь сказать, что RAII не работает и указанное тобой невозможно реализовать средствами RAII?

I>И вот, внезапно, оказывается что и в С++ ничем не лучше, только дополнительно надо еще и память контролировать.

Смотря для каких задач естественно. И уж точно не из-за управления памятью

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

I>>>Это и не должно пугать. Главное четко понимать причины этого явления.
_>>Зачем? Мне все равно. Вопросы распостранненности того или иного языка, как и подбора кадров меня абсолютно не беспокоят.

I>я вот
?
I>>>>>Наоборот, много больше, потому что количество проектов постоянно увеличивается. Многие проекты запускаются на менеджет именно по причине отсутствия плюсовиков.
_>>>>Ну и нафига вам плюсники если можно писать на менеджет? На нем и пишите. Сами же говорите проблем меньше.

I>>>С++ нужен для низкоуровневого контроля ресурсов. В силу отсутствия плюсовиков, эти вопросы вынуждены решать на менеджед.
_>>Получается?

На самом деле могу порекомендовать только одно, платите достойную зарплату и спецы сами к вам потянутся.

I>Это лажа. Или ты считаешь, что количество сиплюсников в регионе резко увеличится если одна из контор даст им топовую ЗП ?

В конторе давшей топовою зарплату количество спецов несомненно увеличится. А регион сегодня чуть менее чем вся планета, попробуйте удаленнщиков нанимать.

Рассказать зачем я катаюсь на работу за 80 км от дома? За зарплатой, хорошими дополнительными условиями и интересной работой.
I>Пару штук ты заманишь. Но если на проект нужно хотя бы десяток это сразу провал. И бюджет раскидаешь и наёмешь летунов.
Труба. Менеджет побеждает ввиду вымирания и деградации плюсников.

Токого я раньше не слышал. А учить коллег не пробовали?

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

I>>>>>С++ нужен для низкоуровневого контроля ресурсов. В силу отсутствия плюсовиков, эти вопросы вынуждены решать на менеджед.
_>>>>Получается?

На самом деле могу порекомендовать только одно, платите достойную зарплату и спецы сами к вам потянутся.

I>>>Это лажа. Или ты считаешь, что количество сиплюсников в регионе резко увеличится если одна из контор даст им топовую ЗП ?

_>>В конторе давшей топовою зарплату количество спецов несомненно увеличится. А регион сегодня чуть менее чем вся планета, попробуйте удаленнщиков нанимать.

I>Это только краткосрочный вариант. Я чет смотрю, конторы которые заманивают топовыми ЗП, очень быстро дохнут.
Ну не знаю.

Есть знакомые в ms, sap некоторых других достаточно больших компаниях, на условия не жалуются да и конторы живее всех живых.
I>>>Пару штук ты заманишь. Но если на проект нужно хотя бы десяток это сразу провал. И бюджет раскидаешь и наёмешь летунов.
_>>Труба. Менеджет побеждает ввиду вымирания и деградации плюсников.

Токого я раньше не слышал. А учить коллег не пробовали?

I>Это что же, ты отказываешься от мега-способа — заваливания деньгами ?

Я? Не, просто предлагаю один из вариантов ликвидировать недостаток специалистов. Но деньги имхо дадут более надежный результат

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

I>>>Ага, "я освоил потому проблем нет" зато бОльшая часть людей валится на собеседованиях именно из за этих указателей.
_>>Ага, вот пусть эта большая часть людей дружным строем марширует в сторону менеджет.

E__>Если честно, то для человека, не осилившего указатели до уровня среднего собеседования по плюсам, у меня очень плохие прогнозы и для менеджед. Как минимум, это 100% означает, что человек не понимает(и так же с трудом будет понимать), как работает выделение памяти и ее сборка в менеджед, что может привести к нехорошим последствиям, особенно в нагруженных проектах.
Мои прогнозы схожи с вашими.

Пошлем их на базы/sql/abap/html/javascript т.п?

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

I>>Это только краткосрочный вариант. Я чет смотрю, конторы которые заманивают топовыми ЗП, очень быстро дохнут.
_>Ну не знаю.

Есть знакомые в ms, sap некоторых других достаточно больших компаниях, на условия не жалуются да и конторы живее всех живых.

В ms зп точно не топовые.

I>>Это что же, ты отказываешься от мега-способа — заваливания деньгами ?

_>Я? Не, просто предлагаю один из вариантов ликвидировать недостаток специалистов. Но деньги имхо дадут более надежный результат

Наоборот, в долгосрочной перспективе это самый ненадёжный. Сдёрнуть с места можно, а сформировать команду уже сильно вряд ли. Обучение даёт гораздо бОльший выхлоп не только с С++.

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

E__>Кстати, как по мне, IDisposable гораздо удобнее в плане читабельности кода(_чужого_), чем какие-то там скрытые ссылки на внешние ресурсы внутри классов, которые неявно открываются, и столь же неявно закрываются. Смотришь на код — и точно видишь, что есть внешний ресурс, и видишь его цикл жизни явно. А не какой-нибудь класс blablaFile, который на деле может вообще оказаться сущностью в памяти, и не содержать в себе ссылки на системный ресурс.

E__>PS жду не дождусь, когда в жабе такое же сделают. Бо конструкции try-finally ну черезчур громоздкие.

Да ладно, ты просто не понимаешь ни указателей ни деструктров и вообще ты боишься с++

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

I>>>Это только краткосрочный вариант. Я чет смотрю, конторы которые заманивают топовыми ЗП, очень быстро дохнут.
_>>Ну не знаю.

Есть знакомые в ms, sap некоторых других достаточно больших компаниях, на условия не жалуются да и конторы живее всех живых.

I>В ms зп точно не топовые.

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

I>>>Это что же, ты отказываешься от мега-способа — заваливания деньгами ?

_>>Я? Не, просто предлагаю один из вариантов ликвидировать недостаток специалистов. Но деньги имхо дадут более надежный результат

I>Наоборот, в долгосрочной перспективе это самый ненадёжный. Сдёрнуть с места можно, а сформировать команду уже сильно вряд ли. Обучение даёт гораздо бОльший выхлоп не только с С++.
Смотря для чего. Достаточно типичный стартап: относительно высокие зарплаты и перспективы послепродажного навара позволяют собрать хороших спецев которые за пару тройку лет доводят проект до продажного состояния. Потом продались, деньги поделили и разбежались или новый стартап замутили.
Вы выходит рецепт знаете? Чего плакать-то на бестолковость кандидатов в команду? Отбирайте наиболее обучаемых и вперед.

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

M>Да не надо рассказывать сказки. Тут рядом, например, Шеридан показывает, как он это понимает, ага.
Ну ты конечно выбрал кого брать в пример. Ты например Кодта бери, он кошернее.

ТКС>>В языках с GC все эти действия приходится продумывать отдельно от управления памятью. Сложно назвать это упрощением.
M>Расскажи мне, что происходит при вызове delete на shared_ptr, например?
Эм. На shared_ptr delete никто не зовёт.

M>Что в языках с GC что без GC надо достаточно строго следить за внешними к программе ресурсами — файлами, сокетами и т.п.
В C++ для этого используют всё тот же RAII, который обеспечивает закрытие всех необходимых внешних ресурсов в тот самый момент когда удаляется держащий их объект.

M>которые обеспечивают ровно то, что обеспечивает GC — своевременное удаление этих объектов из памяти.
GC объект удалит из памяти только при ближайшей сборке мусора. Которая еще хз когда произойдёт. Какое тут ещё своевременное?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>>Математики пусть алгоритмы на доске мелком рисуют. писать программы должны программисты.
I>Многи ли ты можешь назвать специалистов по теории доминирования которые занимаются этим лет 15-20 ? Выбирать, как видишь, не из чего.
В такой ситуации правильный подход такой: математики пишут какой то алгоритм, который они у себя доводят до работающего состояния. Затем по этому алгоритму нормальными программерами пишется код для production.
А пускать их говнокод сразу в prodution это ССЗБ.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Скучные у тебя аргументы, смотри сюда, классика жанра:
I>

I>IComObject *pObj = ... ;
I>void **pUnknown = NULL;

pObj->>QueryInterface(IID_IUnknown, temp);
I>

I>Тебе объяснить, где тут ошибка ?
В том что переменная temp не объявлена?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>Ссылка никак не относится к адресам. Указатель это именно номер байта в АП, то есть, самый что ни есть, адрес и отсюда следует адресная арифметика и тд.
Скажи, а как происходит обращение к объекту по ссылке? Как его находят, если по-твоему в ссылке в отличие от указателя адреса нету?

I>Из твоей формулировки как раз и следует непонимание ссылок.
Судя по всему это ты не понимаешь.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>Эй, осторожнее. В местных специальных олимпиадах я лидирую!
S>

Разве что в количестве сливов, тут ты, бесспорно, лидер с большим отрывом.

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

ТКС>>GC вообще отстой. Толку на три копейки, издержек на рубль.

I>Зато есть алгоритмы которые рвут с++ именно за счет ГЦ. Да-да.

Да кто бы сомневался. Только не плюсы вообще, а хип. Если память в хипе слишком часто выделять, конечно GC окажется быстрее. Только 1) такие ситуации довольно редки 2) это всегда или почти всегда можно обойти.

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

I>Зато файл является внешним ресурсом, а у тебя сказано "легко прибить гвоздями к управлению временем жизни объектов и нет ни одной причины, чтобы разделять их".
I>Раз причин разделять нет, то удаление файла должно делаться в деструкторе какого то класса.

Конечно. Если у тебя есть объект, соотвествующий файлу. Для временных файлов это вполне нормальное решение. Если же у тебя такого объекта нет, то придумывать его тоже нет причин. Соответственно, и прибивать гвоздями нечего.

I>Вот пример:
I>"удаления файла из пекаджа который представляет собой простой зип"

I>Жду примера кода.

Я не вполне понимаю, что именно ты хочешь увидеть. Поэтому жду примера кода на C#, потом представлю аналог на плюсах.

I>>>Представь себе xml-конфиг где прописывается сценарий работы с ресурсом...

ТКС>>Сценарии в xml прописывать — жосткий мазохизм, для подобных целей есть языки и поудобнее

I>Ты скромно ушел от ответа.

Нет, это ты забыл вопрос сформулировать.

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

I>>>Многи ли ты можешь назвать специалистов по теории доминирования которые занимаются этим лет 15-20 ? Выбирать, как видишь, не из чего.

L>>Пофигу. Дайте своим специалистам маткад или матлаб, пусть ваяют нетленку в них. А интергировать будете сгенерированный код. Если они специалитсы по теории, то пусть и занимаются своей теорией, а код пусть оставят профессионалам.

I>Ты похоже так и не понял, что речь про легаси, то есть про проблемы которые были созданы еще до того, как проект пришел на нашу контору.

Это не легаси. Определение легаси я давал в другом посте. То, что ты нам тут приводишь как пример легаси, нормальные люди относят к категории "говнокод обыкновенный".

I>>>О, ты у Пацака подсмотрел такой аргумент ?

L>>Переход на личности -> неадекват -> слив защитан.

I>Да,да, иди погуляй.

Слив защитан.

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

I>>Многи ли ты можешь назвать специалистов по теории доминирования которые занимаются этим лет 15-20 ? Выбирать, как видишь, не из чего.
BBI>В такой ситуации правильный подход такой: математики пишут какой то алгоритм, который они у себя доводят до работающего состояния. Затем по этому алгоритму нормальными программерами пишется код для production.

Вот именно. Это нормальный инженерный процесс.

BBI>А пускать их говнокод сразу в prodution это ССЗБ.

плюс стопицот.

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

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

I>>Указатель и ссылка это две большие разницы.
BBI>Даааа. Ссылка это сахар над указателем. Вот и вся разница.

Налицо непонимание. Как насчет адресной арифметики? Или ссылка на ссылку?

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

I>>>Указатель и ссылка это две большие разницы.
BBI>>Даааа. Ссылка это сахар над указателем. Вот и вся разница.

___>Налицо непонимание.
Давай разъясню если не понимаешь.

___>Как насчет адресной арифметики?
Запрещена "сахаром"

___> Или ссылка на ссылку?
Запрещена "сахаром"

Ещё вопросы?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>>>Ты продолжаешь показывать свое чудовищное непонимание вопроса. Тебе точно не стоит собеседовать кандидатов на C++.
L>>>"New не будет" означает, что сущность, ответственная за корректное удаление некоего объекта, его сама не создает. Этот объест ей передается в полное владение извне, в конструкторе. Сам же объект создается, к примеру, в фабрике.

I>>Это ж целая инфраструктура и только для того, что бы правильно работать с указателями ...

L>Ты серьезно ничего не понял или придуриваешься?
L>Я тебе на пальцах только что описал архитектуру одного модуля системы с пояснениями, а ты увидел только указатели. Это уже комплекс.

Вся эта архитектура выросла из одного фрагмента кода с new и delete. Ты сам то это заметил ?

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

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

Если честно, то твой пост по ссылке это порожняя реакция в ответ на порожняк на собеседования.

I>>Всё, поезд ушел, С++ превращается в лавочку "для своих".

L>Для избранных, если так тебе будет угодно.

Я ж не против

I>>Ага, в старом проекте проблемы в коде за 5-7 лет до того, как я в универ пошел, и основная причина — что я сейчас чего то не умею ? А ты, логик, аплодирую стоя

L>Кто-нибудь, расшифруйте это, пожалуйста.

Расшифровываю — ты уже в который раз обвиняешь меня в проблемах, которые появились задолго до того, как я и мои товарищи занялись проектом

Проблемы в основном с указателями, которые мне и моим товарищам пришлось исправлять денно и нощно.

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

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

I>>Вот уже годный ответ:
I>>

I>>IComObject *pObj = ... ;  

I>>IUnknown *pUnknown = NULL;

pObj->>>QueryInterface(IID_IUnknown, (void**)&pUnknown);  
I>>

M>Годный ответ на какой вопрос? Куда делась temp, и на кой хрен она была нужна в первом варианте кода?

Цитирую себя из той части которую ты скипнул:

"Это код который выдал кандидат на просьбу запросить IUnknown через имеющийся указатель на интерфейс."

"// тут было начеркано и я перенес как было, pUnknown и есть temp"

Ну и дела, уже третий мега=-сиплюсник в одном топике и тоже не умеет читать. Или вы все только правильный С++ код умеет читать ?

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

E__>>Если честно, то для человека, не осилившего указатели до уровня среднего собеседования по плюсам, у меня очень плохие прогнозы и для менеджед. Как минимум, это 100% означает, что человек не понимает(и так же с трудом будет понимать), как работает выделение памяти и ее сборка в менеджед, что может привести к нехорошим последствиям, особенно в нагруженных проектах.

L>Более того, тут сыграет свою роль эффект заметания проблем под ковер: спецэффекты вылезут в тот момент, когда уже поздно будет пить боржоми.

Уважаемый капитан очевидность, заметание проблем под ковер всегда дает такой результат — спецэффекты вылезают именно тогда когда поздно пить боржоми

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

I>>Это код который выдал кандидат на просьбу запросить IUnknown через имеющийся указатель на интерфейс.

L>То есть это я должен был об этом догадаться?

Я очевидно поторопился и нужно было обозначить что за код. Но вообще говоря ты выдал целую кучу порожняка дополнив мое сообщение своей отсебятиной. Что мешало задать уточняющий вопрос ?

Если ты и с кастомером точно так же додумываешь ... Ну ты понял

I>>У тебя бурная фантазия — я нигде не говорил того, что ты мне приписываешь, т.е. выделеная часть это твоя отсебятина
L>Ну ты же задал телепатическую задачу. Вот тебе ответ.

Это твои домыслы. Я не задавал задачу, а привел вариант ответа на избитый вопрос. Были и другие, если хочешь, могу показать

I>>похоже, нужно объяснить для тебя что к чему

L>Да объясняй сколько влезет, после драки кулаками не машут. Если ты так на собеседовании вопросы ставишь, как в изначальном посте, то не удивляйся, что нормальные программисты к вас даже не заходят.

Как ты квалифицируешь сиплюсника, который выдал тот самый код в ответ на просьбу "запросить IUnknown через имеющийся указатель на интерфейс" ?

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

I>Ссылка она есть в даже там где нет никакого АП. Указатель существует только для АП.
I>Ссылка это не сахар, ибо никогда ни при каких условиях не имеет отношения к адресной арифметике,а реализация чз указатели есть частный случай.
Смотри глубже. Как ты не изгаляйся но в любом случае декомпозиция произойдёт до сырого адреса.

I>>>Ссылка это просто возможность работать с конкретным объектом.
BBI>>Надо полагать что ты считаешь что тут в отличие от указателя к объекту доступ осуществляется не по адресу а путём божественного вмешательства.
I>Надо полагать реализация такой вещи как "ссылка" зависит от платформы. Т.е. это высокоуровневая вещь. Реализация ч.з. указатели это только частный случай.
Ты знаешь хотя бы одну аппаратную платформу в которой работа с памятью и объектами в ней была бы сделана не через хранение где либо адреса объекта в памяти?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

I>>"Это код который выдал кандидат на просьбу запросить IUnknown через имеющийся указатель на интерфейс."

M>Что-то ты не договвариваешь. При просьбы запросить чего-то через указатель, человек пишет:

M>

ptr->>get_something(IUknown);
M>

M>А тот код, что ты показал, делает что-то ещё.

Нет, он именно запрашивает IUnknown, а вот твой код делает чтото еще, например это следует из того, что он и близко не похож на COM.
Методы COM возвращают HRESULT а запрос интерфейса это метод QueryInterface.

I>>Ну и дела, уже третий мега=-сиплюсник в одном топике и тоже не умеет читать. Или вы все только правильный С++ код умеет читать ?

M>Это где я такое про себя писал?

Это я написал. А следует это из того, что ты задал вопрос на который уже был ответ в том самом предложении где ты скипнул текст.

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

I>>>Ну и дела, уже третий мега=-сиплюсник в одном топике и тоже не умеет читать. Или вы все только правильный С++ код умеет читать ?

M>>Это где я такое про себя писал?

I>Это я написал.

круто, пиши ещё

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

I>>Ссылка она есть в даже там где нет никакого АП. Указатель существует только для АП.
I>>Ссылка это не сахар, ибо никогда ни при каких условиях не имеет отношения к адресной арифметике,а реализация чз указатели есть частный случай.
BBI>Смотри глубже. Как ты не изгаляйся но в любом случае декомпозиция произойдёт до сырого адреса.

Ты продолжаешь думать на низком уровне

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

Итого, нужно уметь абстрагироваться, т.е. уметь отделять интерфейс от его реализации.

I>>>>Ссылка это просто возможность работать с конкретным объектом.
BBI>>>Надо полагать что ты считаешь что тут в отличие от указателя к объекту доступ осуществляется не по адресу а путём божественного вмешательства.
I>>Надо полагать реализация такой вещи как "ссылка" зависит от платформы. Т.е. это высокоуровневая вещь. Реализация ч.з. указатели это только частный случай.
BBI>Ты знаешь хотя бы одну аппаратную платформу в которой работа с памятью и объектами в ней была бы сделана не через хранение где либо адреса объекта в памяти?

А зачем аппаратная ? Есть распределенные системы, те. ссылка это возможность работать с удаленным объектом. В низкоуровневом мышлении нужно держать в голове примерно такую картинку

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

L>>Ты серьезно ничего не понял или придуриваешься?
L>>Я тебе на пальцах только что описал архитектуру одного модуля системы с пояснениями, а ты увидел только указатели. Это уже комплекс.

I>Вся эта архитектура выросла из одного фрагмента кода с new и delete. Ты сам то это заметил ?

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

Node::~Node()
{
    if (m_pLeafData)
    {
         delete m_pLeafData;
    }
}

,
о чем я в посте и написал. Ты же этого "не заметил".

Фабрику я упомянул только для того, чтобы объяснить use case, в котором создатель объекта передает новосозданный объект в безраздельное пользование наружу. Впрочем, это и есть задача фабрик и все программисты в моем окружении это прекрасно знают. Странно, что приходится тебе такие элементарые вещи разжевывать.

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

___>По итогу имеем ссылка != указатель
Сахар над указателем != указатель.
От спасибо Кэп!

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>Расшифровываю — ты уже в который раз обвиняешь меня в проблемах, которые появились задолго до того, как я и мои товарищи занялись проектом

Проблемы в основном с указателями, которые мне и моим товарищам пришлось исправлять денно и нощно.

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

Если бы ты умел читать, то заметил бы, что с этой частью я как раз и не спорю.

I>>Если вы сиплюсники такие все крутые и избранные, то откуда берутся убитые в говно проекты, на которых нужно учиться как нельзя пользоваться указателями ?

L>Очень просто — крутые сипоюсплюсники таовю контору игнорируют, а говнокод рожают те, кому следовало бы сидеть под теплым крылом managed и не отсвечивать.

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

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

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

___>>По итогу имеем ссылка != указатель
BBI>Сахар над указателем != указатель.
BBI>От спасибо Кэп!

А то, что "засахаренный" адрес в памяти, который завернут в ссылку, может к примеру без всякого предупреждения быть изменён при сборке мусора, совсем-совсем ничего не меняет?

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

L>>>Ты продолжаешь показывать свое чудовищное непонимание вопроса. Тебе точно не стоит собеседовать кандидатов на C++.
L>>>"New не будет" означает, что сущность, ответственная за корректное удаление некоего объекта, его сама не создает. Этот объест ей передается в полное владение извне, в конструкторе. Сам же объект создается, к примеру, в фабрике.

I>>Это ж целая инфраструктура и только для того, что бы правильно работать с указателями ...

L>Ты серьезно ничего не понял или придуриваешься?
L>Я тебе на пальцах только что описал архитектуру одного модуля системы с пояснениями, а ты увидел только указатели. Это уже комплекс.

У него это нормальное состоние. Придумать что-то, а потом с этим упорно спорить.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

I>Вот уже годный ответ:
I>

I>IComObject *pObj = ... ;  

I>IUnknown *pUnknown = NULL;

pObj->>QueryInterface(IID_IUnknown, (void**)&pUnknown);  
I>

I>Выделил специально для тебя

Ужас а не код. Нормальные люди уже лет 12 пишут так:

IComObjectPtr obj = ...; // не понимаю зачем префикс p

IUnknownPtr unknown = obj; // удивительно :)

И как ни странно, ни один объект не утёк, и нету ни одного delete. И это всё ещё С++.

Здравствуйте, Слоноежик, Вы писали:

С>Ужас а не код. Нормальные люди уже лет 12 пишут так:

Я видел цулую кучу кода от микрософта и шота твои наблюдения не подтверждаются.

С>

С>IComObjectPtr obj = ...; // не понимаю зачем префикс p

С>IUnknownPtr unknown = obj; // удивительно :)
С>

С>И как ни странно, ни один объект не утёк, и нету ни одного delete. И это всё ещё С++.

Спасибо, капитан.

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

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

I>>Ссылка никак не относится к адресам. Указатель это именно номер байта в АП, то есть, самый что ни есть, адрес и отсюда следует адресная арифметика и тд.
BBI>Скажи, а как происходит обращение к объекту по ссылке? Как его находят, если по-твоему в ссылке в отличие от указателя адреса нету?
хэндл, как вариант

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

I>>Зато файл является внешним ресурсом, а у тебя сказано "легко прибить гвоздями к управлению временем жизни объектов и нет ни одной причины, чтобы разделять их".
I>>Раз причин разделять нет, то удаление файла должно делаться в деструкторе какого то класса.

ТКС>Конечно. Если у тебя есть объект, соотвествующий файлу. Для временных файлов это вполне нормальное решение.

То есть, если файл не временный, то надо придумывать другой способ управления ресурсами ?

>Если же у тебя такого объекта нет, то придумывать его тоже нет причин. Соответственно, и прибивать гвоздями нечего.

Опаньки ! Сначала ты вещал, что управление ресурсов "легко прибить гвоздями к управлению временем жизни объектов и нет ни одной причины, чтобы разделять их".
Щас ты начал задним числом уточнять своё утверждение

I>>Вот пример:
I>>"удаления файла из пекаджа который представляет собой простой зип"

I>>Жду примера кода.

ТКС>Я не вполне понимаю, что именно ты хочешь увидеть. Поэтому жду примера кода на C#, потом представлю аналог на плюсах.

Я так понял, тебе не нравится пекадж

Оно и ясно — в деструкторе не надо ничего удалять.

Берем такой случай управления внешним ресурсом, как перенос файла:
File.Move(source, dest);

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

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

I>>>Ссылка никак не относится к адресам. Указатель это именно номер байта в АП, то есть, самый что ни есть, адрес и отсюда следует адресная арифметика и тд.
BBI>>Скажи, а как происходит обращение к объекту по ссылке? Как его находят, если по-твоему в ссылке в отличие от указателя адреса нету?

I>На каждой аппаратной/программной платформе по разному.
Ну, давай поподробнее.
На какой это аппаратной платформе есть ссылки?
Или обращение к объектам в памяти происходит не по адресам.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>>Ссылка никак не относится к адресам. Указатель это именно номер байта в АП, то есть, самый что ни есть, адрес и отсюда следует адресная арифметика и тд.
BBI>>Скажи, а как происходит обращение к объекту по ссылке? Как его находят, если по-твоему в ссылке в отличие от указателя адреса нету?
J>хэндл, как вариант

Это враппер. Всё едино хэндл внутри транслируется в адрес. Процессор не понимает хэндлы.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

ТКС>>>>GC вообще отстой. Толку на три копейки, издержек на рубль.
I>>>Зато есть алгоритмы которые рвут с++ именно за счет ГЦ. Да-да.
BBI>>Померяемся?

Уже как то оказалось что GC медленнее чем native аллокация.

I>Оказалось, что GC быстрее чем с++ аллокация искаропки
Что такое "с++ аллокация искаропки"?

I>А что бы всунуть нормальный аллокатор нужно еще поискать нормального спеца, таких нынче днём с огнём искать надо.
Скачать готовую либу много ума не надо.
Вон с Cyberax-ом был тред где он вручную жабий GC тюнил, чтоб он работал как надо, а не как попало.

I>Ну и снова ссылка — http://morepypy.blogspot.com/2010/06/jit-for-regular-expression-matching.html
А что мешает написать JIT для regex для дёргания из native?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

I>>>>Ссылка никак не относится к адресам. Указатель это именно номер байта в АП, то есть, самый что ни есть, адрес и отсюда следует адресная арифметика и тд.
BBI>>>Скажи, а как происходит обращение к объекту по ссылке? Как его находят, если по-твоему в ссылке в отличие от указателя адреса нету?
J>>хэндл, как вариант

BBI>Это враппер. Всё едино хэндл внутри транслируется в адрес. Процессор не понимает хэндлы.

Это демагогия уже. Можно еще и о виртуальных адресах поговорить, с нулевым выхлопом, правда.

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

J>>>хэндл, как вариант
BBI>>Это враппер. Всё едино хэндл внутри транслируется в адрес. Процессор не понимает хэндлы.

J>Это демагогия уже.
Любая программа в итоге выполняется процессором. И все абстракции, которые там наверху наверчены в итоге будут сведены к базовым для платформы вещам, той же адресной арифметике. Где ты тут демагогию увидел?

J>Можно еще и о виртуальных адресах поговорить, с нулевым выхлопом, правда.
А чего о них говорить? Транслируются в физические.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

I>>>>Ссылка никак не относится к адресам. Указатель это именно номер байта в АП, то есть, самый что ни есть, адрес и отсюда следует адресная арифметика и тд.
BBI>>>Скажи, а как происходит обращение к объекту по ссылке? Как его находят, если по-твоему в ссылке в отличие от указателя адреса нету?
J>>хэндл, как вариант

BBI>Это враппер. Всё едино хэндл внутри транслируется в адрес. Процессор не понимает хэндлы.

Например, обращение по хэндлу может осуществляться на одном компьютере, а обращение по соответствующему этому хэндлу адресу — на другом. Соответственно, ни о какой адресной арифметике речь не идет.

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

I>>На каждой аппаратной/программной платформе по разному.
BBI>Ну, давай поподробнее.
BBI>На какой это аппаратной платформе есть ссылки?

Ты сам то понял что спросил ?

BBI>Или обращение к объектам в памяти происходит не по адресам.

Вот-вот

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

I>>А что бы всунуть нормальный аллокатор нужно еще поискать нормального спеца, таких нынче днём с огнём искать надо.
BBI>Скачать готовую либу много ума не надо.

А дай-ка пример готовой либы которая умеет дефрагментировать память как это умеет GC ?

I>>Ну и снова ссылка — http://morepypy.blogspot.com/2010/06/jit-for-regular-expression-matching.html
BBI>А что мешает написать JIT для regex для дёргания из native?

Очевидно, сложность задачи увеличивается, при чем сильно нелинейно.

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

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

J>>>>хэндл, как вариант
BBI>>>Это враппер. Всё едино хэндл внутри транслируется в адрес. Процессор не понимает хэндлы.

J>>Это демагогия уже.
BBI>Любая программа в итоге выполняется процессором. И все абстракции, которые там наверху наверчены в итоге будут сведены к базовым для платформы вещам, той же адресной арифметике. Где ты тут демагогию увидел?
К тому, что совсем не обязательно знать, к чему там что сведется в результате.
Вот ты пишешь скрипт на перле или вообще на баше — ну да, все в результате сведется к машкодам, ну и что?

J>>Можно еще и о виртуальных адресах поговорить, с нулевым выхлопом, правда.
BBI>А чего о них говорить? Транслируются в физические.
ну т.е. виртуальные адреса, которые ты видишь в программе, тоже "врапперы". А настоящий пацанский рулез — это то, что видит контроллер памяти.

От:	jazzer	Skype: enerjazzer
Дата:	19.01.12 09:45
Оценка:	1 (1) +9

От:	okman	https://searchinform.ru/
Дата:	19.01.12 10:56
Оценка:	-6

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	20.01.12 09:27
Оценка:	+1

	От:	Pavel Dvorkin
	Дата:	20.01.12 12:24
	Оценка:	1 (1) +5

	От:	Eugeny__
	Дата:	26.01.12 15:38
	Оценка:	3 (3) +3

	От:	Тот кто сидит в пруду
	Дата:	26.01.12 10:54
	Оценка:	+5 -1

	От:	landerhigh
	Дата:	23.01.12 12:04
	Оценка:	1 (1) +2 -2

От:	Mamut	http://dmitriid.com
Дата:	25.01.12 08:34
Оценка:	1 (1) +2

	От:	alexey_ma
	Дата:	25.01.12 16:48
	Оценка:	1 (1) +3

	От:	LuciferSingapore
	Дата:	19.01.12 11:25
	Оценка:	1 (1) +1

От:	Философ	http://vk.com/id10256428
Дата:	20.01.12 23:11
Оценка:	+1 -2

	От:	Banned by IT
	Дата:	20.01.12 07:30
	Оценка:	1 (1) +1

От:	мыщъх	http://nezumi-lab.org
Дата:	20.01.12 03:24
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	24.01.12 06:38
Оценка:	-1

От:	Sinclair	https://github.com/evilguest/
Дата:	20.01.12 06:42
Оценка:

	От:	Ночной Смотрящий
	Дата:	26.01.12 17:06
	Оценка:

	От:	Слоноежик
	Дата:	01.02.12 12:48
	Оценка: