Re: Стиль написания
От: igna Россия  
Дата: 20.09.06 20:06
Оценка: 16 (6) +4 :))) :))) :))) :))) :))) :))) :))) :))) :)
Здравствуйте, Аноним, Вы писали:

А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D


А исходный текст до применения обфускатора можно посмотреть?
Стиль написания
От: Аноним  
Дата: 20.09.06 16:23
Оценка: :))) :))) :))) :))
Здравствуйте мастера =)

Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.

Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D

1stapp.cpp

25.09.06 23:32: Перенесено из 'C/C++'
Re: Стиль написания
От: korzhik Россия  
Дата: 21.09.06 13:28
Оценка: 54 (6) +3
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте мастера =)


А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.


А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D


А>1stapp.cpp


не смог пройти равнодушно мимо такого безобразия!
Итак:
1. Чего мы там пишем в секцию кода? Хакер, ты наш, юный.
2. Отступы должны быть аккуратными
3. Не мешало бы разбить главную функцию, на несколько.
В твоём случае могло бы быть так:
  void create_and_mapping_file(const char*);
  bool check_PE_header();
  void make_some_shit_with_codesection();


4. у переменных должны быть более осмысленные имена

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

твой код:
HANDLE fhandle = CreateFile(Victim,GENERIC_READ+GENERIC_WRITE,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
if(fhandle==INVALID_HANDLE_VALUE) {
    MessageBox(NULL,mbFOpen,mbErrTitle,MB_ICONERROR);
    return 0;
};

DWORD fsize = GetFileSize(fhandle,NULL);
HANDLE maphandle = CreateFileMapping(fhandle,NULL,PAGE_READONLY,NULL,NULL,NULL);
DWORD mfile = (DWORD)MapViewOfFile(maphandle,FILE_MAP_READ,NULL,NULL,NULL);
DWORD vmem = (DWORD)VirtualAlloc(NULL,fsize+4096,MEM_COMMIT,PAGE_READWRITE);


как надо бы:
    HANDLE file = CreateFile(file_name, 
                             GENERIC_READ | GENERIC_WRITE, 
                             FILE_SHARE_READ, 
                             NULL,
                             OPEN_EXISTING,
                             FILE_ATTRIBUTE_NORMAL,
                             NULL);

    if (file == INVALID_HANDLE_VALUE) 
    {
        MessageBox(NULL, mbFOpen, mb_title, MB_ICONERROR);
        return 0;
    }

    DWORD  file_size = GetFileSize(file, NULL);
    if (file_size == INVALID_FILE_SIZE)
    {
        return 0;
    }

    HANDLE file_mapping = CreateFileMapping(file, NULL, PAGE_READONLY, NULL, NULL, NULL);
    if (file_mapping == 0)
    {
        CloseHandle(file);
        return 0;
    }
    void*  file_base = MapViewOfFile(file_mapping, FILE_MAP_READ, NULL, NULL, NULL);

    if ( file_base == 0 )
    {
        CloseHandle(file_mapping);
        CloseHandle(file);
        return 0;
    }
    void* vmem = VirtualAlloc(NULL, file_size + 4096, MEM_COMMIT, PAGE_READWRITE);

    if (vmem == 0)
    {
        UnmapViewOfFile(file_base);
        CloseHandle(file_mapping);
        CloseHandle(file);
        return 0;
    }


но это тоже плохо, так что читай про RAII

6. Чегой то за цикл?
while (d2!=0) {
    *(BYTE*)d0 = *(BYTE*)mfile;
    d0 = d0+1;
    mfile = mfile+1;
    d2 = d2-1;};


используй memcpy

7. дальше в коде идут непонятные циферки и буковки.
А вот чтобы они были понятными, надо вместо циферок использовать правильно именнованные константы. И ещё программист должен уметь грамотно подбирать инструмент.
Здесь ты анализируешь PE заголовок, так используй файл winnt.h (уже включён через windows.h)
там определены все структуры и константы для работы с PE
Например твой код:
WORD w0 = *(WORD*)vmem;
if(*(WORD*)(vmem)==0x5A4D) {
    DWORD PEstart = *(DWORD*)(vmem+60);
    if(*(DWORD*)(vmem+PEstart)==0x4550) {
        PEstart += (DWORD)(vmem);
        DWORD EP = *(DWORD*)(PEstart+40);
        DWORD sVA = *(DWORD*)(PEstart+0x104);
        if(sVA>EP) {MessageBox(NULL,mbEPAErr,mbErrTitle,MB_ICONERROR);}
        else {
            DWORD sVS = *(DWORD*)(PEstart+0x100);
            d0 = sVS+sVA;
            if(d0<=EP) {MessageBox(NULL,mbEPAErr,mbErrTitle,MB_ICONERROR);}
            else {


должен бытьпримерно таким:
    PIMAGE_DOS_HEADER dosHeader = (PIMAGE_DOS_HEADER)file_base;
    if (dosHeader->e_magic == IMAGE_DOS_SIGNATURE)
    {
        PIMAGE_NT_HEADERS pNTHeader; 
        pNTHeader = (PIMAGE_NT_HEADERS)(dosHeader + dosHeader->e_lfanew);

        if (pNTHeader->Signature == IMAGE_NT_SIGNATURE)
        {
            PIMAGE_SECTION_HEADER  pSectionHeader;
            pSectionHeader = (PIMAGE_SECTION_HEADER)(pNTHeader + sizeof(IMAGE_NT_HEADERS));
            DWORD EP = pNTHeader->OptionalHeader.BaseOfCode;
            DWORD sVA = pSectionHeader->Misc.VirtualSize;

            if (sVA > EP) 
            {
                MessageBox(NULL, mbEPAErr, mb_title, MB_ICONERROR);
            }
            else 
            {

и выделен в отдельную функцию, что то типа check_PE()
Re: Стиль написания
От: Аноним  
Дата: 21.09.06 07:37
Оценка: 7 (2) +4 -1
Превед, Санниасинчег!

А>Здравствуйте мастера =)


А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.


А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D


А>1stapp.cpp


гавнакод. нечитабельно, неоптимизировано, неоткомментировано.
есличо, код читается много чаще, чем пишется. подумай над этим.

NG
Re: Стиль написания
От: 41f  
Дата: 20.09.06 16:50
Оценка: 1 (1) +4
Здравствуйте, Аноним, Вы писали:

А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D


Ален И. Голуб "Веревка достаточной длины, чтобы выстрелить себе в ногу"
Даст ответы на многие вопросы.
Re: Стиль написания
От: Chorkov Россия  
Дата: 21.09.06 07:16
Оценка: 1 (1) -1 :))
Здравствуйте, Аноним, Вы писали:

А>1stapp.cpp


1)
Этот кусок кода, наверняка доступ к полям какой-то структуры, по адресу vmem+d2.
Лучьше преобразрвать указатель к указателю на эту структуру и использвать для доступа имена полей, а не вычисленные смещения.
*(BYTE*)(vmem+d2) = 0xB9;
*(DWORD*)(vmem+d2+1) = *(DWORD*)(PEstart+0x108);
*(BYTE*)(vmem+d2+5) = 0xB8;
*(DWORD*)(vmem+d2+6) = *(DWORD*)(PEstart+0x34)+*(DWORD*)(PEstart+0x104);
*(DWORD*)(vmem+d2+10) = 0x40113080;
*(WORD*)(vmem+d2+14) = 0xFAE2;
*(DWORD*)(vmem+d2+16) = 0x6AEC8B55;
*(BYTE*)(vmem+d2+20) = pv;
*(BYTE*)(vmem+d2+21) = 0x0E9;
*(DWORD*)(vmem+d2+22) = *(DWORD*)(PEstart+40)-(d0+0xA+11);

То-же относится и к указателю PEstart.

2) При сипользовании констант типа 0x746F7270, лучше дать им осмысленные имена.

3) Не верю, что процедуру нельзя развить хотябы на 2-3 отдельных.

4) Мне вообще не понятно, что этот код делает.
Re: Стиль написания
От: Shmakov Россия  
Дата: 21.09.06 13:11
Оценка: -4
Венгерка хде?
Re[3]: Стиль написания
От: korzhik Россия  
Дата: 21.09.06 15:41
Оценка: +2 :)
Здравствуйте, demi, Вы писали:


