Войти
ФлеймФорумПрограммирование

not invented here (4 стр)

Страницы: 13 4 5 616 Следующая »
#45
0:57, 5 фев. 2013

du_hast
Что ты за херню написал, и зачем ты приписываешь это мне?


#46
1:01, 5 фев. 2013

Iskander
> Что ты за херню написал, и зачем ты приписываешь это мне?

Ты сказал: "Точно так же ты добавишь вызов их деструкторов и ручное закрытие ресурсов в деструктор горшка". Объясни, как добавить "вызов их деструктора"?

#47
1:20, 5 фев. 2013

du_hast
> Объясни, как добавить "вызов их деструктора"?

class Gorhok(){
  Resource1 *member1;
  Resource2 *member2;

  virtual ~Gorhok() { 
     delete member1;
     delete member2;
  }
}


Ты конечно можешь хранить члены класса не по указателям, а по значению.

class Gorhok(){
  Resource1 member1;
  Resource2 member2;
}
Тогда деструкторы вызовутся автоматически, да. Взамен ты получаешь обязательность создания member1 и member2 в конструкторе класса Gorhok. Автоматом ты получаешь невозможность использования виртуальных функций для определения правил создания member1 (хотя это зачастую не нужно вообще). Ты уже не сможешь создать часть членов только, а часть оставить как null (предположим тут нет божественности объекта и нарушения S).
Плюс в деструкторе ты получаешь порядок вызовов определяющийся исключительно порядком объявления этих членов класса. Я не уверен что это однозначно хорошо.


Абсолютно то же самое. Как я уже говорил, в 99% случаев явный вызов dispose/close не нужен. В языках с гц пожертвовали удобством 1 процента случаев (да и то, спорно, даже тут зачастую то же самое) чтобы отказатсья от геморроя в остальных 99.

#48
1:41, 5 фев. 2013

Iskander
> Плюс в деструкторе ты получаешь порядок вызовов определяющийся исключительно
> порядком объявления этих членов класса. Я не уверен что это однозначно хорошо.

Думаю, что таки хорошо. Ты ж в теме про атрибуты говорил, что "декларативность - это хорошо".

Ну и

class Gorhok(){
    std::unique_ptr<Resource1> member1;
    std::unique_ptr<Resource2> member2;

  virtual ~Gorhok() {}
};

> обязательность

Видишь, в крестах у меня есть выбор. Могу "гарантировать обязательность", могу "опционально".

#49
1:48, 5 фев. 2013

Iskander
> +1. Следует оставить только С - для драйверов, низкоуровневых сервисов и
> высокопроизводительных приложений, Java для прикладных приложений, JavaScript
> для веба и Perl для различных скриптов. Это языки, доказавшие свою полезность,
> и выдержавшие испытание временем. Остальные, отличающиеся на пару процентов
> (вроде kotlin, haxe, c++, php, python) не нужны.
Ваше мнение очень важно для нас, оставайтесь на линии. XD
В языках программирования, как и в ОС и вообще во всём включая жизнь, существует естественный отбор, так что чего бы кто бы не хотел ситуация будет меняться исключительно по естественному отбору.
С++ умрёт только в том случае если, появится настолько же производительный язык, при этом настолько же удобный, и с таким же количеством готовых библиотек, и с не уступающим набором компиляторов. То есть, примерно..... никогда!

#50
1:51, 5 фев. 2013

du_hast
> Думаю, что таки хорошо. Ты ж в теме про атрибуты говорил, что "декларативность
> - это хорошо".
Это не декларативность.

du_hast
> Ну и
Ок, убедил. В данном 1% случаев умение c++ автоматически вызывать конструкторы - удобнее. Не надо писать одну лишнюю строчку.

#51
1:56, 5 фев. 2013

Chaos_Optima
> С++ умрёт только в том случае если, появится настолько же производительный
> язык, при этом настолько же удобный, и с таким же количеством готовых
> библиотек, и с не уступающим набором компиляторов. То есть, примерно.....
> никогда!
Ты не замечаешь наверное, но в прикладном программировании он почти нигде кроме игр и не используется. Даже из таких математических областей как распределенные вычисления он вытесняется этими вашими хадупами и  грид гейнами.  Доходит до прикола - желающим использовать какой-нибудь map-reduce фреймворк на плюсах рекомендуют биндинг к hadoop.

