Другое различие - то, что функциональные типы возврата и типы параметра не должны были быть определены. Они, как предполагалось бы, были бы ints.
f(x)
{
return x + 1;
}
и
int f(x)
int x;
{
return x + 1;
}
идентичны.
Хорошо, если говорить о себе как о студенте CS :)
Я нахожу статьи Страуструпа очень приятными и практичными , не вдаваясь в бесполезные детали. Возьмем, к примеру, его статью о объектно-ориентированном программировании , одно из лучших произведений, которые я когда-либо читал. Это идет от самой базовой идеи программирования до модульного программирования, проходящего через идею ООП. Он показывает , почему нам нужны эти парадигмы программирования в примерах коротких фрагментов. Вот парадигмы, которые он последовательно использует:
Еще одно фантастическое чтение - Шестнадцать способов сложить кошку . A 16 другой способ записи стека в C ++ (язык на самом деле не имеет значения). Возьмите их и сравните преимущества / недостатки большинства парадигм, которые я знаю / слышал.
Unfortunately, inexperienced programmers often don't realise they have a problem until they run in to it for themselves. I think the best way to see problems in the real world is for students to have 'real world' problems which are probably best found outside of a classroom thats teaching CS principals. (I guess SoftEng would be taught a little differently in this regard)
Code Complete + Head First Design Patterns are the two books I'd recommend every undergrad read before graduating.
Oh, and they should have at least one finished (or mostly finished) extra-cirricular project. A website, game, utility-app whatever.
Серия статей дяди Боба The Apprentice о мастерстве разработки программного обеспечения. Имеет приятный стиль повествования, в котором, я думаю, студенты могут относиться к главному герою, поскольку он / она начинает с скромного ученика.
Один из самых популярных вопросов на этом сайте: Какая самая важная книга, которую должен прочитать каждый программист?
I'll get the ball rolling with:
Generally, these patterns developed because of problems of maintaining and developing large code. Programmers are always strapped for time, and none of them decided that we needed more fluff. Most programmers won't work on the same code throughout the software life-cycle, so there needs to a way for programmers to understand each other's code without having to read a couple million lines of code.
The real world building analogy:
Вы не сделаете здание без стыков. В противном случае он потрескается и сломается, вздымаясь от холода / тепла. Интерфейсы - это ваши соединения между двумя, возможно, жесткими объектами.
Вы делаете его модульным, поэтому возможен ремонт.
Вы не делаете все из одного и того же материала. (сантехника не деревянная)
Вы проектируете его таким образом, чтобы несколько подрядчиков могли работать над зданием одновременно.
Человек, который использует здание, просто хочет его использовать и не заботится о том, как
вы построили это.
Лица, которые осматривают здание, - это те же люди, которые строят его.
Можно использовать установщики и приемники класса A. Это дает то же чувство, что и если вы используете объект класса A.
-121--2172897-Архитектура нарушена. Частные участники являются частными, так как не требуется доступ к ним вне класса и к друзьям.
Вы можете использовать взломы друзей, средства доступа, продвигать участника или # определять частные общедоступные
(heh). Но это все краткосрочные решения - вероятно, придется на каком-то этапе вернуться к нарушенной архитектуре.
Прагматичные программисты хорошо прагматичны, но они хорошо разбираются в теории CS и знают, когда и как ее применять.