D>Здесь может быть не все так жестко, а так:


D>
D>HANDLE hfile = CreateFile(...);
D>if (INVALID_HANDLE_VALUE == hfile) //Кстати, уважаемый начинающий, догадаетесь, почему я hfile написал справа от знака сравнения.
D>  return 0;

вот кстати спорная привычка

D>HANDLE hMap = CreateFileMapping(...);
D>CloseHandle(hfile); //BEEF! <-- Здесь можно так сделать!!! Дело в том что Винда не отпустит хендл, пока он используется.

первый раз такое вижу, думаю возможны какие нибудь подводные камни

D>//Внутри все работает на счетчиках ссылок. Отпустили mapping и хендлы освободились автоматически Виндой.
D>UnmapViewOfFile(pMap);

возможно. я не в курсе

D>


D>А вот у меня дор сих пор детская проблема — люблю выравнивание в столбик... Например:


D>
D>//Бесит что держите семеро :)
D>#define WIDTH 800
D>#define HEIGHT 600
D>//А вот так нравится...
D>#define DIMX 800
D>#define DIMY 600
D>//И к какому врачу идти не знаю....
D>


такаяж фигня, люблю тоже всё выравнивать
Re: Стиль написания
От: Константин Л.  
Дата: 20.09.06 16:35
Оценка: :))
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте мастера =)


А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.


А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D


А>1stapp.cpp\


неужели ты понимаешь, что там делается после