#52
2:01, 5 фев. 2013

Iskander
> но в прикладном программировании он почти нигде кроме игр и не используется

Раз уж ты вспомнил массовое обслуживание. Я как раз таки разрабатывал сервис, которым пользуется довольно много людей и таки на крестах. Если бы он был на петоне, нам бы потребовалось в 10-100 раз (во столько раз медленнее петон крестов) серверов, места под них, электричества, охлаждения, проводов, свичей, обслуживания. И люди бы получали бы ответ позже (а это очень важная метрика).

#53
2:06, 5 фев. 2013

du_hast
> Я как раз таки разрабатывал сервис, которым пользуется довольно много людей и
> таки на крестах
Таки что за сервис, хотя бы общее направление. И таки, что ты там делал. А вообще заявление в стиле "ты говоришь что вот большинство людей на лекговушках ездят, а вот мой дядя на белазе работает"

du_hast
> И люди бы получали бы ответ позже (а это очень важная метрика).
Биржа?


du_hast
> Если бы он был на петоне, нам бы потребовалось в 10-100 раз (во столько раз
> медленнее петон крестов) серверов, места под них, электричества, охлаждения,
> проводов, свичей, обслуживания
Во первых странная пропорция, ну да ладно. Могу тогда заявить, что вы бы зато написали его в 10-100 раз быстрее и доработка новая занимала бы в 10-100 раз меньше времени. лол.

#54
2:11, 5 фев. 2013

Iskander
> написали его в 10-100 раз быстрее и доработка новая занимала бы в 10-100 раз меньше времени.

вероятно. но стоимость запуска и эксплуатации выросла бы раз в 10-100. каждый сервак стоит $3k, плюс место, электричество и обслуживание.

> лол.

вероятно.

> Таки что за сервис, хотя бы общее направление. И таки, что ты там делал.

да мечтаю я.

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

Ты сам заговорил про массовое обслуживание.

#55
2:28, 5 фев. 2013

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

Про массовость - да, джава, шарп и питон это массовые. С++ нишевый. Из серверов его вытеснили давно уже, исключения остались. Из распределенных систем обработки данных вытесняют активно, как и из десктопа. Игры тож уже на очереди.

#56
2:30, 5 фев. 2013

Iskander
> стоимость серверов вообще ничтожна по сравнению с.

десятки (теперь сотни) тысяч серверов?

#57
2:41, 5 фев. 2013

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

#58
2:45, 5 фев. 2013

Iskander
> Думаю это небольшая сумма совсем от вашей зарплаты.

Но когда я работал отрасли, связанной с производством аппаратуры (серийным) мы экономили на smd конденсаторах, это вот такие штучки (примерно, 1.5мм на 1мм):

Изображение
#59
2:54, 5 фев. 2013

Iskander
> Ты не замечаешь наверное, но в прикладном программировании он почти нигде кроме
> игр и не используется.
RLY? приведи список программ у тебя на компе и посмотрим какие из них написаны не на С++
Iskander
> для крупного проекта стоимость серверов вообще ничтожна по сравнению с.
RLY? напомни, какой у тебя опыт работы с обслуживанием большого количества серверов?
каждый сервак стоит 3к$ + незабываем о потреблении электричества + оборудование для охлаждения +затраты электричества на охлаждение +админ или даже несколько +Аренда помещения под серваки +затраты на маршрутизацию этих серверов, затраты бешеные. Не удивительно что СССР (создатели EVE) переписали свои серваки с питона на С++
И к тому же разработка на ++ ненамного дороже и дольше нежели разработка на другом языке. 
Iskander
> Про массовость - да, джава, шарп и питон это массовые.
как много приложений для винды ты видел написанных на шарпе, яве, и особенно на питоне?
Iskander
> Из серверов его вытеснили давно уже, исключения остались.
в каком плане сервер? если ты про обработку сообщений то Апачи частично на С++, частично на С написан к примеру, базы данных поголовно написаны на С\С++.

Страницы: 13 4 5 616 Следующая »
ФлеймФорумПрограммирование

Тема в архиве.