Дмитрий Гавриленко: Физически там вызывается метод с сигнатурой Company get_Company();
То есть, строчка
Im.Work.Company.CompanyName="Intel";
раскрылась бы в
Company temp_var=Im.get_Work().get_Company();
temp_var.set_CompanyName("Intel");
Если бы Company была классом, то в temp_var оказалась бы ссылка на тот же объект, ссылка на которой лежит в Im.Work. Но структура - это value-тип, и при присваиваниях, передачах в функцию и возврате из неё создаются копии - так же, как для структур в C.
Те же проблемы возникают, когда хочется поменять поле в каком-нибудь элементе списка List < Company > . Я пока не знаю способов сделать это.
Сергей Протько: зам предам математика не нужна, да.
Учитывая, что моей основной задачей было писать решения задач, для которых математика-таки нужна, это не всегда верно :)
Вопрос в том, что именно не нравится в C# - Слишком сложный? Недостаточно низкоуровневый? Слишком медленный? Требует .NET для запуска программ? А если что-то ещё - то что нравится?
Сергей Протько: Что такое граф, знать надо. Простейшие термины - поток, цикл, связные и сильносвязные компоненты, расстояние между вершинами - тоже. Но в том объёме, в котором они нужны в алгоритмах. Надо ли знать теорию графов (конкретные теоремы, которые могут использоваться для разработки алгоритмов) - сомневаюсь: либо задача сводится к известному алгоритму, либо решается "на коленке", из общих соображений.
В дискретке то же самое. Задачи, для решения которых нужно нетривиально состыковать разные результаты, конечно, бывают. Но это обычно "гробы".
brainick: И потом, почему не вскрывается? Говорят же - не используйте в качестве ключа осмысленный текст, результат могут расшифровать. А если у нас есть два сообщения, зашифрованные одним и тем же ключом, то их XOR будет одним из этих сообщений, зашифрованных ключом, который является другим сообщением.
brainick: Не знаю. Только что взял картинки из английской версии "человечков" (чтобы не мешали воспоминания тридцатилетней давности) - вскрывается без проблем. Только последнее слово "god" распознать не удалось - до оборота "meet thy god" я не догадался.
Алексей Яхненко: Это не цейтнот. Это большой граф взаимосвязей, который лежит в голове и который надо выплеснуть в виде кода. И при этом не расплескать. Написание комментариев ухудшит дело так же, как и придумывание имён.
Хорошо, если я смогу угадать, на какие функции распадётся код. Тогда можно будет написать хотя бы их имена (а если повезёт - то и сигнатуры), и дальше использовать их в качестве скелета. Но при таком подходе начиная где-то с середины оказывается, что всё не так, и в таком порядке написать обработку за разумное время не удаётся. Приходится половину скелета ломать и начинать сначала...
Алексей Яхненко: Даже если функции маленькие и решают одну задачу. Вот поменялась сигнатура у какого-то метода. Всё равно придётся пройтись по всем точкам его вызова, понять, как там получить необходимые для вызова данные. Возможно, придётся поменять и сигнатуру вызывающего метода, или изменить его логику...
У функции, которая вычисляет силу тока, могут, например, на входе добавиться единицы измерения - омы или килоомы. Может потребоваться узнать погрешность вычисления, тогда во всей программе придётся либо вводить в пару к измерению его погрешность, либо все числа заменять на структуры "число с погрешностью". Может потребоваться учесть температуру проводника, которая берётся из внешней модели (а раньше она в проекте не фигурировала вообще - температурные зависимости решили добавить только что).
Имя переменной может не успеть стать очевидным - за 5 минут написали функцию с однобуквенными переменными и пошли писать следующие функции, чтобы не забыть, что они должны делать. А потом, когда через месяц вернёмся к этой функции, придётся учиться читать код. Конечно, тогда и можно будет изобрести правильные имена, но придётся поработать.
С пунктом 2 есть большая проблема. Допустим, в проект пришлось внести небольшое изменение - поменялся смысл одного из параметров, несколько параметров объединились в структуру, добавились новые... Поменять придётся 10-15 функций, образующих небольшое дерево. При этом в результате изменений комментарии, естественно, устареют.
И что делать? Пока мы меняем код, списки сделанных и необходимых изменений удержать в голове можно (если никто не отвлекает). Если после каждого изменения функции исправлять её комментарий, то точно забудем, что и как теперь надо менять. Если же комментарии не менять, то после того, как избавимся от ошибок компиляции, всё отладим и протестируем - забудем, какие функции менялись, и какие комментарии теперь надо исправлять.
Кстати, пока будем изобретать новое имя переменной для самодокументированного кода - то тоже половина необходимых изменений вылетит из головы. На одновременное решение нескольких сложных задач мозг, всё-таки, не очень рассчитан.
Dum_spiro_spero: Мне тоже очень интересно, как работают в крупных фирмах, как распределяются обязанности между специалистами в предметной области, алгоритмистами и программистами. И кто такие "аналитики".
Мне тоже всё приходится делать самому, и как делегировать часть работы программисту, я совсем не представляю.
"Готовые формулы", которые получит программист, должны быть в терминах остальной части проекта и вписываться в его структуру. А термины и структура по мере развития проекта имеют тенденцию меняться. В какой системе координат сегодня летает спутник? В геоцентрической? В системе барицентра "Земля-Луна"? Барицентра "Солнце-Юпитер"? Или вообще привяжемся к реликтовому излучению? Выбор, сделанный когда-то, может оказаться неудачным, и придётся многое переделывать. Включая структуру данных и порядок расчёта. И что делать бедному программисту - ждать, пока математики опять придумают своё неизвестно что, а потом начинать всё сначала? Или как-то участвовать в принятии решений? А для этого надо знать и математику, и физику, и всю задачу хотя бы на 2-3 слоя вокруг себя.
Xatory: В шутеры я не играл. Но всё-таки, когда вы повернули камеру вниз на 90 градусов, а потом нажали "влево" - что стало происходить с изображением?
И что не так в этом рассуждении (движение после поворота вокруг OY на 180 гр):
Итак, поворот вокруг OY на 180 гр. У нас a=c=0, b=pi.
dy1=dy; dz1=dz;
dx1=-dx; dz2=-dz;
dx2=-dx; dy2=dy;
Вектор (dx2,dy2,dz2) равен (-dx,dy,-dz), что и следовало ожидать.
Получается, что при движении "вперёд" (вектор (0,0,-1) в локальных координатах) камера движется по вектору (0,0,1) - удаляясь от точки, в которую смотрела исходно.
Xatory: Камера будет смотреть туда же, куда и до поворотов. Проверил.
Получается, что при третьем повороте изображение на экране вращалось по часовой стрелке, а не двигалось слева направо?
Камера всегда смотрит в начало координат? Если да - как пересчитываются её координаты?
Думаю, что вам достаточно хранить три параметра - сферические координаты центра камеры (угол поворота вокруг OX, угол поворота вокруг OZ, расстояние до центра) и при движениях вперёд/назад менять третий параметр.
Хорошо. Если вы повернёте камеру на 90 гр в направлениях (последовательно) вправо, вниз, влево, вверх - то что вы ожидаете получить? Кстати, в какой системе координат эти "вправо, вниз" определяются - в глобальной, или в системе камеры?