if(*(WORD*)(vmem)==0x5A4D) {

Re[2]: Стиль написания
От: Roman Odaisky Украина  
Дата: 25.09.06 07:40
Оценка: +2
Здравствуйте, Аноним, Вы писали:

А>* Никогда не пользуйся табуляциями. Включи в редакторе текста замену табуляций на пробелы. У тех кто будет пользоваться другим редактором весь текст может оказаться нечитаемым.

Ну это уж чересчур. Если использовать табуляции только для отступов, всё будет OK.
int f()
{
\t  g();
\t  while(h())
\t  {
\t  \t  i();
\t  \t  j();
\t  \t  if(k())
\t  \t  {
\t  \t  \t  break;
\t  \t  }
\t  }
}

Проблемы будут при использовании табуляций для выравнивания всего, что только можно, вроде такого:
for(std::vector<std::string>::const_iterator i = dataStrings.begin(),
\t  \t  \t  \t  \t  \t  \t  \t  \t  \t  \t   e = dataStrings.end();
\t  i != e;
\t  ++i)

Здесь при другом размере табуляции будет полный бардак.
До последнего не верил в пирамиду Лебедева.
Re[3]: Стиль написания
От: kan Великобритания  
Дата: 25.09.06 08:21
Оценка: +2
Roman Odaisky wrote:

> Здесь при другом размере табуляции будет полный бардак.

Я обычно смешиваю пробелы с табуляцией:
if(_____a == "1")
{
\t do(1);
}
else if(a == "2")
{
\t do(2);
\t for(int i=0;
\t ________i<10;
\t ________++i)
\t {
\t \t blah();
\t }
}

Т.е. если отступ идёт просто на следующий уровень, то табуляция, если отступ "внутрь оператора", то пробелы, по
количеству букв в операторе. Тогда смена размера табуляции влияет только на то, на что надо и ничего не разъезжается.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: Стиль написания
От: CrystaX Россия https://crystax.me/
Дата: 21.09.06 11:56
Оценка: 1 (1)
Здравствуйте, asdfghjkl, Вы писали:

A>В данном случае она стоит после списка переменных этого класса. Здесь список пустой. Но он есть!


После закрывающей фигурной скобки '}' точка с запятой ';' не ставится. Никогда!


Просто надо быть точнее в формулировках.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Re[4]: Стиль написания
От: trophim Россия  
Дата: 24.09.06 20:45
Оценка: 1 (1)
Здравствуйте, korzhik, Вы писали:

D>>
D>>//Бесит что держите семеро :)
D>>#define WIDTH 800
D>>#define HEIGHT 600
D>>//А вот так нравится...
D>>#define DIMX 800
D>>#define DIMY 600
D>>//И к какому врачу идти не знаю....
D>>


K>такаяж фигня, люблю тоже всё выравнивать


Нас уже трое.
[EOF]
Let it be! — Давайте есть пчелу!
Re[3]: Стиль написания
От: Аноним  
Дата: 21.09.06 04:31
Оценка: +1
Здравствуйте, Аноним, Вы писали:

А>звеняйте, но обфускатором не пользовался, да и зачем использовать его для проэкта на cpp, это ведь не .net, который легко декомпилируется.


Я думаю для вас хотели донести простую мысль,
что программа в первую очередь пишется не для компьютреа,
а для человека, а ваш код совершенно не предназначен для прочтения.
Re[5]: Стиль написания
От: Vladimir D Belousov Россия  
Дата: 21.09.06 06:27
Оценка: +1
Здравствуйте, Crackjack, Вы писали:

C>Да вроде нормально, читается не плохо.Вроде все в одном стиле, ткст не разряженный, но дело вкуса.С математикой конечно сложно разобраться, но это в целом не проблема.Коментарии конечно нужны, но только такие что описываю картину в целом, а не то что делает конкретный оператор. Ворде таких:

C>// Находим корни таким-то методом

C>// Для опроса каждого устройства создаем отдельный поток


C>// устанавливаем параметры COM-порта в соответствие со

C>// спецификацией протокола обмена с APC's smart protocol
C>// http://eu1.networkupstools.org/protocols/apcsmart.html

C>// просто fuck!


Самые распространенные забыли:
// Durty HACK
// TODO
(забавно, у меня такие комментарии Kate особо подствечивает).

Без таких комментариев можно всё сломать, решив что это (то или иное) ошибка и её срочно надо исправить.
--
Спасибо
Re[3]: Стиль написания
От: asdfghjkl  
Дата: 21.09.06 11:48
Оценка: +1
A>>После закрывающей фигурной скобки '}' точка с запятой ';' не ставится. Никогда!

CX>
CX>class A {};
CX>


В данном случае она стоит после списка переменных этого класса. Здесь список пустой. Но он есть!
Невозможно чтобы у всех было всё, так как всех много, а всего мало...
Re[6]: Стиль написания
От: trophim Россия  
Дата: 24.09.06 20:45
Оценка: +1
Здравствуйте, Vladimir D Belousov, Вы писали:

VDB>Самые распространенные забыли:

VDB>// Durty HACK
VDB>// TODO
VDB>(забавно, у меня такие комментарии Kate особо подствечивает).

VDB>Без таких комментариев можно всё сломать, решив что это (то или иное) ошибка и её срочно надо исправить.


Да, есть такое дело. А комменты TODO, я думаю следует писать сразу же и писать то, чего собственно туду, а то уже через час забываешь в каком месте ты чего-то не дописал. В итоге очень интересно наблюдать как вызывается метод базового класса, который вроде уже реализован, нет никаких в нем TODO, а он, собака, как-то ведет себя подозрительно. Забыл записать TODO, вот и не было куска логики. Смотрел код. Долго думал.
[EOF]
Let it be! — Давайте есть пчелу!
Re[2]: Стиль написания
От: trophim Россия  
Дата: 24.09.06 20:45
Оценка: :)
Здравствуйте, <Аноним>, Вы писали:

А>гавнакод.


Хм, хороший термин. Возьму на вооружение. Не возражаете?
А то Фаулеровский "bad smells in code" не так точен.
[EOF]
Let it be! — Давайте есть пчелу!
Re: Стиль написания
От: Аноним  
Дата: 26.09.06 05:38
Оценка: :)
Здравствуйте, Аноним, Вы писали:

...твой папа тебе благодарен не будет...

Да и коллеги оставят тебя калекой! Ты через год сам побежишь покупать машину времени? когда будешь разбираться в своих сорцах, чтобы сломать самому себе руки и выбить зубы, за такой код!
Re: Стиль написания
От: Starik_Hottabych  
Дата: 20.09.06 16:30
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте мастера =)


А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.


А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D


А>1stapp.cpp


Я бы добавил чуточку коммента в код для разъяснения хода Выших мыслей
Re: Стиль написания
От: Аноним  
Дата: 20.09.06 16:47
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте мастера =)


А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.


А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D


А>1stapp.cpp


Санне, юзай константы, не все понимают наш маразм
Re[2]: Стиль написания
От: Аноним  
Дата: 20.09.06 22:00
Оценка:
Здравствуйте, igna, Вы писали:

I>Здравствуйте, Аноним, Вы писали:


I>А исходный текст до применения обфускатора можно посмотреть?


звеняйте, но обфускатором не пользовался, да и зачем использовать его для проэкта на cpp, это ведь не .net, который легко декомпилируется.
Re[4]: Стиль написания
От: Crackjack Россия  
Дата: 21.09.06 05:58
Оценка:
Да вроде нормально, читается не плохо.Вроде все в одном стиле, ткст не разряженный, но дело вкуса.С математикой конечно сложно разобраться, но это в целом не проблема.Коментарии конечно нужны, но только такие что описываю картину в целом, а не то что делает конкретный оператор. Ворде таких:
// Находим корни таким-то методом

// Для опроса каждого устройства создаем отдельный поток

// устанавливаем параметры COM-порта в соответствие со
// спецификацией протокола обмена с APC's smart protocol
// http://eu1.networkupstools.org/protocols/apcsmart.html

// просто fuck!
Re: Стиль написания
От: Alex34 Израиль  
Дата: 21.09.06 07:44
Оценка:
Здравствуйте, Аноним, Вы писали:

Может моё мнение субъективно , но здесь уже было сказано , что код пишеться для человека , а не для машины.

А ты сам попробуй 3 вещи :

1. Просмотри свой код через месяц — другой . Сможешь ли еще понять , что код делает ?

2. Попробуй внести в него изменения или попроси друга . Насколько это будет легко тебе ( а особенно ему ) это сделать ?

3. Почитай "Рефакторинг " Фаулера.

