Здравствуйте, gandjustas, Вы писали:

NBN>>>>А чем мешают шаблоны и классы там где нужна высокая производительность?
G>>>Вряд ли они там мешают, но не помогают — это точно.
CC>>Код писать с ними удобнее чем в С стиле.
G>А на более выкогоуровневых языках еще удобнее. Вы с этим спортить будете?
Ты софист, с тобой спорить только время тратить.
Какое отношение другие языки имеют к сравнению С и С++?

NBN>>>>Ага, кроме как для игр, приложений затрагивающих эмбеддед сложнее простейших контроллеров, кроссплатформенных приложений которым требуется шустрая работа.
G>>>С играми отдельная песня — там сейчас во всю идет перенос тяжелых вычислений на аппартаные ускорители.
CC>>Да ты еще и геймдевелопер я смотрю И спец по переносу расчетов на GPU.
CC>>Ну-ка расскажи что там и как в геймдеве, а я послушаю.
G>Не, я с геймдевом сталкивался всего пару раз и обра раза впечатления неочень.
Т.е. ты не в курсе.
Но мнение, как полагается, имеешь.

Здравствуйте, gandjustas, Вы писали:

G>>>Я сталкивался с пользователями, которые вполне нормально мирились с генерацияей отчета на 1с (которая на С++) которая длилась двадцать минут.
___>>1С — УГ.
___>>Я знаю программу — Супермаг 2000, написанную на Оракле, отчет пару часов для небольшого магазина. И причем здесь Оракл? Хреновую программу можно написать на любом языке.
G>Я про это и говорю.
G>Самое главное что пользователи могут и пару часов подождать.
Значит нужно писать хреновые программы?

Здравствуйте, gandjustas, Вы писали:

G>>>>>Вряд ли они там мешают, но не помогают — это точно.
NBN>>>>Помогают — облегчают рефакторинг и читаемость кода.
G>>>Шаблоны улучшают читаемость только в самых простых случаях.
CC>>Шаблоны это не только александреску-стайл. С ними можно писать читабельный и удобный код.
G>Ну я и говорю — с самых простых случаях, но в таких случаях C++ сильно уступает по выразительности C#.
Откуда в сравнении С и С++ взялся С#? Мсье софист со стажем?

G>Каким образом имея 32-битный указатель можно обратить за пределы четырех гигов?
G>Возможно сама ось может увидеть много памяти, а для 32-битного приложения 4 гига — предел.
ОС это точно такой же код, как и в приложении, только привилегий побольше.
А добраться можно например через сегментные регистры и LDT, но это уже нестандартное приложение получится.
Так что технически это осуществимо.

Здравствуйте, Mamut, Вы писали:

M>Который невозможно сопровождать и отлаживать?
С неалександреску шаблонами — читабельный и отлаживабельный

Здравствуйте, gandjustas, Вы писали:

И>>>>>>>>Достаточно в таск менеджере взглянуть на кол-во используемой памяти .net прогой и С++ с эквивалентной функциональностью, чтобы понять, что ты гонишь.
G>>>>>>>Кроме того цифра в таск менеждере ни о чем не говорит, просто сверните приложение, будете удивлены.
CC>>>>>>Ты не в тот таскманагер смотришь, тебе уже сообщали.
G>>>>>Пор цифирке в таскабаре — не ко мне, они меня мало интересуют. Я производидтельность профайлером меряю.
CC>>>>И давно ты "кол-во используемой памяти" меряешь профайлером?
G>>>А я где-то говрил что меряю количество памяти?
G>>>Я же написал что эти цифирки не интересуют. Если нужно быстродействие, то меряю его профайлером.
CC>>Ты придуриваешься или всегда такой? Специально оставил поквоченную всю историю вопроса. Речь шла про (см. выше) память. Перечитай внимательно.
G>Читай выделенное.
Да да, тебе про потребляемую память, а ты "а мне до сиреневой звезды, у меня профайлер!".

G>Это же замечательно. Больше людей счастливы.
Особенно те, которым потом этот говнокод отдают на переделку.

Здравствуйте, gandjustas, Вы писали:

E>>Если есть сложная логика + много памяти + нужна скорость и компактность, то ХиндиС -- плохой выбор!
G>Покажите мне программу где все это нужно одновременно.
Алгоритм факторизации MPQS например. Памяти надо тонны, расчетов на месяцы.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, gandjustas, Вы писали:

