The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В Google провели сравнение производительности C++, Java, Go ..., opennews (??), 05-Июн-11, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


22. "В Google провели сравнение производительности C++, Java, Go ..."  +1 +/
Сообщение от Аноним (-), 05-Июн-11, 01:35 
> C обычно показывает себя чуть шустрее плюсов и чуть экономичнее.

На нем сложно наворотами разбрасываться, что способствует культурному и экономному стилю программирования :)

Ответить | Правка | Наверх | Cообщить модератору

56. "В Google провели сравнение производительности C++, Java, Go ..."  –5 +/
Сообщение от Tiny (?), 05-Июн-11, 10:25 
Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах. void*, Мимикрия под ООП с использованием структур.
Ответить | Правка | Наверх | Cообщить модератору

59. "В Google провели сравнение производительности C++, Java, Go ..."  +4 +/
Сообщение от Andrew Kolchoogin (?), 05-Июн-11, 10:57 
> Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах.
> void*, Мимикрия под ООП с использованием структур.

Ограниченность C способствует удержанию в голове программиста идеи, что программа пишется для того, чтобы быстро работала и легко читалась другими людьми.

А что до void * -- во-первых, reinterpret_cast<> и в C++ никто не отменял, а во-вторых -- попробуйте догадаться, не перелопатив ВЕСЬ исходный код, как именно на C++ отработает конструкция вида a+b. :)

Ответить | Правка | Наверх | Cообщить модератору

61. "В Google провели сравнение производительности C++, Java, Go ..."  +/
Сообщение от Tiny (?), 05-Июн-11, 11:41 
Касты вас использовать никто не заставляет, ООП и шаблоны позволяют избавиться от такой необходимости, чего не скажешь о С. А по поводу оператора сложения - чем он в этом плане отличается от обычной функции?
Ответить | Правка | Наверх | Cообщить модератору

70. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от anonymous (??), 05-Июн-11, 13:43 
> А по поводу оператора сложения - чем он в этом плане отличается от обычной функции?

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

вообще, лучше бы CLU развили, а не отходы жизнедеятельности страусов.

Ответить | Правка | Наверх | Cообщить модератору

94. "В Google провели сравнение производительности C++, Java, Go ..."  +/
Сообщение от Andrew Kolchoogin (?), 05-Июн-11, 17:53 
> Касты вас использовать никто не заставляет,

А void * -- заставляют, что ли?

> ООП и шаблоны позволяют избавиться от такой необходимости, чего не скажешь о С.

О, да. Особенно при обращении к совсем не объектной операционке.

> А по поводу оператора сложения - чем он в этом плане отличается от обычной функции?

Да вот именно, что в C++ -- ничем.

А в C -- отличается. Поэтому я могу быть совершенно уверен, что оператор '+' в коде на C делает что-то, вполне соответствующее моему пониманию.

А вот как именно его перегрузил былоко^Wпрограммист на C++ -- пойди пойми, не перелопатив исходники.

Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

114. "В Google провели сравнение производительности C++, Java, Go ..."  +/
Сообщение от анон (?), 05-Июн-11, 21:05 
>А void * -- заставляют, что ли?

Порой без этого никак.
>оператор '+'

Данный оператор и в С++ будет делать что-то, вполне соответствующее вашему пониманию. Другое дело что в переменных типов отличных от стандартных данное действие бессмысленно.

Ответить | Правка | Наверх | Cообщить модератору

116. "В Google провели сравнение производительности C++, Java, Go ..."  +/
Сообщение от Andrew Kolchoogin (?), 05-Июн-11, 22:19 
> Данный оператор и в С++ будет делать что-то, вполне соответствующее вашему пониманию.

Если его не перегрузили.

А перегрузить его можно весьма эзотерическим способом. ;)

И получить что-нибудь вида operator+(char *, int) -- тупо делающий realloc и заполняющий конец пробелами. Или не заполняющий?-)

Правильно, см. исходники -- там и будет написано. ;)

Ответить | Правка | Наверх | Cообщить модератору

119. "В Google провели сравнение производительности C++, Java, Go ..."  +/
Сообщение от анон (?), 05-Июн-11, 22:29 
Ок. Зачем кому-то заниматься подобным? К тому же не стоит забывать и о макросах.
Ответить | Правка | Наверх | Cообщить модератору

121. "В Google провели сравнение производительности C++, Java, Go ..."  +1 +/
Сообщение от Andrew Kolchoogin (?), 05-Июн-11, 22:41 
> Ок. Зачем кому-то заниматься подобным?

О.

Мы подошли к Главному Вопросу Программирования: "Зачем быдлокодить?" :)))

Ответа на него у меня, к сожалению, нет. :)))
> К тому же не стоит забывать и о макросах.

#define TRUE FALSE

?-)

Ответить | Правка | Наверх | Cообщить модератору