Если после всего этого , ты решишь , что ничего менять не надо — то значить стиль у тебя хороший.
Re[2]: Стиль написания
От: Crackjack Россия  
Дата: 21.09.06 07:52
Оценка:
Все гуд, мне этот код нравится все больше и больше.Вот только документации под рукой нет, а то бы можно было разобраться о чем речь.Коменты походу будут только мешаться.Я так понимаю, что здесь каждое имя переменной несет смысловую нагрузку.
Re: Стиль написания
От: rg45 СССР  
Дата: 21.09.06 07:59
Оценка:
" Аноним " <0@users.rsdn.ru> wrote in message news:2119453@news.rsdn.ru...
> Здравствуйте мастера =)
>
> Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.
>
> Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D
>
> 1stapp.cpp

Я думаю, тебе интересно будет прочесть книжку Саттера и Александреску "Стандарты программирования на C++. 101 правило и рекомендация". Здесь под словом стандарт подразумевается не стандарт языка C++, а стандарты стиля кодирования.
Posted via RSDN NNTP Server 2.0
--
Справедливость выше закона. А человечность выше справедливости.
Re: Стиль написания
От: elcste  
Дата: 21.09.06 08:29
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять.


После просмотра кода мне показалось, что Вам еще рано задумываться о вопросах стиля. Вообще же (когда со временем этот вопрос станет актуальным) есть довольно очевидный способ выработки собственного стиля: попробуйте описать Ваш стиль кодирования. В такой форме, чтобы, руководствуясь этим описанием, ему могли следовать другие люди. При этом будьте готовы приводить аргументы в пользу выбранного Вами варианта из нескольких возможных. Короче говоря, попытайтесь объяснить себе, почему Вы делаете именно так, а не иначе. В процессе и сложится стиль.

P.S. В реальной жизни кодера, написавшего такое, я заставил бы переделывать всё, начиная с использования табуляций.
Re: Стиль написания
От: asdfghjkl  
Дата: 21.09.06 11:22
Оценка:
После закрывающей фигурной скобки '}' точка с запятой ';' не ставится. Никогда!
Невозможно чтобы у всех было всё, так как всех много, а всего мало...
Re[2]: Стиль написания
От: CrystaX Россия https://crystax.me/
Дата: 21.09.06 11:39
Оценка:
Здравствуйте, asdfghjkl, Вы писали:

A>После закрывающей фигурной скобки '}' точка с запятой ';' не ставится. Никогда!


class A {};
... << RSDN@Home 1.2.0 alpha rev. 655>>
Re[2]: Стиль написания
От: demi США  
Дата: 21.09.06 14:48
Оценка:
Здравствуйте, korzhik, Вы писали:
K>как надо бы:
K>
K>    HANDLE file = CreateFile(file_name, 
K>    if (file == INVALID_HANDLE_VALUE) 
K>        return 0;
K>    HANDLE file_mapping = CreateFileMapping(file, NULL, PAGE_READONLY, NULL, NULL, NULL);
K>    if (file_mapping == 0)
K>    {
K>        CloseHandle(file);
K>        return 0;
K>    }
K>    void*  file_base = MapViewOfFile(file_mapping, FILE_MAP_READ, NULL, NULL, NULL);
K>    if ( file_base == 0 )
K>    {
K>        CloseHandle(file_mapping);
K>        CloseHandle(file);
K>        return 0;
K>    }
K>    void* vmem = VirtualAlloc(NULL, file_size + 4096, MEM_COMMIT, PAGE_READWRITE);
K>    if (vmem == 0)
K>    {
K>        UnmapViewOfFile(file_base);
K>        CloseHandle(file_mapping);
K>        CloseHandle(file);
K>        return 0;
K>    }
K>


Здесь может быть не все так жестко, а так:

HANDLE hfile = CreateFile(...);
if (INVALID_HANDLE_VALUE == hfile) //Кстати, уважаемый начинающий, догадаетесь, почему я hfile написал справа от знака сравнения.
  return 0;

HANDLE hMap = CreateFileMapping(...);
CloseHandle(hfile); //BEEF! <-- Здесь можно так сделать!!! Дело в том что Винда не отпустит хендл, пока он используется.

if (!hMap)
  return 0;

PVOID pMap = MapViewOfFile(...);
CloseHandle(hMap); //BEEF! <-- Здесь можно так сделать!!! Дело в том что Винда не отпустит хендл, пока он используется.

if (!pMap)
  return 0;

//... наши великие дела ...

//Внутри все работает на счетчиках ссылок. Отпустили mapping и хендлы освободились автоматически Виндой.
UnmapViewOfFile(pMap);


А вот у меня дор сих пор детская проблема — люблю выравнивание в столбик... Например:

//Бесит что держите семеро :)
#define WIDTH 800
#define HEIGHT 600
//А вот так нравится...
#define DIMX 800
#define DIMY 600
//И к какому врачу идти не знаю....
Не стыдно попасть в дерьмо, стыдно в нём остаться!
Re[3]: Стиль написания
От: Roman Odaisky Украина  
Дата: 21.09.06 16:51
Оценка:
Здравствуйте, demi, Вы писали:

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

Я тоже когда-то так писал, потом перестал. Компилятор всё равно предупредит (3 >= /W? Тогда мы идем к вам!), а читаемость всё же падает. Читаем-то мы слева направо.
if(FAIL == {здесь какое-то длинное выражение}) // если что? исключительная ситуация?
if(FAIL == promptUser("Format drive C:?", RETRY | IGNORE | FAIL)) // а-а, это кнопка!

if(promptUser({здесь строки всякие, константы}... // ага, задаем какой-то вопрос, и в зависимости от реакции делаем то или иное
if(promptUser("Format drive C:?", RETRY | IGNORE | FAIL) == FAIL) // понятно

Да и в случае сравнений «<»/«>»/... нарушается или концепция, или здравый смысл.
if(SOME_VALUE == f()) // это еще можно понять...

if(SOME_THRESHOLD <= readItTenTimesToUnderstand()) // ??!
if(thisIsJustABitSimpler() >= SOME_THRESHOLD) // а это расходится со стратегией для ==.
До последнего не верил в пирамиду Лебедева.
Re[4]: Стиль написания
От: demi США  
Дата: 22.09.06 09:00
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, demi, Вы писали:


RO>
//Кстати, уважаемый начинающий, догадаетесь, почему я hfile написал справа от знака сравнения.

RO>Я тоже когда-то так писал, потом перестал. Компилятор всё равно предупредит (3 >= /W? Тогда мы идем к вам!), а читаемость всё же падает. Читаем-то мы слева направо.

Согласен. Другое дело, что хотелось бы, что бы многоуважаемый начинающий знал об этом. Я так тож редко делаю и пишу hr == E_FAIL а не наоборот, (а вообще пишу FAILED(hr)). Это просто, к слову.
Не стыдно попасть в дерьмо, стыдно в нём остаться!
Re[4]: Стиль написания
От: demi США  
Дата: 22.09.06 09:03
Оценка:
Здравствуйте, korzhik, Вы писали:

D>>
D>>HANDLE hMap = CreateFileMapping(...);
D>>CloseHandle(hfile); //BEEF! <-- Здесь можно так сделать!!! Дело в том что Винда не отпустит хендл, пока он используется.

K>первый раз такое вижу, думаю возможны какие нибудь подводные камни

D>>//Внутри все работает на счетчиках ссылок. Отпустили mapping и хендлы освободились автоматически Виндой.
D>>UnmapViewOfFile(pMap);

K>возможно. я не в курсе

D>>


Этот код я впервые с пояснениями увидел не где-нибудь, а в boost. Так что посмотрите, там сказано с оговоркой 'seems to be'. Но если такая уважаемая либа делает так, думаю, это не так плохо (наверно кто-то из создателей знает что в потрохах Windows).
Не стыдно попасть в дерьмо, стыдно в нём остаться!
Re: Стиль написания
От: Ubivetz Украина  
Дата: 22.09.06 09:40
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте мастера =)


А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.


А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D


А>1stapp.cpp

Лично я бы порекомендовал:
1) использовать константы с осмысленными именами, а не числовые значения,
2) комментировать назначение блоков кода,
3) отделять блоки кода, несущие определённую смысловую нагрузку, пустыми строками,
4) всё же располагать операторные скобки друг под другом (несколько облегчает чтение),
5) (на будущее) не сильно увлекаться шаблонами, да и вообще, поменьше извращаться (иначе коментировать извраты)
6) писать код в расчёте скорее на новичка или программиста средней категории, нежели на гуру.
Эх, люблю выпить и переспать с кем нибудь!
Но чаще выходит перепить с кем — нибудь и выспаться...
Re[3]: Стиль написания
От: asdfghjkl  
Дата: 22.09.06 10:58
Оценка:
D>
D>HANDLE hfile = CreateFile(...);
D>if (INVALID_HANDLE_VALUE == hfile) //Кстати, уважаемый начинающий, догадаетесь, почему я hfile написал справа от знака сравнения.
D>


