Комментарии 28
Конец сожрался:
#include "windows.h" #include < string> #include <map> #include <set> #include <vector> #include <list> #include <algorithm> using namespace std;
0
Есть блог Mobile Development
habrahabr.ru/blogs/mobiledev/
может туда статью перенесете?
еще можно для улучшения читаемости раскрасить c++ синтаксис
через source.virtser.net/
habrahabr.ru/blogs/mobiledev/
может туда статью перенесете?
еще можно для улучшения читаемости раскрасить c++ синтаксис
через source.virtser.net/
+1
Окей, попробую.
0
Вот я присоединился к блогу Mobile Development и теперь что? Снова их там создавать? Или как-то указать в статье, чтобы она и там была видна?
0
Спасибо за статью. И остальные статьи (; И хочу присоединиться к XaocCPS, неудобно добавлять все что связано с мобильной разработкой в избранное, список захламляется, а отсматривать всю «разработку» в поисках постов «про мобильники» тоже неудобно, пишите пожалуйста в mobiledev.
0
а вообще, прочитал текст и какое-то неоднозначное мнение
что касается технической стороны — хорошо
что касается стиля изложение — не понравилось:
«учили алфавит по третьему изданию справочника»
«Если Вы все еще здесь – продолжаем!»
«Вот еще странный кусок кода»
«ОС браузер Chro..., то есть Oper.., то есть Inernet Explorer! Фуу, вспомнил название-таки! „
“Почему? Потому что! „
для кого эти фразы и зачем?
что касается технической стороны — хорошо
что касается стиля изложение — не понравилось:
«учили алфавит по третьему изданию справочника»
«Если Вы все еще здесь – продолжаем!»
«Вот еще странный кусок кода»
«ОС браузер Chro..., то есть Oper.., то есть Inernet Explorer! Фуу, вспомнил название-таки! „
“Почему? Потому что! „
для кого эти фразы и зачем?
0
Согласен с Вами.
Статья в целом действительно очень неплоха и полезна (техническая составляющая, все-таки, главная), но стиль действительно немного подкачал. Этих эмоциональных развлекалок, скажем, многовато, если они все не лишние.
Статья в целом действительно очень неплоха и полезна (техническая составляющая, все-таки, главная), но стиль действительно немного подкачал. Этих эмоциональных развлекалок, скажем, многовато, если они все не лишние.
0
Это авторский стиль! Представьте, что эту статью писал Пушкин. Он бы не стал пользоваться сухим техническим языком, верно? ;-)
+2
>>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 надо сажать перечитывать умные книжки. И выписывать тезисы в тетрадку :)
Это что ли серийник? Нехорошо такие вещи писать. Хуже только ссылку на торент дать.
Придирки к технической составляющей:
>> 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 надо сажать перечитывать умные книжки. И выписывать тезисы в тетрадку :)
+2
(* краснеет и пытается затереть серийник мелом *)
Насчет оптимизации строковых функций — возможно Вы правы, варианты получше наверняка можно придумать. А TCHAR это уже по привычке идет — чтобы не думать.
stdafx.h я не использую и не знаю что это такое. Прекомпайлед хедеры тоже не использую. Патамушта! ;-)
Насчет оптимизации строковых функций — возможно Вы правы, варианты получше наверняка можно придумать. А TCHAR это уже по привычке идет — чтобы не думать.
stdafx.h я не использую и не знаю что это такое. Прекомпайлед хедеры тоже не использую. Патамушта! ;-)
0
>>stdafx.h я не использую и не знаю что это такое. Прекомпайлед хедеры тоже не использую. Патамушта! ;-)
stdafx.h — это стандартный прекомпайлед хедер в VS.
А с чем связана нелюбовь к прекомпайледам, если вы все равно в каждый cpp включаете один и тот же h файл?
С прекомпайледом будет компилироваться проект гораздо быстрее.
stdafx.h — это стандартный прекомпайлед хедер в VS.
А с чем связана нелюбовь к прекомпайледам, если вы все равно в каждый cpp включаете один и тот же h файл?
С прекомпайледом будет компилироваться проект гораздо быстрее.
0
Мои эксперименты показали, что прекомпайлед хедеры компилируются медленней и глюкают. Может делал криво, не знаю.
0
eMbedded Visual C++ 4.0 распространяется Microsoft'ом бесплатно!
И этот серийник приведён на странице загрузки eMbedded Visual C++ 4.0.
… я правда не понимаю, как можно писать статью о программировании под WinCE и не знать этого. :))
И этот серийник приведён на странице загрузки eMbedded Visual C++ 4.0.
… я правда не понимаю, как можно писать статью о программировании под WinCE и не знать этого. :))
+2
М… я бы порекомендовал Visual Studio 2005 для новичков — она уже сразу идет со всем нужным барахлом(кроме ActiveSync) и даже есть предопределенные шаблоны проектов + запуск/дебаг одной кнопокй
+1
При загрузке DLL под Win32 имя ее файла должно быть в ANSI. Хотя проект и под UNICODE. Почему?Не имя DLL должно быть в ANSI, а имя функции. Почему? Да потому что стандарт С разрешает использовать в именах функций (и других идентификаторах) только альфанумерик и _.
0
И да
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.
0
Да, имя функции.
0
Дак поправьте статью :)
И ещё, по поводу вот этого куска:
Почитаем стандарт (21.3.6/3)
То есть стандарт не требует, чтобы массив, на который указывает data(), заканчивался нулевым символом. В случае выше вместо data() правильнее использовать c_str(). А лучше вообще выкинуть функцию ANSI и пользоваться вышеупомянутой GetProcessAddressA().
И ещё, по поводу вот этого куска:
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().
0
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Программирование под Windows CE с помощью Embedded Visual C++, часть 1