Пространство имен

[thechicho]

// В одном потоке вызывается GET, а в другом POST.
вот это будет эпик фейл...
но разве для каждого потока не будут созданы свои экземпляры класса Functions...

у меня ща так сделано

Код

C++ (Qt)
class BlaBlaThread : public QThread, public Functions
{
    Q_OBJECT
 
public:

я думал, что для каждого потока будет свой объект Functions, соответственно, общих данных не будет...

ведь так?

[Пантер]

Ох, ппц. Учи ООП. Нахрена тут множественное наследование?

[thechicho]

чтобы можно было использовать функции без всяких приставок (класса, namespace и тп)

[Пантер]

facepalm.jpg

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

[kambala]

у тебя что ли оплата работы обратно пропорциональна количеству символов?

[thechicho]

а чо метку искать-то, в нескольких строчках.

// Это общепринятые подходы.
анархия мать порядка.

// Я уж было подумал, что ты стал беспокоиться о своем коде, что завел такую тему. А нет все в порядке)
харе палить кантору

// куда прозрачнее там будет использовать рекурсию. конечно, для этого придётся немного переписать код
это хде?О_о
у меня там рекурсия только на переход по редиректу.
или ты чо имеешь в виду.

а насчет вложенных циклов... я до них еще не дорос, т.к. я хз чо за циклы такие break; решает все проблемы

[thechicho]

// Множественное наследование нужно только тогда, когда оно оправдано. Лично мне еще ни разу не пришлось им пользоваться
а чем оно плохо в данном случае?
если я правильно понимаю, для каждого потока будет создан свой экземпляр с функциями, т.е. глабальные переменные класса Functions будут в каждом потоке свои адреса иметь. как-то так... короче работать должно. если я все правильно понимаю.

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

// у тебя что ли оплата работы обратно пропорциональна количеству символов?
кто бы меня взял то еще на работу прогером
я не работаю "на дядю". я продаю софт и услуги пока что.
а так, если бы я в команде работал, разумеется использовал бы "общепринятые нормы" по мере знаний своих неглубоких

[thechicho]

// facepalm.jpg
этот круче http://kolobok.us/smiles/light_skin/facepalm.gif
кстати, добавь лучше колобков вместо этих смайлов.

а то тока один прикольный - 
ну этот еще ничо так -

[thechicho]

зацените аву

[Пантер]

а чем оно плохо в данном случае?

Да тем, что у тебя идет лишняя завязка. Вот зачем множественное наследование, если можно сделать так:

Код:

class BlaBlaThread : public QThread
{
    Q_OBJECT
 
private:
Functions functions_;

Это тоже хреново, но получше твоего варианта.

[mutineer]

а так, если бы я в команде работал, разумеется использовал бы "общепринятые нормы" по мере знаний своих неглубоких

Откуда ж ты эти нормы возьмешь, если не используешь их в коде своем?

[thechicho]

// Вот зачем множественное наследование, если можно сделать так
так сделать нельзя, все методы и свойства вываливаются из области выдимости. т.е. вылазит куча ошибок. надо тогда к каждой функции приписывать объект.

// Это тоже хреново, но получше твоего варианта
я так и делал сначала, но грю, только с именем объекта видно.
поэтому методом тыка отнаследовал, и все заработало

и чем хреново то?
это как-то скажется на производительности, стабильности работы проги?

[thechicho]

// Откуда ж ты эти нормы возьмешь, если не используешь их в коде своем?

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

[andrew.k]

// Откуда ж ты эти нормы возьмешь, если не используешь их в коде своем?

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

Ага.
Когда мне понадобиться, я начну красиво и технологично писать код.
А сейчас мне это не надо, поэтому я буду писать как хочу.
Ну да. Подход.

[thechicho]

если обломится такое счастье и кто-то меня возьмет на работу программером ("будь проклят тот день, когда... я нанял его на работу" (с) потенциальный работодатель )

я не начну красиво и технологичено писать код.
я буду писать, как того потребуют реалии.

приказ - написать красиво и технологично.
будет написано красиво и технологично.
приказ - написать быстро и шобы работало
будет написано быстро и будет работать.

я себе отдаю приказы второго плана
вот как-то так.
andrew.k, хватит выдумывать то, чего нет