Ну ладно мы мучаеся, читая наизнанку, но молодежи-то зачем это грузить?
Невозможно чтобы у всех было всё, так как всех много, а всего мало...
Re[4]: Стиль написания
От: demi США  
Дата: 22.09.06 14:17
Оценка:
Здравствуйте, asdfghjkl, Вы писали:

D>>
D>>HANDLE hfile = CreateFile(...);
D>>if (INVALID_HANDLE_VALUE == hfile) //Кстати, уважаемый начинающий, догадаетесь, почему я hfile написал справа от знака сравнения.
D>>


A>Ну ладно мы мучаеся, читая наизнанку, но молодежи-то зачем это грузить?


Roman Odaisky заметил неудобочитаемость данной конструкции. Я не отрицаю.

Кстати, а никто не имеет ничего против названия типа _name данных в классе? (в POD и public не практикую). Вроде по стандарту C++ имена с двумя подчеркиваниями подряд в любом месте слова забронированы, _+Заглваная буква, _+любой символ ТОЛЬКО для глобальных имен. Получается _name в классе безвреден. Лично мне m_ не нравится сильно. Как и венгерка!!! Эта вообще ахтунг! Венгерку ф топку!!!

class A
{
   int _num;
   int _totalSize;
   //so on...
};
Не стыдно попасть в дерьмо, стыдно в нём остаться!
Re[5]: Стиль написания
От: kan Великобритания  
Дата: 22.09.06 15:05
Оценка:
demi wrote:

> Кстати, а никто не имеет ничего против названия типа _name данных в

> классе? (в POD и public не практикую). Вроде по стандарту C++ имена с
> двумя подчеркиваниями подряд в любом месте слова забронированы,
> _+Заглваная буква, _+любой символ ТОЛЬКО для глобальных имен. Получается
> _name в классе безвреден. Лично мне m_ не нравится сильно. Как и
> венгерка!!! Эта вообще ахтунг! Венгерку ф топку!!!
Да можно и "m_", в бусте иногда попадается "fieldName_", а вариант "_fieldName" я видел только в языках не
обеспечивающих security для обозначения приватных данных или для нестандартных расширений.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Стиль написания
От: sugarde  
Дата: 22.09.06 15:16
Оценка:
Здравствуйте, Аноним, Вы писали:

Прсотите, если не секрет, какой декомпилятор выплюнул этот код?
В жизни кaждoгo челoвекa бывaют приятные мoменты, кoгдa oн чувствует себя пoлным идиoтoм. Приятнoсть этих мoментoв в пoстижении истины.
Re[5]: Стиль написания
От: Roman Odaisky Украина  
Дата: 22.09.06 21:40
Оценка:
Здравствуйте, demi, Вы писали:

D>Кстати, а никто не имеет ничего против названия типа _name данных в классе? (в POD и public не практикую). Вроде по стандарту C++ имена с двумя подчеркиваниями подряд в любом месте слова забронированы, _+Заглваная буква, _+любой символ ТОЛЬКО для глобальных имен. Получается _name в классе безвреден. Лично мне m_ не нравится сильно. Как и венгерка!!! Эта вообще ахтунг! Венгерку ф топку!!!


D>
D>class A
D>{
D>   int _num;
D>   int _totalSize;
D>   //so on...
D>};
D>

Можно, разумеется. А по поводу HN зря. Читал статью Джоэла?

По поводу именования — я обычно делаю так:
class X
{
. . .
private:
    int i_;
    std::deque<std::string> strings_;
    Y allTheMembersAreCalledThisWay_;

public:
    void regularMemberFunction();
    void _somethingQuestionable(); // «handle with care!»
};