E>>>Если есть сложная логика + много памяти + нужна скорость и компактность, то ХиндиС -- плохой выбор!
G>>Покажите мне программу где все это нужно одновременно.
CC>Алгоритм факторизации MPQS например. Памяти надо тонны, расчетов на месяцы.
Угу, и его чаще всего пишут на С, опять С++ остался неудел

Здравствуйте, CreatorCray, Вы писали:

CC> M>Который невозможно сопровождать и отлаживать?

CC> С неалександреску шаблонами — читабельный и отлаживабельный

Ну, когда на банальном СТЛе может вывалиться простыня в 5-7 строк звернутых друг в друга шаблонах — все равно не очень отлаживабельный http://pascalg.wordpress.com/2008/02/24/stl-error-messages-are-so-great/

#include <iostream>
#include <vector>

using namespace std;

int main(){
      vector<int> aList;

       aList.insert(10);    // итератор намеренно пропущен

       return 0;
}

Сообщение об ошибке

pascal@zetwal:~/temp$ g++ stltest.cpp
stltest.cpp: In function ‘int main()’:
stltest.cpp:9: error: no matching function for call to ‘std::vector<int, std::allocator<int> >::insert(int)’
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/vector.tcc:93:

note: candidates are: typename std::vector<_Tp, _Alloc>::iterator std::vector<_Tp, _Alloc>::insert(__gnu_cxx::__normal_iterator<typename _Alloc::pointer, std::vector<_Tp, _Alloc> >, const _Tp& ) [with _Tp = int, _Alloc = std::allocator<int>]
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_vector.h:657: note: void std::vector<_Tp, _Alloc>::insert(__gnu_cxx::__normal_iterator<typename _Alloc::pointer, std::vector<_Tp, _Alloc> >, size_t, const _Tp& ) [with _Tp = int, _Alloc = std::allocator<int>]

Здравствуйте, MxKazan, Вы писали:

CC>>Да блин у меня на 2 гигах открыты две VS2008 с решарпером и всё, 2 гига кончились. А проект запустить так вообще 2.7 гига коммит и веник в свопе надрывается.
MK>Да правда чтоль. На работе 2 Гига. Бывает и по три Студии открываю. И ничего не тормозит вообще.
MK>Про проект ничо не скажу, оно в зачаточном состоянии.
Проект на шарпе, здоровый, писан когда то американскими индусами.
Стало легче когда решарпер снёс.

Здравствуйте, gandjustas, Вы писали:

G>>>Например при ипользовании ФВП с помощью буста затайпдефить все функции не получися.
CC>>Функциональщину на С++ на данный момент я отношу к редкостным извращениям, полагая что если надо функциональщина — лучше взять другой язык.
CC>>Появится поддержка functional из С++0х в компилерах — будем посмотреть.
CC>>А пока это не для С++.
G>То есть всетаки с++ недостаточно выразительный.
В сравнении с С, про который речь в этой ветке?

G>Что и требовалось доказать.
Сам себе придумал, сам себе доказал. Как тебе жить просто, а.

Здравствуйте, gandjustas, Вы писали:

E>>>>Если есть сложная логика + много памяти + нужна скорость и компактность, то ХиндиС -- плохой выбор!
G>>>Покажите мне программу где все это нужно одновременно.
CC>>Алгоритм факторизации MPQS например. Памяти надо тонны, расчетов на месяцы.
G>Угу, и его чаще всего пишут на С, опять С++ остался неудел
А пацаны то и не знают

Здравствуйте, Mamut, Вы писали:

M>Сообщение об ошибке

M>pascal@zetwal:~/temp$ g++ stltest.cpp
M>stltest.cpp: In function ‘int main()’:
M>stltest.cpp:9: error: no matching function for call to ‘std::vector<int, std::allocator<int> >::insert(int)’
M>/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/vector.tcc:93:

M>note: candidates are: typename std::vector<_Tp, _Alloc>::iterator std::vector<_Tp, _Alloc>::insert(__gnu_cxx::__normal_iterator<typename _Alloc::pointer, std::vector<_Tp, _Alloc> >, const _Tp& ) [with _Tp = int, _Alloc = std::allocator<int>]
M>/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_vector.h:657: note: void std::vector<_Tp, _Alloc>::insert(__gnu_cxx::__normal_iterator<typename _Alloc::pointer, std::vector<_Tp, _Alloc> >, size_t, const _Tp& ) [with _Tp = int, _Alloc = std::allocator<int>]

M>[/q]

Вай батыр, какой дурдом!
Меняй компилер, срочно!
Кошерный выводит так:

Compiling with Intel(R) C++ 11.0.061 [IA-32]... (Intel C++ Environment)
main.cpp
.\main.cpp(9): error: no instance of overloaded function "std::vector<_Ty, _Ax>::insert [with _Ty=int, _Ax=std::allocator<int>]" matches the argument list
            argument types are: (int)
            object type is: std::vector<int, std::allocator<int>>
      aList.insert(10);    // итератор намеренно пропущен
            ^

compilation aborted for .\main.cpp (code 2)

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, gandjustas, Вы писали:

G>>>>Например при ипользовании ФВП с помощью буста затайпдефить все функции не получися.
CC>>>Функциональщину на С++ на данный момент я отношу к редкостным извращениям, полагая что если надо функциональщина — лучше взять другой язык.
CC>>>Появится поддержка functional из С++0х в компилерах — будем посмотреть.
CC>>>А пока это не для С++.
G>>То есть всетаки с++ недостаточно выразительный.
CC>В сравнении с С, про который речь в этой ветке?
В сравнении с другими языками, поддерживающими ФВП например.

G>>Что и требовалось доказать.
CC>Сам себе придумал, сам себе доказал. Как тебе жить просто, а.
Ну почему же, вы тут упорно доказываете что все надо писать на С++.
А оказывается что там где требуется производительность там пишется все на С (или на подмножестве С++), а там где производительность не требуется выразительности плюсов не хватает.

CC> Вай батыр, какой дурдом!
CC> Меняй компилер, срочно!

Это не решение проблемы

Здравствуйте, Mamut, Вы писали:

M>Ну, когда на банальном СТЛе может вывалиться простыня в 5-7 строк звернутых друг в друга шаблонах — все равно не очень отлаживабельный http://pascalg.wordpress.com/2008/02/24/stl-error-messages-are-so-great/
хы, и это разве сообщение об ошибке которым стоит гордится?

проанализировал как я анализировал:
взгяд ухватился за стрчку error:
далее прочитал текст no matching function for call
далее прочитал insert(int)
далее прочитал to ‘std::vector<int, std::allocator<int> >
далее взгляд перенёсся на aList.insert(10);
далее было задействовано около двух десятков лицевых мышц для выражения типа o_O

потрачено: ~6 секунд.
вывод: ето даже не попытка ввести в замешательство.

P.S. Рекомендую подключить буст.

Х> потрачено: ~6 секунд.
Х> вывод: ето даже не попытка ввести в замешательство.

Х> P.S. Рекомендую подключить буст.

Нууу, так нечестно Это должно было быть моим следубщим ходом На самом деле, vector — это вообще так, мелочевка Но ошибки уже впечатляют

Здравствуйте, gandjustas, Вы писали:

G>>>То есть всетаки с++ недостаточно выразительный.
CC>>В сравнении с С, про который речь в этой ветке?
G>В сравнении с другими языками, поддерживающими ФВП например.
А они откуда взялись в обсуждении "С или С++"?
Ты с темы не съезжай, будь так любезен.

G>>>Что и требовалось доказать.
CC>>Сам себе придумал, сам себе доказал. Как тебе жить просто, а.
G>Ну почему же, вы тут упорно доказываете что все надо писать на С++.
Примеры моих постов, где говорится "что все надо писать на С++" в студию. Причем там должно говориться "все надо писать на С++" и никак иначе.

Здравствуйте, Mamut, Вы писали:

CC>> Меняй компилер, срочно!
M>Это не решение проблемы
Ну так диагностика об ошибке то куда вменяемее. Проблема я так понял в неразборчивой простыне в случае ошибки.

Здравствуйте, CreatorCray, Вы писали:
G>>Не зачастую, всегда, но GC работает в сотни раз реже, чем выделение-совобождение памяти стандартным аллокатором.
CC>Это как напишешь. В unmanaged в реальном коде где надо performance выделение/освобождение памяти выносят "за скобки" и делают крайне редко.
Ты не поверишь — в managed делают точно так же. К примеру, для интенсивных сокетных операций на старте приложения распределяют буфера, которые впоследствии будут пиниться, чтобы защититься от фрагментации хипа.

Здравствуйте, CreatorCray, Вы писали:
CC>Беда то в том, что входной порог в managed сильно низкий, и обложенный памперсами нуб может спокойно говнокодить не получая при этом за свой говнокод по рукам — работает же, и не падает.
Ничего страшного. На плюсах нуб точно так же может говнокодить. То, что приложение сумело запуститься у нуба на машине, никак не гарантирует того, что оно будет устойчиво работать во всех сценариях.