The Winapi (C Win32 API, No MFC) tutorial
Нашел тут очень приятные и легкие в понимании примеры для WinAPI
На английском.
The Winapi (C Win32 API, No MFC) tutorial
История противостояния OpenGL и Direct3D
Автор - Nicol Bolas
Переводчик - kurokikaze - http://kurokikaze.habrahabr.ru/
Оригинал - http://programmers.stackexchange.com/questions/60544/why-do-game-developers-prefer-windows/88055
Перевод - http://habrahabr.ru/blogs/gdev/123194/
От автора:
Перед тем как мы начнём, скажу: я знаю об OpenGL гораздо больше чем о Direct3D. Я в жизни не написал ни одной строки кода для D3D, и я писал руководства по OpenGL. Так что то что я тут расскажу, не вопрос предвзятости. Теперь это просто история.
Зарождение конфликта
Однажды, в начале 90-х, Microsoft огляделась вокруг. Они увидели замечательные Super Nintendo и Sega Genesis, на которых было много отличных игр. И они увидели DOS. Разработчики писали для DOS так же как для консолей: прямо на железе. Но, в отличии от консолей, где разработчик точно знал каким железом располагает пользователь, разработчики для DOS вынуждены были писать в расчёте на множество различных конфигураций оборудования. А это гораздо сложнее, чем кажется на первый взгляд.
У Microsoft в то время была ещё большая проблема: Windows. Windows хотела единолично распоряжаться оборудованием, в отличие от DOS, позволявшей разработчику делать всё что ему заблагорассудится. Владение оборудованием было обязательно для того чтобы упорядочить взаимодействие между приложениями. Взаимодействие-то и не нравилось разработчикам игр, потому что забирало ценные ресурсы, которые они могли использовать для своих замечательных игр.
Чтобы привлечь разработчиков игр в Windows, Microsoft нужен был единый API который был бы низкоуровневым, работал в Windows и при этом не страдал от тормозов и, самое главное, абстрагировал бы от разработчика оборудование. Единый API для графики, звука и пользовательского ввода.
И так родился DirectX.
3D ускорители появились на свет несколько месяцев спустя. И перед Microsoft встало сразу несколько проблем. Видите ли, DirectDraw, графический компонент DirectX, работал только с 2D графикой: выделением графической памяти и побитовым копированием между разными выделенными секциями памяти.
И Microsoft купили некий промежуточный драйвер и сделали из него Direct3D версии 3. Его ругали все и повсюду. И не просто так; одного взгляда на код было достаточно чтобы отшатнуться в ужасе.
Старый Джон Кармак из Id Software взглянул на этот мусор, сказал: «К чёрту!», и решил писать под другой API — OpenGL.
Другая часть этого клубка проблем состояла в том что Microsoft были очень заняты совместной работой с SGI над реализацией OpenGL для Windows. Идея была проста — привлечь разработчиков типичных рабочих GL-приложений: систем автоматического проектирования, моделирования, всего такого. Игры были последним, о чём тогда думали в Microsoft. Это всё предназначалось для Windows NT, но Microsoft решили добавить эту реализацию и в Win95.
Чтобы привлечь внимание разработчиков профессионального софта к Windows, Microsoft попробовали подкупить их доступом к новым функциям ускорителей трехмерной графики. Microsoft сделали протокол Installable Client Driver: производитель графического ускорителя мог перегрузить программную реализацию OpenGL аппаратной. Код просто автоматически использовал аппаратную реализацию если она была доступна.
Qt. Получение списка сетевых интерфейсов.
QList<QNetworkInterface> getInterface() { //берем все интерфейсы, которые есть в системе QList<QNetworkInterface> networkInterfaces = QNetworkInterface::allInterfaces(); for(int i = 0; i < networkInterfaces.size(); i++) { QFlags<QNetworkInterface::InterfaceFlags> _flags = networkInterfaces.at(i).flags(); //если интерфейс выключен или если это вообще loopback if(!(QNetworkInterface::IsUp & _flags) || (QNetworkInterface::IsLoopBack & _flags)) { //то убираем его из списка networkInterfaces.removeAt(i); } } //возвращаем список работающих и активных интерфейсов return networkInterfaces; }
QTableWidget. Запрет редактирования столбцов.
Проще всего делается через делегат.
class NonEditTableColumnDelegate : public QItemDelegate { Q_OBJECT public: NonEditTableColumnDelegate(QObject * parent = 0) : QItemDelegate(parent) {} virtual QWidget * createEditor ( QWidget *, const QStyleOptionViewItem &, const QModelIndex &) const { return 0; } };
Использование:
aTable = new QTableWidget(this); aTable->setColumnCount(3); //запрещаем редактирование первого столбца aTable->setItemDelegateForColumn(0, new NonEditTableColumnDelegate()); //запрещаем редактирование второго столбца aTable->setItemDelegateForColumn(1, new NonEditTableColumnDelegate()); //итого из трех столбцов редактироваться будет только последний
Компиляция программ в консоли Линукс (на примере CentOS)
Для компиляции программ необходимо установить gcc.
Для С:
yum install gcc
Для С++:
yum install gcc-c++
Программы достаточно удобно писать в MC (yum install mc.i386)
Делаем: mcedit <имяфайла> (например mcedit hello.cpp - окончание у файлов *.cpp - c++, а *.c - C)
В появившемся оконце набираем свою программу. Например, классическое, на С++:
#include <iostream> using namespace std; int main() { cout << "Hello, world" << endl; return 0; }
Нужно делать типа пустую строку после окончания набора кода.
Жмем F2 для сохранения и F10 для выхода (или еще можно "сворачивать" редактор нажатием ctrl+o (разворачивать также)
Теперь набираем:
g++ hello.cpp -o hello
и, если все правильно, получаем на выходе исполняемый файлик hello, который можно юзать - ./hello
Для С-программ:
gcc <имя_файла> -o <имя_выходного_файла>
Изучить. Для новой работы.
Qt (link)
SQL (уже знаю. попрактиковаться в написании боевых приложений)
XML
SVG (wikilink)
Modbus TCP (wikilink)
TCP, UDP
libpcap (1 - wikilink, 2 - link)
По Qt сразу:
Building static Qt on Windows:
1. http://www.qtcentre.org/wiki/index.php?title=Building_static_Qt_on_Windows
2. http://blog.lugru.com/2009/03/qt-static-mingwm10dll-and-deployment-under-windows-environment/
3. http://doc.qt.nokia.com/4.6/deployment-windows.html#static-linking
Вот. Выглядит жутковато. Для 3 недель-то.
Аналог atoi
int atoi(char *str) { std::string mS = str; //получаем строку std::istringstream mStream(mS); //преобразуем строку в поток int tmp; mStream >> tmp; //выгружаем из строкового потока в переменную return tmp; }
Простой и короткий вариант. По разным обсуждением в интернете - медленный. Связано это с потоковыми обработками.
14 октября языку программирования С++ исполнилось 25 лет
Первый официальный гид по новосозданному языку С++ появился ровно 25 лет назад. Тогда еще мало кому известный Бьерн (Бьярнэ в датской транскрипции) Страуструп 14 октября 1985 года представил новый язык программирования высокого уровня, который позволял писать программы для разных компьютеров, используя почти неизменный программный код, который был ближе к языку людей, нежели к машинным кодам.
В последнее время С++ становится самым широко используемым языком программирования, который поддерживает объектно-ориентированное программирование. Страуструп стал первопроходцем в области использования объектно-ориентированной и общей техник в области создания программных приложений, где эффективность является приоритетным свойством, таких как симуляторы, графика, пользовательские интерфейсы, прикладные системы, системы для научных вычислений.
Книга Страуструпа "Язык программирования C++" — одна из самых широко читаемых книг из своей области, которая была переведена на 19 языков. Следующая книга, "Дизайн и эволюция C++", открыла много нового в описании языков программирования: новые идеи, идеалы, проблемы. В дополнение к своим пяти книгам, Страуструп опубликовал более сотни академических и других популярных статей.
Бьёрн принимал активное участие в создании стандарта ANSI/ISO для C++ и продолжает работу по поддержанию и пересмотру стандарта.
Текст взят отсюда http://www.xakep.ru/post/53535/default.asp
День программиста или маленькая программка на asm’е.
Старый добрый debug.exe, с легкой подачи Di, позволил написать праздничный вариант программы "Hello, world!"
-a 100
0B2F:0100 mov ah,09
0B2F:0102 mov dx,0109
0B2F:0105 int 21
0B2F:0107 int 20
0B2F:0109 db "S Dniom Programmista$"
0B2F:011E
-rcx
CX 0000
:011e
-n s_dniom.com
-w
Writing 0011E bytes
-q
Объектно-ориентированное программирование. Введение.
Существует два основных способа проектирования программных систем – структурное проектирование, основанное на алгоритмической декомпозиции, и объектно-ориентированное проектирование, основанное на объектно-ориентированной декомпозиции. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое значение агентам, которые являются либо объектами, либо субъектами действия. Однако эти способы, по сути, ортогональны, поэтому нельзя сконструировать сложную систему одновременно двумя способами. Необходимо начать разделение системы либо по алгоритмам, либо по объектам, а затем, используя полученную структуру, попытаться рассмотреть проблему с другой точки зрения.
Алгоритмическую декомпозицию можно представить как обычное разделение алгоритмов, где каждый модуль системы выполняет один из этапов общего процесса. При объектно-ориентированной декомпозиции каждый объект обладает своим собственным поведением, и каждый из них моделирует некоторый объект реального мира. С этой точки зрения объект является вполне осязаемой вещью, которая демонстрирует вполне определенное поведение. Объекты что-то делают, и мы можем, послав им сообщение, попросить их выполнить некоторые операции.
Объектная декомпозиция имеет несколько преимуществ перед алгоритмической:
• объектная декомпозиция уменьшает размер программных систем за счет повторного использования общих механизмов, что приводит к существенной экономии выразительных средств;
• объектно-ориентированные системы более гибки и проще эволюционируют со временем, потому что их схемы базируется на устойчивых промежуточных формах. Действительно, объектная декомпозиция существенно снижает риск при создании сложной программной системы, так как она развивается из меньших систем, в которых мы уже уверены;
• объектная декомпозиция помогает нам разобраться в сложной программной системе, предлагая нам разумные решения относительно выбора подпространства большого пространства состояний.
В объектно-ориентированном анализе существует четыре основных типа моделей: динамическая, статическая, логическая и физическая. Через них можно выразить результаты анализа и проектирования, выполненные в рамках любого проекта. Эти модели в совокупности семантически достаточно богаты и универсальны, чтобы разработчик мог выразить все заслуживающие внимания стратегические и тактические решения, которые он должен принять при анализе системы и формировании ее архитектуры. Кроме того, эти модели достаточно полны, чтобы служить техническим проектом реализации практически на любом объектно-ориентированном языке программирования.
Фактически все сложные системы можно представить одной и той же (канонической) формой – в виде двух ортогональных иерархий одной системы: классов и объектов. Каждая иерархия является многоуровневой, причем в ней классы и объекты более высокого уровня построены из более простых. Какой класс или объект выбран в качестве элементарного, зависит от рассматриваемой задачи. Объекты одного уровня имеют четко выраженные связи, особенно это касается компонентов структуры объектов. Внутри любого рассматриваемого уровня находится следующий уровень сложности. Структуры классов и объектов не являются независимыми: каждый элемент структуры объектов представляет специфический экземпляр определенного класса. Объектов в сложной системе обычно гораздо больше, чем классов. С введением структуры классов в ней размещаются общие свойства экземпляров классов.
Структурный подход состоит в декомпозиции (разбиении) системы на элементарные функции, т.е., система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом создаваемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:
• принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
• принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне – так называемый принцип иерархического упорядочивания.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
• DFD (Data Flow Diagrams) диаграммы потоков данных;
• ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".
На стадии проектирования системы модели расширяются, уточняются и дополняются диаграммами, отражающими ее структуру.
Перечисленные модели в совокупности дают полное описание системы независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.