Т. о., члены именуются с подчеркиванием в конце, методы — без оного, дебажно-грабельные классы начинают свои имена с подчеркивания, что призвано привлекать внимание. Вот например:
template <class ClassBeingTested>
class InvariantCheckHelper: public InvariantCheckHelperBase
{
public:
    InvariantCheckHelper(ClassBeingTested const& obj): obj_(obj)
    {
    }

    ~InvariantCheckHelper()
    {
        obj_._checkInvariants();
    }

private:
    ClassBeingTested const& obj_;
};

template <class ClassBeingTested>
InvariantCheckHelper<ClassBeingTested> makeInvariantCheckHelper(ClassBeingTested const& obj)
{
    return InvariantCheckHelper<ClassBeingTested>(obj);
}

#define CHECK_INVARIANTS_NOW_AND_ON_EXIT() \
    ; \
    this->_checkInvariants(); \
    InvariantCheckHelperBase const& invariantCheckHelper = makeInvariantCheckHelper(*this); \
    (void)invariantCheckHelper;

использование, полагаю, очевидно:
class X
{
    void _checkInvariants() const
    {
        assert(abc);
        assert(xyz);
    }

    void whatever()
    {
        CHECK_INVARIANTS_NOW_AND_ON_EXIT();
        doSomething();
    }
};
До последнего не верил в пирамиду Лебедева.
Re[6]: Стиль написания
От: demi США  
Дата: 23.09.06 07:33
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:
RO>А по поводу HN зря. Читал статью Джоэла?
Почитаю внимательно, когда освобожусь.

Вот мои мысли против HN.

Мне не нравиться удлинение имен. Во вторых, усложенение рефакторинга. DWORD dwSize; -> WORD wSize; И все вхождения 'dwSize' надо менять. Зачастую этим пренебрегают, и имена не соответствуют типу, что еще хуже. Так можно обозначить ограниченный набор типов (не user-defined). Это было хорошим решением для asm-кода и местах сопряжения asm-C, где никаких проверок типов нет и отсутствуют "разумные" преобразования.

;Давно не практиковался а асме, не пинайте сильно. Но суть ясна.
dw  word_size_var; ;2 bytes
dd  dword_var;     ;4 bytes

;...

;Забыли что переменная 2 байта, но компилятор съест - возьмет лишних 2 байта.
mov eax, DWORD PTR word_size_var;


Факт ведь, что MS отказалась от HN. К тому же, мы живем не в мире Borland Turbo C 3.1 а в мире VisualStudio + VisualAssist, и для того, чтобы узнать тип переменной, достаточно просто навести на имя мышкой. А если стоит ассист, то вообще ничего делать не надо — он когда редактируешь выводит в своей строке определение символа под курсором редактора(для переменной тип). + ворнинги и все такое Венгерка излишня и утомительна.

А вот различить глобальная, стековая или член класса данная перменная, сложнее и код читается лучше, если видно, где функция обращается к членам класса, stack frame и тд. Так что я за _name (beef!), m_name, name_ в классах, g_name, ::name для глобальных переменных. Остальные — как угодно, но БЕЗ венгерки.
Не стыдно попасть в дерьмо, стыдно в нём остаться!
Re[6]: Стиль написания
От: demi США  
Дата: 23.09.06 07:37
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:
А вообще мой стиль отсюда — здесь. C# naming conventions, но для C++ по мойу очень удачно подходит.
Не стыдно попасть в дерьмо, стыдно в нём остаться!
Re: Стиль написания
От: strcpy Россия  
Дата: 23.09.06 08:25
Оценка:
А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.
Для начала определись с правилами кодирования, в частоности, выбери, что ты используешь — пробелы или табуляции.
Удвой число ошибок, если не получается добиться цели.
Re: Стиль написания
От: Анатолий Широков СССР  
Дата: 23.09.06 09:27
Оценка:
А>1stapp.cpp

Качественный фейк.
Re[2]: Стиль написания
От: johny5 Новая Зеландия
Дата: 25.09.06 01:10
Оценка:
C>1)
C>Этот кусок кода, наверняка доступ к полям какой-то структуры, по адресу vmem+d2.
C>Лучьше преобразрвать указатель к указателю на эту структуру и использвать для доступа имена полей, а не вычисленные смещения.
C>
C>*(BYTE*)(vmem+d2) = 0xB9;
C>*(DWORD*)(vmem+d2+1) = *(DWORD*)(PEstart+0x108);
C>*(BYTE*)(vmem+d2+5) = 0xB8;
C>*(DWORD*)(vmem+d2+6) = *(DWORD*)(PEstart+0x34)+*(DWORD*)(PEstart+0x104);
C>



Нельзя, если не хотите поиметь проблем от выравнивания структур.
Команды, типа #pragma pack (msvc) и __attribute что то там (не помню)(gcc) во первых между собой синтаксически не совместимы (не портабельны),
а во вторых не дают гарантии той плотной упаковки, что вы добиваетесь.
Re: Стиль написания
От: Аноним  
Дата: 25.09.06 06:57
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте мастера =)


А>Я начинающий кодер на cpp, и хочу оценить свой стиль написания.. возможно мне нужно его поменять. Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.


А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D


А>1stapp.cpp


