CEBEP

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

Я много думал и переосмысливал сроки изучения си++, решил что логично поступить так: Считать си++ изученным если хорошо изучен "Язык программирования С++" [Бьерн Страуструп] (могу выложить если надо) + какая-нибудь метода по культуре написания кода (отбивка, переходы строк, пробелы, мена переменных и т.д.) + какая-нибудь книжечка на любую специфическую тему, чтобы понять, какие из приёмов языка в практике сгодились а какие решили не применять. Тогда представление о языке исчерпывающее и больше ничего не надо кроме практики. Её много не бывает. Возвращаясь же к топикстарту скажу, что, на мой взгляд, разумнее всего начинать с классического си, изучить на нём понятия массивов, функций, адресов и остального. Попробовать написать сортировку матрицы, обязательно программу по обработке строк (что ни будь типа удаления слов начинающихся с 'a' или преобразования числа в строку (как прописью так и цифрами полезно)), ещё очень хорошо бы изучить быстродействие тех или иных алгоритмов и недельку поковыряться с оптимизацией. После этого юный программист готов к пхп.

Поклонники моей персоны без труда вспомнят Я думаю, что на рабочем столе должно быть только то, с чем непосредственно идёт работа. Файлы. Потому он у меня даже перенесён с С на D, качаться всё по дефолту должно на него. А ярлыками захламлять ни к чему.

Я где-то в течении года устраивал тотализаторы в одной онлайн РПГ, пливлекало то что и азарт есть и потерять ничего ценного даже в случае сильного увлечения нельзя. В реальной жизни - тотализатор и пр. - ЗЛО! без добра и даже намёка на среднее. Да, можно нажиться, но имхо проще заработать. По поводу коэффициентов на собственном опыте (теорию читал, но не так чтобы уж): задачу следует разбивать на 3 части 1. Определение вероятности выигрыша той или иной ставки. В вырожденном случае: монета в 49.9(9)% - орёл/решка а в 0.(0)1% - ребро 2. Ожидание толпы. Если толпа ожидает другой исход, например, в случае договорного боя, можно очень ловко мотивировать ставками 3. Собственно подсчёт коэффициентов. В случае монетки 1.(9) на орёл, 1.(9) на решку и 100500 на ребро. Т. е. 1/49.9(9)%, 1/49.9(9)% и 1/0.(0)1% Дальше в коэффициентах учитываются налоги, откаты и п.р. и учитывается 2 пункт. По опыту самой выгодной является ситуация со множеством равновероятных исходов. В ней и огромное поле для договоров и обманов, причём никто ничего не докажет, и по-честному тоже всегда выгодно в основном. Пользуясь тем что я имел дело не с реальными деньгами я абстрагировался от этических вопросов и где можно обманывал, в реале не при каких обстоятельствах этим не займусь.

ну что что-то? консольную программу - одно. Можно например написать шифратор файлов достаточно быстро и он будет в какой-то степени годный. Или таймер какой-нибудь... Если говорить об интерфейсных приложениях то это вообще не стандартные библиотеки языка. В то же время можно взять, скажем MFC библиотеку и ничего не понимая в си соорудить из наворованных готовых кусков что-то похожее на "программу" Вообще, если хотите действительно разобраться берите счёт на годы... Я начал изучение 4 года назад и уверен что ещё не закончил.

Если вы думаете что знаете с++ - вы не знаете с++ (с) Страуструп Просто надо решить что такое "знать язык". И почему-то в рамках топика почти не различимы си и си++. И если вопрос всё таки о си то всё равно не понятно: сколько и кикие стандартные библиотеки нужно изучить, на сколько подробно, на сколько можно считать библиотеку изученной если вы не разбираетесь в её интерфейсе а всё что вам нужно переписали в собственной. Коротко говоря критерии установить не только трудно но и глупо.

первый.

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

нет, ну есть например блок поиска, выписываете его в отдельный файл, и php include... а вообще vs подсвечивает и javascript и css и html...

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

Если программист начал с пхп то он не получит представления о том как его программа тратит память, как бережет. Ещё, по моему, если не написать 2-3 программ на низкоуровневый анализ строк то понимание не придёт. Вообще не компилируемые языки это игрушка не для слабонервных. Вспомним хотя бы $a = 0; $b = ""; $c = "0"; $a==$b //true $a==$c //true $b==$c //false Если такого рода закидоны станут привычными то нормальный язык программирования где идёт строгий контроль за памятью, типами переменных и пр. сведёт с ума. Обратное - только частично. На мой взгляд, для программиста этот язык вообще не интересен, писать на нём надо только для конкретной цели. Удовольствие от программирования на таком языке получить можно но мало. Даже в рамках топика есть примеры явного недуга пхп: использование классов привело к увеличению времени исполнения програмы по сравнению с элементарным вызовом функции, а Страуструп, когда затевал писать с++ основным плюсом своей разработки справедливо считал исключительно семантическую роль классов, никак не влияющих на скорость исполнения кода. Да, класс стек может замедлить программу в 20 раз, но по сравнению с массивом а не с стеком реализованным через функции. Кроме того, время исполнения не компилируемых скриптов сильно зависит от их объёма, что для нормального языка - полное безумие.

4! п.с. мне тоже не понравилось...

