1. Список говнокодов пользователя PascalOverlord

    Всего: 2

  2. C++ / Говнокод #22058

    −16

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    MyBeautifulMarvelousStruc funcWithoutReturnStatement(FuckMyLife eatShitAndDie)
{
    MyBeautifulMarvelousStruc mbms;
    mbms.myLife = eatShitAndDie;
}

int main()
{
    ...
    MyBeautifulMarvelousStruc test = funcWithoutReturnStatement(eatShitAndDie);
    ...
}

    Призываю дядь в крестах шарящих.
    Я объявляю функцию, возвращающую некую структуру. В определении не пишу "return". Собираю с MinGW 4.9.2 32bit. Собираю не вручную, подключил компилер в QtCreator-е. Ошибок при компиляции нет. Создаётся структура, поля которой есть неинициализированный хлам (что не удивительно). Вопросы:
    * Что возвращает функция без "return" в теле функции?
    * Почему это компилится?
    * Что читать, чтобы такие вещи знать?
    Не буду утверждать, что читал от корки до корки книжку дядюшки Шилдта, пользовался ей как справочник по базовому синтаксису с комментариями. Листал, короче.
    Или это разговор не о c++, а о компиляторах c++?

    PascalOverlord, 27 Января 2017

    Комментарии (258)

  3. C++ / Говнокод #22027

    −20

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    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
    65. 65
    66. 66
    67. 67
    68. 68
    69. 69
    70. 70
    71. 71
    72. 72
    73. 73
    74. 74
    75. 75
    76. 76
    77. 77
    78. 78
    79. 79
    80. 80
    81. 81
    82. 82
    83. 83
    84. 84
    85. 85
    86. 86
    Допустим, хочу добавить новый функционал. Что нужно для этого сделать:
1. Объявить сигнал в интерфейсе интерфейсов (хех). Этот, например, скажет презентеру, что пользователь хочет добавить нового ученика в бд.
void addStudSIG(StudentData newStudent); 
2. Объявить одноимённый слот в презентере. Пока всё терпимо.
void addStudSLOT(StudentData newStudent); 
3. прихуярить их друг к другу в методе презентера, который отвечает за подписку на сигналы интерфейса
QObject::connect(uI, SIGNAL(addStudSIG(StudentData)), this, SLOT(addStudSLOT(StudentData)));
4. реализуем этот слот, реализация состоит из вызова одного метода ("o_" это указатель на "модель", "o" значит "owl", но это не важно)
o_->addStud(newStudent);
5. объявляем этот метод в "модели"
qint32 addStud(StudentData newStudent); // возвращаемое значение это id новой записи в таблице
6. реализуем, опять вызовом одного метода
sController_.addItem(newStudent); // для каждой сущности в таблице у меня есть controller, который отвечает за её обработку
7. Теперь, просто реализуем метод контроллера средствами подключённой ормки, если контроллер есть.
Если нет, то нужно ещё немного покопипастить своего кода.
Т.е. "бизнес-логика" размазана по этим контроллерам. Такая архитектура порождает кучу проблем. Копирую имена методов, чтобы создавать методы.
А если хочешь узнать, что же делает сигнал и тебе не достаточно комментария над ним, нужно идти в глубь на 3 или 4 слоя по вызовам одноимённых
методов, нихуя не понимая.
Думал, создать для всех этих объектов общий интерфейс и возможностями Qt Creator, чередуя левую и правую кнопку мыши, частично генерировать
код. Но это какая-то абстрактная говнокод-фабрика получится. И лапша из перевызова методов не распутается, пусть даже готовиться эта лапша будет
быстро.
Думал, вместо внедрения контроллеров в модель, пронаследовать моделью все эти контроллеры и спокойно вызывать методы. Но 4 предка у одного
класса показалось мне диковатым.
У меня ощущение, что я как ооп-обезъяна забил трюм ненужными классами и потонул. Может не нужно было явно выносить model, view, presenter
в классы? Может не нужно было делать классы для контроллеров, а сделать процедуры в отдельном файле? Слишком много "может".
Я доделал это. Оно злобно рычит, но работает. Но я не хочу каждый раз так задрачивать кнтрлц/кнтрлв. Любой фидбек поможет.
Заранее спасибо. Прикрепляю заголовочники упомянутых классов, сколько влезет.
// абстрактный класс, родитель для любого интерфейса
class UserInterface : public QObject
{
    Q_OBJECT
public:
    UserInterface();
    // методы для обновления интерфейса
    virtual void update(данные для обновления интерфейса) = 0;
    // далее куча подобных методов

// сигналы сообщают Presenter-у, что произошли изменения в интерфейсе и передают данные от пользователя на дальнейшую обработку
signals:
    void addStudSIG(StudentData newStudent);
    // далее куча сигналов
};

// назвал presenter чертом
class Daemon : public QObject
{
    Q_OBJECT

public:
    // подписаться на все события (сигналы) интерфейса пользователя, запомнить указатели на представление и модель
    void listen(UserInterface *uI, Owl *o);

// чтобы узнать, что делает слот, смотри одноимённые сигналы UserInterface
public slots:
    void getStudsByGradeSLOT(qint32 grade);
    // далее куча слотов

private:
    // указатель на интерфейс
    UserInterface *uI_;
    // указатель на модель (бизнес-логику)
    Owl *o_;

    // прихуярить все сигналы uI к слотам Daemon
    void connectSiWithSl_(UserInterface *uI);
};

// это "модель"
class Owl
{
public:
    Owl();
    ~Owl();

    void addStud(StudentData s);
    // далее все возможные преобразования над бд, owl получился что-то вроде фасада над конкретными контроллерами

    // создание бд, открытие и закрытие соединения
    void initDb_();
    void close_();
private:
    // контроллер, отвечающий за создание бд и открытие, закрытие соединения...
    BasicDquestDbController bController_;
    StudentController sController_;
    // далее по контроллеру на каждую сущность базы данных
};

    Ахой, матросня! Сегодня с вами капитан Кьют и мы будем бороздить просторы говноморей в поисках код-ревью. Пишу сейчас проектец на Qt. Нас на палубе 2 говнокодера. И я близок к тому, чтобы килевать самого себя. У кого есть время и желание, жду от них совета, а те, кто не захочет помочь, сможет поугарать над начинающей c++ макакой.
    В двух словах о проекте: несложное приложение, работает с локальной бд на SQLite через ормку какого-то случайного азиата с гитхаба, интефейс на Qt-шных формах. Архитектурно попытался изобразить MVP. Почему его? Интерфейс нужно было отделить от всего остального. Разработка интерфейса выделилась в отдельную, сложную (и, вроде бы, интересную) задачу. Ею занимаюсь не я. Я отвечаю за "presenter" и "model". Наверное, можно это назвать бекендом. И, чтобы каждый раз не тратить несколько минут на сборку проекта, (все эти ебучие виджеты) я имею заглушку интерфейса. Так вот, братва, я где-то проебался. Нахуярил классов и проебался. Заметил за собой, что при добавлении каждой новой фичи (при готовом скелете архитектуры) снова и снова копирую и вставляю одноимённые функции в одноимённые функции...

    PascalOverlord, 24 Января 2017

    Комментарии (66)