* пользуйся втягиванием в теле функции
* аргументы функций и макросов отделяй пробелами. Так больше воздуха и легче читать.
* Никогда не пользуйся табуляциями. Включи в редакторе текста замену табуляций на пробелы. У тех кто будет пользоваться другим редактором весь текст может оказаться нечитаемым.
* Используй выровненный к колонки текст, например по символу =. Ты привел в комменте определение OPENFILENAME выровненное в голонки. Его легко читать, не так ли? При этом выше его стоит несколько строк, их читать сложнее.
* если строка константная то и определяй ее как константную, например
вместо char mbErrTitle[] = "Error"; используй
const char* mbErrTitle = "Error";
* если массив char используешь как сишную строку с терминированием нулем то используй указатель а не декларацию массива.
* магические константы комментируй
* операции которые нельзя понять сразу тоже комментируй, например
d0 = (*(DWORD*)(PEstart+0x54))-(nos*0x28+0xF8+PEstart-(DWORD)vmem);
Принцип очень простой. Берешь текст, любую строку, и считаешь что ты ее видишь первый раз в жизни, и в ней две ошибки. Их нужно найти и исправить.
* пиши код так чтобы можно было 1) его понять и 2) его отладить спустя два года. Например
*(BYTE*)(vmem+d2) = 0xB9;
*(DWORD*)(vmem+d2+1) = *(DWORD*)(PEstart+0x108);
*(BYTE*)(vmem+d2+5) = 0xB8;
*(DWORD*)(vmem+d2+6) = *(DWORD*)(PEstart+0x34)+*(DWORD*)(PEstart+0x104);
*(DWORD*)(vmem+d2+10) = 0x40113080;
*(WORD*)(vmem+d2+14) = 0xFAE2;
Определи структуру, поставь указатель на эту структуру на vmem+d2 и в дебаггере будешь видеть что там.
* пиши по одному выполняемому выражению на строку, чтобы в дебаггере тебе же жилось лучше, например
if(d1>0) {d1 = (*(DWORD*)(d0-0x20))+0x1000&0xFFFFF000;}
else {d1 = *(DWORD*)(d0-0x20);};
Здесь дебаггер не сможет отличить шаг проверки от шага выполнения выражения.
* пользуйся едиными правилами применения фигурных скобок, например
else{d2 = d2+1;};
очевидно выбивается из общего стиля.
* OutputDebugString(dsNoImport) должно быть только в отладочной версии, изучи макросы условной компиляции и пользуйся ими.
* Не посылай так далеко как на метку lbl, выполни более читабельно.
* файлам давай осмысленные имена, не привязанные к времени, например без new, old, first и прочие. Что сегодня first — завтра совсем не first.

Хотя ты хотел узнать кто что об этом думает. Лично я думаю что шансы у тебя есть.
Re[7]: Стиль написания
От: Roman Odaisky Украина  
Дата: 25.09.06 07:30
Оценка:
Здравствуйте, demi, Вы писали:

RO>>А по поводу HN зря. Читал статью Джоэла?

D>Почитаю внимательно, когда освобожусь.

Почитай, много интересного узнаешь.

D>Вот мои мысли против HN.

D>DWORD dwSize; -> WORD wSize;
Это Systems Hungarian, с современными IDE идея совершенно бесполезная. А Simonyi придумал совсем другое, Apps Hungarian. Только когда он поведал всей Microsoft о своей разработке, те ничего не поняли и стали писать lpsz.

Пример:
string sAddSlashes(string usStr); // «"» -> «\"» и т. п.

usUserName = httpGet("name"); // unsafe
sUserName = sAddSlashes(usUserName); // safe

sqlQuery("INSERT ... " + sUserName + "...");

sqlQuery("INSERT ... " + usUserName + "..."); // Hey! What do you think you're doing?

sWhatever = usWhatever; // Stop! Danger!

И т. п. Если rIndex — это номер строки в листе Excel, а cIndex — столбца, то «rIndex = cIndex», по крайней мере, бросается в глаза.
До последнего не верил в пирамиду Лебедева.
Re[8]: Стиль написания
От: kan Великобритания  
Дата: 25.09.06 08:13
Оценка:
Roman Odaisky wrote:

> string sAddSlashes(string usStr); // «"» -> «\"» и т. п.

>
> *us*UserName = httpGet("name"); // unsafe
> *s*UserName = sAddSlashes(usUserName); // safe
>
> sqlQuery("INSERT ... " + *s*UserName + "...");
>
> sqlQuery("INSERT ... " + *us*UserName + "..."); // Hey! What do you think you're doing?
А такое сразу в морг. placeholders на это дело есть.

> sWhatever = usWhatever; // Stop! Danger!

Зачем пытаться впихнуть смысл в 2 буквы?

> И т. п. Если rIndex — это номер строки в листе Excel, а cIndex —

> столбца, то «rIndex = cIndex», по крайней мере, бросается в глаза.
Уж лучше rowIndex, colIndex. На чём экономим?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: Стиль написания
От: Roman Odaisky Украина  
Дата: 25.09.06 08:23
Оценка:
Здравствуйте, kan, Вы писали:

>> Здесь при другом размере табуляции будет полный бардак.


kan>Я обычно смешиваю пробелы с табуляцией:


kan>Т.е. если отступ идёт просто на следующий уровень, то табуляция, если отступ "внутрь оператора", то пробелы, по

kan>количеству букв в операторе. Тогда смена размера табуляции влияет только на то, на что надо и ничего не разъезжается.

Так а я о чем.
До последнего не верил в пирамиду Лебедева.
Re[9]: Стиль написания
От: Roman Odaisky Украина  
Дата: 25.09.06 08:28
Оценка:
Здравствуйте, kan, Вы писали:

>> sqlQuery("INSERT ... " + *us*UserName + "..."); // Hey! What do you think you're doing?

kan>А такое сразу в морг. placeholders на это дело есть.
Ну это уже другой вопрос. Сначала придумали проблему (plainтекстовый язык, который приходится генерить на ходу), а потом решают ее.

>> sWhatever = usWhatever; // Stop! Danger!

kan>Зачем пытаться впихнуть смысл в 2 буквы?
Ответ на вопрос «зачем» в названии статьи.

>> И т. п. Если rIndex — это номер строки в листе Excel, а cIndex —

>> столбца, то «rIndex = cIndex», по крайней мере, бросается в глаза.
kan>Уж лучше rowIndex, colIndex. На чём экономим?
Может, и лучше. Но оба варианта явно лучше, чем index1/index2.
До последнего не верил в пирамиду Лебедева.
Re[3]: Стиль написания
От: Аноним  
Дата: 25.09.06 10:13
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Аноним, Вы писали:


А>>* Никогда не пользуйся табуляциями. Включи в редакторе текста замену табуляций на пробелы. У тех кто будет пользоваться другим редактором весь текст может оказаться нечитаемым.

RO>Ну это уж чересчур. Если использовать табуляции только для отступов, всё будет OK.
RO>Проблемы будут при использовании табуляций для выравнивания всего, что только можно, вроде такого:
RO>
RO>for(std::vector<std::string>::const_iterator i = dataStrings.begin(),
RO>\t  \t  \t  \t  \t  \t  \t  \t  \t  \t  \t   e = dataStrings.end();
RO>\t  i != e;
RO>\t  ++i)
RO>

