Pull to refresh

Comments 28

Конец сожрался:
#include "windows.h"
#include < string>
#include <map>
#include <set>
#include <vector>
#include <list>
#include <algorithm>

using namespace std;


Вот я присоединился к блогу Mobile Development и теперь что? Снова их там создавать? Или как-то указать в статье, чтобы она и там была видна?
нет просто в режиме редактирования статьи выберите другой блог для сохранения
Отредактируйте статью и выберите вверху блог, в который ее хотите положить.
Спасибо за инфу, вроде бы получилось.
Спасибо за статью. И остальные статьи (; И хочу присоединиться к XaocCPS, неудобно добавлять все что связано с мобильной разработкой в избранное, список захламляется, а отсматривать всю «разработку» в поисках постов «про мобильники» тоже неудобно, пишите пожалуйста в mobiledev.
а вообще, прочитал текст и какое-то неоднозначное мнение

что касается технической стороны — хорошо
что касается стиля изложение — не понравилось:

«учили алфавит по третьему изданию справочника»
«Если Вы все еще здесь – продолжаем!»
«Вот еще странный кусок кода»
«ОС браузер Chro..., то есть Oper.., то есть Inernet Explorer! Фуу, вспомнил название-таки! „
“Почему? Потому что! „

для кого эти фразы и зачем?
Согласен с Вами.
Статья в целом действительно очень неплоха и полезна (техническая составляющая, все-таки, главная), но стиль действительно немного подкачал. Этих эмоциональных развлекалок, скажем, многовато, если они все не лишние.
Это авторский стиль! Представьте, что эту статью писал Пушкин. Он бы не стал пользоваться сухим техническим языком, верно? ;-)
да я не спорю :) ради бога
но вы наверняка знаете, что даже Пушкин не всем нравится :)
Пушкин не стал бы пользоваться C++:)
>>1. eMbedded Visual C++ 4.0 (TRT7H-KD36T-FRH8D-6QH8P-VFJHQ)
Это что ли серийник? Нехорошо такие вещи писать. Хуже только ссылку на торент дать.

Придирки к технической составляющей:
>> wstring UniCODE(string w)
>> string ANSI(wstring w)
w передается по значению — лишнее копирование. Если часто используется — много расходов и дефрагментация памяти. Самый правильный вариант — сделать функцию inline и написать const wstring& w, тогда и w не будет копироваться и возвращаемое значение не будет.

>>wstring ApplicationPath()
>>{
>>TCHAR Path[MAX_PATH + 1] = {0};
>>…
>>return Path;
Имхо, в таких местах лучше вместо TCHAR использовать сразу wchar_t. Так как вы все равно возвращаете юникод-строку — зачем вам тогда TCHAR?

>>Вот как у меня выглядит начало h-файла, который включается в каждый компилируемый файл первым:
Это вы так прекомпилед хедер обозвали? :)

>>using namespace std;
А за такой код в stdafx.h надо сажать перечитывать умные книжки. И выписывать тезисы в тетрадку :)
(* краснеет и пытается затереть серийник мелом *)

Насчет оптимизации строковых функций — возможно Вы правы, варианты получше наверняка можно придумать. А TCHAR это уже по привычке идет — чтобы не думать.

stdafx.h я не использую и не знаю что это такое. Прекомпайлед хедеры тоже не использую. Патамушта! ;-)

>>stdafx.h я не использую и не знаю что это такое. Прекомпайлед хедеры тоже не использую. Патамушта! ;-)
stdafx.h — это стандартный прекомпайлед хедер в VS.
А с чем связана нелюбовь к прекомпайледам, если вы все равно в каждый cpp включаете один и тот же h файл?
С прекомпайледом будет компилироваться проект гораздо быстрее.
Мои эксперименты показали, что прекомпайлед хедеры компилируются медленней и глюкают. Может делал криво, не знаю.
Да, похоже криво.
Они для того и придуманы, чтобы ускорять билд.
Из опыта: На крупном проекте как-то, который билдился 20 минут, повсеместное внедрение прекомпайледов сократило время билда минут до 6-7.
eMbedded Visual C++ 4.0 распространяется Microsoft'ом бесплатно!
И этот серийник приведён на странице загрузки eMbedded Visual C++ 4.0.
… я правда не понимаю, как можно писать статью о программировании под WinCE и не знать этого. :))

М… я бы порекомендовал Visual Studio 2005 для новичков — она уже сразу идет со всем нужным барахлом(кроме ActiveSync) и даже есть предопределенные шаблоны проектов + запуск/дебаг одной кнопокй
При загрузке DLL под Win32 имя ее файла должно быть в ANSI. Хотя проект и под UNICODE. Почему?
Не имя DLL должно быть в ANSI, а имя функции. Почему? Да потому что стандарт С разрешает использовать в именах функций (и других идентификаторах) только альфанумерик и _.
И да
For Windows CE 3.0 and later, the ASCII version of this function, GetProcAddressA, is supported. With this version, the lpProcName parameter is of the type LPCSTR.
Дак поправьте статью :)

И ещё, по поводу вот этого куска:
string f_name = ANSI(func_name);
FARPROC f = GetProcAddress(h, f_name.data());

Почитаем стандарт (21.3.6/3)
const charT* data() const;
Returns: If size() is nonzero, the member returns a pointer to the initial element of an array whose first
size() elements equal the corresponding elements of the string controlled by *this. If size() is
zero, the member returns a non-null pointer that is copyable and can have zero added to it.

То есть стандарт не требует, чтобы массив, на который указывает data(), заканчивался нулевым символом. В случае выше вместо data() правильнее использовать c_str(). А лучше вообще выкинуть функцию ANSI и пользоваться вышеупомянутой GetProcessAddressA().
UFO landed and left these words here
Когда я начинал проект 5-й Mobile только появился, а 2003 было еще много.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.