Ну например можно задать полупрозрачными элементы цветографически интегрированные в хэдэр. То есть рамочка таблицы делается не константным цветом а либо через стили задаётся полупрозрачный слой либо добавляется png фон. Но на мой взгляд такой подход трудно реализовать. Если же затея заключена в том чтобы растягивать всё вместе с градиентным фоном то тут придётся возится с растягиванием изображений, что, по моему, не вариант. Идеальным вариантом на мой взгляд бы было просто заполнять незаполненную градиентом область цветом равным цвету нижнего пикселя градиента. При небольших (меньше 150px) растяжениях это будет почти незаметно и с точки зрения вёрстки просто. Горизонтальное меню с присными соответственно попадает в хэдэр из "мэйна". position: absolute; нужен чтобы высота хэдэра не учитывалась при построении страницы. Естественно при динамической высоте шапки такой вариант никчему не приведёт.

position: fixed; bottom:0px;

1. Можно сунуть ненужный див под нужный свойством z-index 2. Можно задать ненужному диву вид курсора как у нужного. Непосредственно решения вашей задачи в браузеры не интегрировано.

при расчёте высоты страницы браузеры не учитывают top: -279px; а считают как будто всё расположено в естественном порядке. Мой вариант лечения: задать хэдэру абсолютное позиционирование, убрать top: -279px; и соответственно position: relative; после чего добавить в #main соответствующий margin-top

Microsoft Visual Studio

+1 списки в основном удобнее оставлять как есть.

Ваш код необходимо заменить на следующий: <?php }//Эта фигурная скобочка вообще не по делу. Она от какой-то расположенной выше части скрипта. Не в коем случае не трогайте её. if( $shipping ) { ?> <tr> <td>информация</td> <td><?php echo $shipping_display ?></td> </tr> <?php } Это если $shipping не может быть меньше нуля. в противном случае <?php }//Эта фигурная скобочка вообще не по делу. Она от какой-то расположенной выше части скрипта. Не в коем случае не трогайте её. if( $shipping > 0 ) { ?> <tr> <td>информация</td> <td><?php echo $shipping_display ?></td> </tr> <?php }

да блин! for(операция1; условие; операция2){тело цикла} исполняется так: операция1 тело цикла операция2 если условие == true тело цикла операция2 если условие == true тело цикла операция2 если условие == true тело цикла операция2 если условие == true тело цикла операция2... То есть ВСЕГДА один раз тело цикла выполняется НЕЗАВИСИМО от условий цикла! В первом примере всё работает совершенно корректно, у меня крепнет убеждение что вы его даже не пытались скомпилировать.

я строго за ё! её без ё никак не написать а ёё так вообще. З.Ы. У нас препод по термеху обладает удивительной способностью: практически все е произносит как е... и даже некоторые и...

да? а у меня выводит. первая итерация for безусловна. ну раз так то можно усложнить жизнь #include <stdio.h> #include <math.h> void main() { double b, x, x1, x2, d, y; printf("Введите начальное положение и конечное"); scanf("%lf%lf", &x1, &x2); printf("\n┌─────────────┬────────────┐"); printf("\n│ x │ f(x) │ "); b = ( x2 - x1 ) / 9; int flagOfOneIteration = 0; x = x1; while((x <= x2 && b) || !flagOfOneIteration) { if(x<-1.) y=-2-x; else if(x<0.) y=(-2+sqrt(4-4*pow(x,2.)))/2; else if(x<2.) y=(4-sqrt(16-4*pow(x,2.)))/2; else if(x<4.) y=-1.; else y=(x/2)-3; printf("\n├─────────────┼────────────┤"); printf("\n│ %7.2lf │ %7.2lf │", x,y); ++flagOfOneIteration; x+=b; } printf("\n└─────────────┴────────────┘"); } Так как в классике внутри тела цикла for менять параметры цикла - безумие, переходим на while. Но я уверен что вы что-то не так сделали с моим предыдущим примером.

document.getElemetsByTagName('head')[0].innerHTML += '<script ....></script>' разве не работает?

видимо ваши дивы свёрстаны так что в IE между layer1 и layer12/layer11 есть отступ, другой элемент или что-либо ещё. Это приводит к срабатыванию выключения появившихся дивов (сработало onMouseOut), а в фф такого нет потому что нет и разрывов. + рекомендую переписать скрипты <script language="javascript"> function displayElems() { document.getElementById('layer11').style.display = 'block'; document.getElementById('layer12').style.display = 'block'; } function hideElems() { document.getElementById('layer11').style.display = 'none'; document.getElementById('layer12').style.display = 'none'; } </script> И соответственно <div id="layer1" onmouseover ="displayElems()" onmouseout ="hideElems()">DIV 1</div> <!-- основной--> <div id="layer11" onmouseout ="hideElems()">DIV 1 right</div> <!-- дополнительный 1--> <div id="layer12" onmouseout ="hideElems()">DIV 1 bottom</div> <!-- дополнительный 2-->

1. блок и маргин применять к <a> 2. float имхо(!) при заполнении контента не должно быть классов так как классы всё-таки для чего-то большого, обобщающего. Я лично всё пихаю в параметр style. По поводу неиспользования параметров вы совершенно правы, их не должно быть. Естественно за исключением href, alt, src, style, class, id и прочего...