RO>Здесь при другом размере табуляции будет полный бардак.

Не буду заниматься предсказаниями когда что произойдет а когда нет, в каком редакторе, в каком вьюере, какой версии и прочее. Я высказал свою точку зрения, выработавшуюся за 10 лет работы. Основано на статистике работы с многими исходниками на самых разных языках и с разными стилями кодирования. Я учитывал распространенные, малораспространенные редакторы, различные вьюеры, и их подсистемы печати. Если придерживаться правила "табуляция — табу" то проблемы не исчезают конечно но по меньшей мере минимизируются. Если человек хотел совет "как лучше", то это правило подходит, на мой взгляд.
Re[3]: Стиль написания
От: Аноним  
Дата: 25.09.06 12:26
Оценка:
Здравствуйте, johny5, Вы писали:


C>>1)

C>>Этот кусок кода, наверняка доступ к полям какой-то структуры, по адресу vmem+d2.
C>>Лучьше преобразрвать указатель к указателю на эту структуру и использвать для доступа имена полей, а не вычисленные смещения.
C>>
C>>*(BYTE*)(vmem+d2) = 0xB9;
C>>*(DWORD*)(vmem+d2+1) = *(DWORD*)(PEstart+0x108);
C>>*(BYTE*)(vmem+d2+5) = 0xB8;
C>>*(DWORD*)(vmem+d2+6) = *(DWORD*)(PEstart+0x34)+*(DWORD*)(PEstart+0x104);
C>>



J>Нельзя, если не хотите поиметь проблем от выравнивания структур.

J>Команды, типа #pragma pack (msvc) и __attribute что то там (не помню)(gcc) во первых между собой синтаксически не совместимы (не портабельны),
J>а во вторых не дают гарантии той плотной упаковки, что вы добиваетесь.

Нужно преобразовать к структуре. Выравнивание структур — это еще не самая жуткая фигня. Есть платформы, где переменные целых типов должны располагаться в памяти с адресов, кратных 4-м. На таких платформах, код

C>>*(DWORD*)(vmem+d2+1) = *(DWORD*)(PEstart+0x108);


работать будет не всегда.
Re[4]: Стиль написания
От: johny5 Новая Зеландия
Дата: 25.09.06 17:17
Оценка:
J>>Нельзя, если не хотите поиметь проблем от выравнивания структур.
J>>Команды, типа #pragma pack (msvc) и __attribute что то там (не помню)(gcc) во первых между собой синтаксически не совместимы (не портабельны),
J>>а во вторых не дают гарантии той плотной упаковки, что вы добиваетесь.

А>Нужно преобразовать к структуре. Выравнивание структур — это еще не самая жуткая фигня. Есть платформы, где переменные целых типов должны располагаться в памяти с адресов, кратных 4-м. На таких платформах, код


C>>>*(DWORD*)(vmem+d2+1) = *(DWORD*)(PEstart+0x108);


А>работать будет не всегда.


На таких платформах и ваш и мой вариант приведёт к краху, потому что сгенерённый код будет одинаков. Не думаю что компилятор генерит всегда неэффективный код считывания по байту только из предположения что смещение, переданное вами может быть не кратным 4м.
Всё таки это должно быть на совести программиста.
Re[10]: Стиль написания
От: kan Великобритания  
Дата: 26.09.06 08:05
Оценка:
Roman Odaisky wrote:

>> > sqlQuery("INSERT ... " + *us*UserName + "..."); // Hey! What do you

> think you're doing?
> kan>А такое сразу в морг. placeholders на это дело есть.
> Ну это уже другой вопрос. Сначала придумали проблему (plainтекстовый
> язык, который приходится генерить на ходу), а потом решают ее.
Да нет, это от непонимания того, что программа и данные — вещи разделяемые. Если программу можно генерить, это вовсе не
означает, что туда надо пихать все данные.

>> > sWhatever = usWhatever; // Stop! Danger!

> kan>Зачем пытаться впихнуть смысл в 2 буквы?
> Ответ на вопрос «зачем» в названии статьи.
Я не понял. Автор просто говорит, давайте Unsafe String обозначать как us, а Safe как s. И всё. А без этого соглашения
никто код не поймёт — читабельности это добавляет мало. В общем, ничем не лучше, чем lpsz. Лично я бы писал
userNameUnescaped или даже userNameUnsafeString, unsafeStrUserName, но двухбуквенные аббревиатуры — упаси боже. Пока я
не прочёл в статье что эти буквы значат — я не понял что это значит. Ещё на несколько широко известных и легко
понимаемых сокращений типа col, str, func, ret, bool, pwd, id и т.д. я согласен, но не более.
А вообще говоря, все эти фокусы — от неправильной архитектуры — котлеты и мухи должны быть отдельно. Если у тебя SQL —
есть байндеры, и никогда не надо сувать ничего в текст запроса, если это HTML — есть куча генераторов, скажем XML->XSLT
или куча разных web-движков, которые лучше знают что и где и как кодировать.

>> > И т. п. Если rIndex — это номер строки в листе Excel, а cIndex —

>> > столбца, то «rIndex = cIndex», по крайней мере, бросается в глаза.
> kan>Уж лучше rowIndex, colIndex. На чём экономим?
> Может, и лучше. Но оба варианта явно лучше, чем index1/index2.
Никто не спорит, но всё-таки row лучше чем r, а col лушче чем c
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Стиль написания
От: Аноним  
Дата: 26.09.06 13:29
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Думаю ни для кого не секрет что удача в кодинге напрямую зависит от стиля.


Удача в кодинге — это, сильно !!!
Пожелай мне удачи в кодинге, пожелай
Re: Стиль написания
От: Skleroz Россия  
Дата: 26.09.06 13:56
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Собственно, вот здесь находится кусок моего кода, хотелось бы услышать, что вы об этом думаете :D


А ты сам через пол-года его открой и услышишь :D
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Стиль написания
От: Dair Россия  
Дата: 26.09.06 14:52
Оценка:
S>Венгерка хде?

Осталась в бейсике.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.