161. "В Google провели сравнение производительности C++, Java, Go ..."  +/
Сообщение от анон (?), 06-Июн-11, 18:18 
Речь о другом на самом деле. Никто не вынуждает перегружать операторы. А без void* порой не обойтись.
Ответить | Правка | Наверх | Cообщить модератору

162. "В Google провели сравнение производительности C++, Java, Go ..."  +1 +/
Сообщение от dmi3semail (ok), 06-Июн-11, 18:47 
> И получить что-нибудь вида operator+(char *, int)

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

Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

156. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от anonymous (??), 06-Июн-11, 15:53 
> А в C -- отличается. Поэтому я могу быть совершенно уверен, что
> оператор '+' в коде на C делает что-то, вполне соответствующее моему
> пониманию.

справедливости ради:
#define + -

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

158. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от anonymous (??), 06-Июн-11, 15:55 
но не везде прокатывает, да. %-)
Ответить | Правка | Наверх | Cообщить модератору

69. "В Google провели сравнение производительности C++, Java,..."  –2 +/
Сообщение от anonymous (??), 05-Июн-11, 13:40 
> Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах. void*, Мимикрия
> под ООП с использованием структур.

ООП is not a silver bullet. also, ООП -- это мимикрия под структуры с усложнённым синтаксисом.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

77. "В Google провели сравнение производительности C++, Java,..."  –1 +/
Сообщение от Tiny (?), 05-Июн-11, 14:22 
>> Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах. void*, Мимикрия
>> под ООП с использованием структур.
> ООП is not a silver bullet. also, ООП -- это мимикрия под
> структуры с усложнённым синтаксисом.

Потрудитесь узначть что такое ООП для начала

Ответить | Правка | Наверх | Cообщить модератору

79. "В Google провели сравнение производительности C++, Java,..."  –2 +/
Сообщение от anonymous (??), 05-Июн-11, 14:26 
> Потрудитесь узначть что такое ООП для начала

это фетиш некоторых wannabe-программистов. которые считают, что симула-подобные императивные языки — это Ъ и вершина технологий.

Ответить | Правка | Наверх | Cообщить модератору

117. "В Google провели сравнение производительности C++, Java,..."  +4 +/
Сообщение от Andrew Kolchoogin (?), 05-Июн-11, 22:24 
>> Потрудитесь узначть что такое ООП для начала
> это фетиш некоторых wannabe-программистов. которые считают, что симула-подобные
> императивные языки — это Ъ и вершина технологий.

Вы перегибаете палку.

Для "объектируемых" алгоритмов ООП весьма и весьма полезен, т.к. сокращает процесс отладки.
Для "необъектируемых" -- " -- " -- " -- " -- вреден, т.к. удлиняет -- " -- " -- " --

К примеру, практически любую GUI-софтину можно натянуть на объектную модель.
С brute-force кракалкой паролей всё строго наоборот.

Multi-threaded-сервер для ООП хорош.
Сервер на основе FSM -- плох.

От алгоритмов надо идти, а не от парадигмы. Ну и, конечно, "когда под рукой нет ничего, кроме молотка, всё вокруг кажется гвоздями" -- если программист никакой другой модели, кроме объектной, не знает -- плохи дела...

Ответить | Правка | Наверх | Cообщить модератору

159. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от anonymous (??), 06-Июн-11, 15:59 
> Вы перегибаете палку.

немного. я, впрочем, не говорил, что ООП не нужно вовсе; я просто имел в виду, что есть определённый подвид людей, для которых всё, что не-ООП — это ерунда, устарело, ненужно и неудобно.

опять же — можно было бы тролльнуть человека тем, что «ООП придумали те, кто не смог сделать замыкания», но, кажется, он бы всё равно не понял.

Ответить | Правка | Наверх | Cообщить модератору

138. "В Google провели сравнение производительности C++, Java,..."  –1 +/
Сообщение от oops_ (?), 06-Июн-11, 06:26 
>>> Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах. void*, Мимикрия
>>> под ООП с использованием структур.
>> ООП is not a silver bullet. also, ООП -- это мимикрия под
>> структуры с усложнённым синтаксисом.
> Потрудитесь узначть что такое ООП для начала

Это всего лишь надстройка над структурным программированием.

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

164. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от анон (?), 06-Июн-11, 22:40 
ru.wikipedia.org/wiki/Объектно-ориентированное_программирование посмотрите пункт "основные понятия".
Ответить | Правка | Наверх | Cообщить модератору

165. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от anonymous (??), 06-Июн-11, 22:47 
> ru.wikipedia.org/wiki/Объектно-ориентированное_программирование посмотрите пункт
> "основные понятия".

мало того, что ссылка на русскую педию, так ещё и не в тему.

Ответить | Правка | Наверх | Cообщить модератору

166. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от анон (?), 06-Июн-11, 22:55 
А что не так с русской вики? Очередные придирки с претензией на интеллектуальность? Насчет ссылки - можно было и догадаться. Прочитайте основные принципы ООП и ответьте - причем здесь структуры?
Ответить | Правка | Наверх | Cообщить модератору

170. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от anonymous (??), 06-Июн-11, 23:09 
> причем здесь структуры?

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

Ответить | Правка | Наверх | Cообщить модератору

173. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от анон (?), 07-Июн-11, 07:13 
Считайте что "структуры" в данном конексте и есть "структурное программирование".  Глупые придирки означают лишь то, что вам нечего ответить по делу.
Ответить | Правка | Наверх | Cообщить модератору

174. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от anonymous (??), 07-Июн-11, 07:16 
> Считайте что «структуры» в данном конексте и есть «структурное программирование».

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

Ответить | Правка | Наверх | Cообщить модератору

175. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от анон (?), 07-Июн-11, 08:02 
>я также могу считать

Дело ваше. Только в текущем контексте подмена слов вполне допустима.
>мне достаточно этой «описки»

По вашим постам впрочем не сложно понять, что основная цель спора - переход на личности. В таком случае нам с вами разговаривать не о чем.

Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

176. "В Google провели сравнение производительности C++, Java,..."  +1 +/
Сообщение от anonymous (??), 07-Июн-11, 08:11 
зачем так дрожать за свою «личность»? вот же фетиш у людей… ты всё равно аноним — тебе не плевать, что о тебе скажет другой аноним?

а вот то, что ты как минимум облажался, попутав «структуры» и «структурное программирование», а теперь ещё и утверждаешь, что «в текущем контексте подмена слов вполне допустима» — факт. я тебе несколько раз давал возможность признать, что ты ступил — а ты не то, что не захотел ней воспользоваться, а до сих пор не понимаешь, почему после такой ошибки серьёзно с тобой разговаривать просто смешно.

Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

177. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от анон (?), 07-Июн-11, 08:35 
>а вот то, что ты как минимум облажался, попутав «структуры» и «структурное программирование»

Признаю, просто запутало то что изначально речь шла именно о структурах.
>а до сих пор не понимаешь, почему после такой ошибки серьёзно с тобой разговаривать просто смешно.

Понимаю и извиняюсь за ваше потраченное время.

Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

179. "В Google провели сравнение производительности C++, Java,..."  +/
Сообщение от anonymous (??), 07-Июн-11, 08:49 
и вот почему сразу было не сказать: «пардон, ошибся, вас много, я один»? зачем было всё это время упорствовать? как будто больше никто никогда не ошибается…
Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

101. "В Google провели сравнение производительности C++, Java, Go ..."  +/
Сообщение от Аноним (-), 05-Июн-11, 19:38 
> Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах.

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

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

118. "В Google провели сравнение производительности C++, Java, Go ..."  +1 +/
Сообщение от Andrew Kolchoogin (?), 05-Июн-11, 22:29 
>> Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах.
> Почему-то быдлокода на высокоуровневых языках куда больше.

Потому, что пишут на них больше. Писали бы на языке Ассемблера -- быдлокод был бы там.

А вообще -- возьмите ядро Linux'а версий примерно 2.0-2.2, и посмотрите в тамошний C.

Вырвиглазный пиз^W^WОчень своеобразный стиль кодирования. :)

Ответить | Правка | Наверх | Cообщить модератору

130. "В Google провели сравнение производительности C++, Java, Go ..."  +/
Сообщение от Бублик (?), 06-Июн-11, 02:02 
Увы, быдлокода на любых массовых языках полно. Быдлокод чаще всего элементарно рентабельней.
Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

140. "В Google провели сравнение производительности C++, Java, Go ..."  +1 +/
Сообщение от iZEN (ok), 06-Июн-11, 07:47 
> Увы, быдлокода на любых массовых языках полно. Быдлокод чаще всего элементарно рентабельней.

"Быдлокод" чаще всего поддаётся рефакторингу и покрытием Unit-тестами. Но! Быдлокод сначала пишут, а потом рефакторят и не делают предварительных оптимизаций, то есть "на выброс, а там поглядим, нужно ли". Для старой школы традиционен подход водопадной модели разработки, когда сначала много-много думают, потом просто думают, потом пишут, как монолит: на века.


Ответить | Правка | Наверх | Cообщить модератору

137. "В Google провели сравнение производительности C++, Java, Go ..."  +/
Сообщение от oops_ (?), 06-Июн-11, 06:20 
>> C обычно показывает себя чуть шустрее плюсов и чуть экономичнее.
> На нем сложно наворотами разбрасываться, что способствует культурному и экономному стилю
> программирования :)

Насчет культуры поспорил бы. Слижком уж волно писать позволяет.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру