azShoo У меня для вас еще худшие новости: элементарный рассчет в уме показывает, что 90% считающих себя программистами - не программисты... что, в общем-то, увы - довольно точно кореллирует с наблюдениями по жизни :)
tsarevfs Вы меня прямо смутили столь категоричным утверждением ;) Разумеется, возможны варианты, хорошие и разные... Но! В некоторых случаях (Buddy memory allocation) "куча", в смысле механизма динамического распределения памяти, таки прямо реализуется на основе одной из одноименных структур данных (Heap), или, выражаясь еще проще - на дереве :)
Остается только уточнить, что сами понятия "стек" и "куча" изначально - структуры данных с определенными свойствами/поведением. Они активно используются ЯП (так же, как, например, бинарные деревья используются в реляционных базах данных). Kак конкретно эти структуры реализованы, полностью зависит от компилятора/рантайма и ОС/платформы. Если брать, например, Java, то там вообще сама JVM в принципе - стековый автомат (а не процессор с регистрами, как это имеет место быть в распространенных железных процессорах).
Начинать лучше с начала - т.е. с логики и эпистемологии. А дальше читать все, что под руку попадет - от древних греков до современников... и вырабатывать собственную систему представлений о закономерностях и устройстве бытия. Только это невозможно и довольно таки бессмысленно без всего остального, так что, параллельно с этим нужно интересоваться и математикой, и физикой, и литературой, и историей... короче - получать самое обыкновенное классическое образование, которое потом действительно поможет "разобраться самостоятельно" :)
Охотно. Если под "меташаблонами" вы подразумеваете конкретные учения (например, категорический императив Канта), то помогают они, разумеется, не непосредственно. Они - своего рода туториалы. На разных примерах демонстрируют применение метода познания: от анализа к синтезу. Вот он помогает конкретно, в т.ч. и в работе :)
MSDN... Это такая Отче Наш от Майкрософта... уважаюший себя программер может процитировать с любого места, даже если его разбудить в 4:30 утра :) А если серьезно, весьма полезный источник знаний, особенно для тех, кто под Винду программирует.
К сожалению, это очень распространенная ересь, встречал такое даже в более-менее солидных фирмах. Когда один особенно убежденный начальник продолжал настаивать на своей правоте, игнорируя все рациональные аргументы, я просто взял и шутки ради переписал пару классов, использовав для названий переменных транслит с пяти разных языков. Только это его в конечном счете и убедило :)
@Applez Ну, подсмотреть на скорую руку можно, например, на oodesign
Скажем так: там я не нашел ни одного паттерна, который бы не приходилось использовать постоянно :)
Не нужно писать такие методички! У студентов может сложиться впечатление, что паттерны, как аккорды - достаточно знать несколько "самых распространенных", и слабаешь любой шлягер... а это, мягко говоря, профанация! Никто не раздумывает, а какой бы такой паттерн применить для вот этого конкретного задания. Идея выделить "самые распространенные" совершенно оторвана от реальности. На самом деле, для задания просто находят решение, и это решение оказывается тем лучше/качественнее/элегантнее/адекватнее, чем больше разных паттернов разработчик знает, и, следовательно, мог принять во внимание при проектировании данного конкретного решения. Вот и все. Паттерны, это не аккорды, и даже не гаммы, а законы гармонии. Соответственно, нельзя знать некий "необходимый минимум" - можно либо понимать, что это такое и иметь достаточно опыта для решения конкретной задачи, или нет. В первом случае разные программисты могут по факту использовать совершенно разные паттерны, но задача будет решена адекватно, во втором ни один самый волшебный паттерн не спасает. А для понимания паттернов есть только один путь - много читать, разбираться, использовать на практике, набивать шишки. Именно от этого по данной теме так многАбукАФ написали и еще напишут... и читать их нужно, по возможности, все.
Кхе-кхе... ни разу не споря со сказанным, просто добавлю на полях, что дипломная работа, строго говоря, должна демонтстрировать умение автора пользоваться научными методами, а ее результаты - обладать хотя бы минимальной научной ценностью.
На упрощенном примере: вычислить сторону треугольника по теореме Пифагора - не имеет научной ценности, в то время, как доказать теорему Пифагора доселе неизвестным способом - вполне.
@Rostel: Спасибо за идею! Увы, доступа к XENу нет никакого. Тамошние админы, похоже, даже не знают, что это такое и за любым чихом обращаются к какому-то подрядчику, что стоит денег и мороки... короче, если их не тыкнуть носом в проблему, никаких телодвижений там не будет :( Уточняющий вопрос: если XPET выключен, значит ли это, что ядро будет при любом раскладе показывать (например, через iostat) stolen time = 0,00 ?
Нет, "мы не будем делать за вас лабораторку" :) Если "с математикой" настолько плохо, что непонятно, как позиционировать квадрат внутри прямоугольника, то и толку от примера не будет ровным счетом никакого. Попробуйте самостоятельно напрячь мозги, приведите здесь пример собственного творчества... его охотно поправят, укажут на ошибки и разъяснят непонятное. Делать работу за вас (тем более, такую элементарную) тут вряд ли кто-то станет. Для этого есть фриланс :)
А в чем вопрос-то? Кас сделать? Оч просто: из оригинала кропнуть максимально возможную квадратную область, если она больше превьюхи - уменьшить, возможно, с применением фильтра Ланчоса (для сохранения четкости изображения).
Отдельная песня - если в оригинале смысловой фокус изображения не совпадает с геометрическим (например, лицо юзера на краю прямоугольного группового снимка). Для таких случаев уважающие себя системы предлагают сначала установить область, подлежащую вырезанию-скалированию, вручную.
@stalker7q Мastech - вполне приличный, выше среднего... китаец :) А это, извините, несколько иные и инженерная школа, и культура производства. Хотя, в подавляющем большинстве случаев/потребностей эта разница вообще не будет играть заметную роль. Так что, я не стал бы говорить, что он мне "не угодил" - это слишком категорично. В своем ответе я просто обозначил диаппазон того, что есть на рынке. Просто взгляните сюда, сюда и сюда.
@bm13kk Увы - в общем случае нет другого пути :( Единственно, что частично помогло мне лично - обращаться к хедхантерам, проводящим предв. отсев. Однако даже тут из 5-7 именитых и дорогих фирм 99% - фуфло. Одна единственная фирма подгоняет реально хороших кандидатов. Но т.к. цены весьма заоблачные, этот вариант подходит далеко не для каждого проекта.
@StrangeAttractor Ну, теоретически, конечно - да. Но в случае с JPEG это давно стало практически не актуально, т.к. файл обрабатывается целиком, т.е. когда все данные "уже есть" (как правило, на носителе с произвольным доступом). Для примера, в том же MP3 метаданные вполне себе стандартно могут находиться в хвосте и никого это особенно не смущает. Такой подход принципиально важен только для стрима или для носителя с последовательным доступом, типа магнитной ленты. При поблочном чтении или в памяти (где прыжок на любое смещение практически ничего не стоит) никакого принципиального преимущества, кроме морального удовлетворения, он не дает :)
@barkalov Ну, по сути вопроса мне, например, просто не до конца понятен физический смысл требуемого ограничения... Если указанная сила F - развиваемая двигателем тяга, а "ограничение" подразумевает, что эта тяга просто не должна превысить некоторый заданный предел, то рассуждения кажутся мне справедливыми, ибо мощность двигателя (в терминах ньютоновской механики) есть способность двигателя развить определенную тягу (момент силы). Для грубой модели такой подход сойдет.
Более реалистичной была бы модель, учитывающая 1. инерционность двигателя (грубо - если пилот скачкообразно переведет РУД на взлетный режим, изменение F займет некоторое время) и нелинейность зависимости производимой тяги от, скажем, количества сжигаемого топлива (или чего-то другого, выступающего в модели в качестве управляющей величины).
Вспомните "автомобильные" графики зависимости развиваемого крутящего момента от оборотов двигателя внутреннего сгорания. (Не считая себя великим физиком, рискну тем не менее предположить, что аналогичное явление должно наблюдаться для реактивного двигателя на сжимаемом рабочем теле).
