Кресты / Говнокод #6384 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64
#include <windows.h>





struct io
{
    io()
    {
        SetConsoleTitle(__FUNCSIG__);
    }
    ~io()
    {
        DebugBreak();
    }
} io_obj;




int main()
{
}

typedef void(fn_t)();

#pragma comment(linker, "/merge:.CRT=.rdata")

#pragma data_seg(".CRT$XCA")
extern "C" fn_t * start[] = {0};
#pragma data_seg(".CRT$XCZ")
extern "C" fn_t * finish[] = {0};
#pragma data_seg()

void call_dtors();

extern "C" void _initterm()
{
    fn_t **p = start, **q = finish;
    while (p < q)
    {
        if (*p)
            (*p)();
        ++p;
    }
    main();
    call_dtors();
}

fn_t * dtors[999];
int c_dtors;

void call_dtors()
{
    while (c_dtors--)
        dtors[c_dtors]();
}

extern "C" int atexit(void (__cdecl *func )( void ))
{
    dtors[c_dtors++] = func;
    return !"unspecified";
}

если клепаем что то без CRT и хотим чтоб вызывались
конструкторы деструкторы статических объектов и хотим свое то
вот реализация для тех кто этого еще неделал
https://wasm.ru/forum/viewtopic.php?pid=428250#p428250

Запостил: rat4 rat4, (Updated )

Комментарии (26) RSS

  • Конструктор и деструктор стракта - это так Ъ...
    Ответить
    • Это полезно в некоторых случаях, таже инициализация. Я, например, при решении задач на однонаправленные списки с заглавным звеном, в которых удаление списка требовалось всего сразу, а не отдельных его элементов, делал след образом:
      struct node{
      //свойства
      ...
      //указатель на след звено
      node *pNext;
      node(){pNext=NULL;//и инициализация других свойств};
      ~node(){delete pNext;} //цепная реакция
      }

      (*(node *pHead=new(node)).pNext=new(node);
      delete pHead;

      Если посмотреть на деструктор, то можно понять принцип. Пример туповат, но все же, надеюсь, ответил на вопрос.
      Да и вообще странный вопрос.
      Ответить
    • если знать, в чем разница между структурой и классом, то наличие конструктора/деструктора для структуры не вызывает никаких негативных имоций)
      Ответить
      • > если знать, в чем разница между структурой и классом

        Кстати, в чём?
        Ответить
        • ах ты бедненький необразованный паскалист! срочно в школу) разница в определении области видимости членов по умолчанию... есть еще особенности нахождения указателя на vtable в памяти...
          Ответить
            • ну насколько я помню (если канеш не путаю ничего), в структуре указатель на таблицу виртуальных функций всегда в конце данных, а в классе - не всегда... то есть над структурой можно реализовывать всякий говнокод, оперируя со смещением члена структуры относительно "базового адреса" структуры...
              Ответить
              • Какой-нибудь компилятор, возможно, и захочет зачем-то реализовать подобный гемморой, но что-то мало верится. В практически всех ныне живущих компиляторах указатель на VMT всегда сидит в самом начале, независимо от того, как объявлен класс - со 'struct' или с 'class'.
                Ответить
          • "Области видимости"? Можно поподоробнее, про "область видимости". Я вот, например, прекрасно знаю различия между class и struct, но как к этому прикрутить "область видимости" в упор не вижу.

            Да, и какие это такие особенности с нахождением "указателя на vtable"?
            Ответить
              • И? Где здесь "области видимости"? На всякий случай напомню, что и видимость и область видимости - строго определенные в языке термины (английский аналоги - visibility, scope). А 'public' и 'private' - спецификаторы доступа, которые к видимости никакого отношения не имеют вообще. Более того, одним из ключевых свойств разграничения доступа в С++ является то, что на видимость они никак не влияют (что зачастую удивляет новичков, ожидающих, что private члены будут невидимы снаружи). Private члены класса видимы снаружи абсолютно точно так же, как и public члены класса. А вот доступа к private членам извне нет. Не надо путать видимость с доступом.

                А уж именно области видимости тут вообще никак ни к селу ни к городу.
                Ответить
                • какой же ты бестолковый блеать) если бы я здесь написал "спецификаторы доступа" - никто бы не понял... а так все прекрасно поняли, что я имею ввиду, ну кроме одного "цпп-шного гения", который так любит всем что-то втирать и придераться к словам)
                  Ответить
            • в чем же существенные различия между классом и структурой для программиста, кроме как в различии областей видимости по умолчанию?
              Ответить
              • вероятно в том, что модификаторы доступа - это public, private, protected, а области видимости - локальная, глобальная.
                Ответить

Добавить комментарий

Помни, guest, за тобой могут следить!

    А не использовать ли нам bbcode?


    8