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

VD>И вообще, что это за позиция — устроиться куда-то "на начальную позицию"?
VD>Это значит ты будешь изучать что-то, а тебе за это еще и платить кто-то должен?

Да, так бывает. И не только в ПО. И не только сейчас, но и раньше было.
То, что ты не умеешь искать такие позиции, всего лишь говорит что-то о тебе, а не об окружающем мире...
Можешь подумать над значением слова "подмастерье"...

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

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

G>>

G>>var stackArrayOfStruct = stackalloc SomeStruct[10];
G>>

Х>хы, ансейф, вперёд к С++?

Х>просто вот когда дело доходит до новых апи — здравствуй интероп с нейтивом
О да, это просто нереальная сложность, написать DllImport наверное непостижимая задача.

Х>хочешь массив на стеке — здравствуй ансейф,
Думаешь он часто нужен?

Х>тот же пэйнт.нет афаир просто насквозь пропитан ансейфом
От силы 5% ансейфа.

Х>зачем тогда сишарп?
Все что ты назвал никак не мешает использовать всю мощь сишарпа.

Х>хорошие вещи делаются только в нейтиве, вот тот же пример с выводом строк, для такой забавы как флейм на рсдн и стримы с регекспами не грех использовать, а вот если бы ето была программа промышленных маштабов — скажим анализатор логов, то здравствуй мем-маппед файлы да стейт-машины с отсутствием аллокаций, и писать етона си++ без ifstream и multiset, а не на сишарпе с gc и аллокацией на каждый чих.
А доказательсва будут? Ты еще не заметил что GC работает быстре стандартного аллокатора?

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

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

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

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

BZ>>>>читай внимательно. в языках с gc гарантия — на 3x, можно и меньше. в C++ — гарантий никаких, расход может быть каким угодно прсто потому что память усеяна мелкими дырками

NBN>>>C++ очень универсальный язык Он позволяет писать так как тебе нужно. В частности обеспечить все гарантии по чему хочешь, чем я, кстати, на днях воспользовался.
G>>Я вот тут на днях написал на C# библиотеку для работы с конечными автоматами. Она генерирует в рантайме код автомата по описанию, а потом использует его.
G>>На C++ такое получится?

E>И что же из себя представляет описание?
XML или код.

E>И что из этого описания генерируется?
Вложенные ифы.

E>И зачем это нужно в рантайм, почему нельзя в compile-time?
Пчто в рантайме задавать без перезапуска.

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

G>Круто, а фабричный метод так изобразите?
А зачем в данном случае фабричный метод?..
Но вообще-то возможно и изображу, правда тут надо бы уточнить, что ты понимаешь под "фабричный метод", так как может и изображу, а может и нет...

G>ЗЫ. Передача указателя на стек до добра не доводит, большенство уязвимостей в ПО так и получаются.
А как можно было бы такой уязвимостью воспользоваться? Ну, хотя бы, гипотетически? Это же не буфер, а объект на стеке.

Про то, что в больших программах 99% кода достаточно глубоко запрятаны для того, чтобы не смочь породить уязвимость, я и не говорю..

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

C>Вы глубоко заблуждаетесь. Лучший тому пример — Microsoft Blend, и AutoCAD, последних версий.
Про AutoCAD это еще кто заблуждается:

Using the ActiveX® (COM Automation) interface in AutoCAD Architecture software, you can build applications with a variety of programming technologies and environments including Microsoft® Visual C++®, Visual Basic® (VB), Delphi, and Java. AutoCAD Architecture extends the AutoCAD ActiveX interface to provide direct access to most of its custom objects.

Being based on AutoCAD, AutoCAD Architecture also includes Visual Basic for Applications (VBA), the most popular programming environment, and Visual LISP®.

When developing object oriented C++ applications for AutoCAD Architecture, you'll need to work with both the AutoCAD ObjectARX® SDK and the Object Modeling Framework (OMF) for AutoCAD Architecture. Designed for use by professional programmers to develop the fastest, most efficient, and most compact applications for AutoCAD, ObjectARX and the OMF provide the highest performance applications for AutoCAD Architecture, and an ideal development environment.

In 2007, AutoCAD Architecture's .NET interface has been expanded with many classes previously only supported through OMF and C++ now accessible to all .NET supporting languages. Now VB and C# developers can access most of the power of OMF.

http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=3377116

Внутри AutoCAD как был C++ + MFC (AutoCAD200, для него сам расширения писал), так и остался. Для тех кто сомневается, пост из AutoCAD форума:

maybe you are compiling with the debug version of the MFC libraries. You can check the project configuration properties and see what you have set in C/C++ -> Code Building -> Runtime Library. Here you have to set the value "DLL Multithread (/MD)" either for the debug that for the release configuration. This is because Autocad use only the release version of MFC.

http://discussion.autodesk.com/forums/thread.jspa?messageID=6137033&#6137033

Справедливости ради надо сказать, что пост там про AutoCAD2008. Но вряд-ли AutoCAD2009 что-то изменилось кардинально.

Так что AutoCAD из списка С# приложений вычеркивайте

Алексей

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

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

MK>>Здравствуйте, Хвост, Вы писали:

Х>>>потому что я был уверен что struct в C# ето только данные и все операции с ним аля положить в массив и вызвать метод происходят только в его боксовом представлении
MK>>Угу. Еще ты был уверен про уровень

Автор: Хвост
Дата: 20.03.09

разработчиков .Net.
MK>>Что теперь мешает и мне написать подобный пост про тебя?
Х>к тому же если ты проследишь начало темы про структуры, то она была о размещении их в массиве, и тут без ансейфа вариант действительно только один — боксинг.
Если нужно на стеке то почему бы не использовать ансейф?
Ансейф не означает отказ от возможностей шарпа и не объявляет о бажном коде. Это просто код где потенциально могут возникнуть ошибки, на C++ например вся программа такая, и ниче.

Х>C# (особенно в версии 3.5) ето очень мощный язык, но для приложений требующих производительности, малой затраты ресурсов, быстрой реакции интерфейса ето просто моветон.
Это каких таких приложений? И причем тут интерфейс? Вы скорость полета WPF видели? Очень рекомендую посмотреть доклад PC46 c PDC2008, повторите такое же на С++ тогда вам поверят.

Х>Дотнетчики же говорят "ааа, да ты чего, купи 4 ядра, возьми 16 гб" меня просто умиляют
Да ну, ссылку кините?
Как раз большенство софта работает на обычных современных компах, с парой гигов и максимум двумя ядрами.
Это только на вопли С++ников, что оно кушает много памяти, так отвечают.

Х>вы поймите, что достойная производительность ето дополнительный функционал, ето когда спеллчекер подчёркивает красным не через две секунды после набора слова а сразу, ето когда в CAD'ах скролл рабочей области работает плавно, ето когда скриптовый google docs интерфейс не лагает, ето когда ты можешь в корелдро видеть тридцать слоёв одновременно а не пять, или когда диаграмму в таблице можно увидеть не только в плоском виде а в 3д и повращать, т.е. ещё раз, дополнительные ресурсы — дополнительный функционал.
А вы можете показать где .NET реально тормозит, кроме убогих поделок говнокодеров?
Убогие поделки и на С++ есть.

Х>Вся ета дотнетчина на десктопах ето от бедности, когда нет денег нанять высокопрофессиональных программистов на С++ чтобы сделать проект и планка качества невысока, сойдёт и сишарп. Ентерпрайз лично у меня никогда не ассоциировался с качественным кодом, имхо там главная цель — лишь бы правильно работало, а уж быстро ли, медленно ли, интерфейс кривой или прямой — ето уже волнует в пятую очередь.
А что есть качество?

Х>Что насчёт дотнета на серверах — я только за, там дотнет ето просто клей, логика, вся тяжёлая работа лежит на сиквел-серверах + если надо какие-либо нейтив компоненты для обработки чего-нить быстрого (звук/картинки/видео). Заменить слово C# например на Python и ничего не поменяется, абсолютно. C# это клей, полный аналог VB конца 90-х по своему назначению, и плз, не надо его пихать в десктопы, точнее у вас ничего не выйдет, т.к. вы десктопы на C# не пишете, если вы разумны или у вас разумный руководитель.
Это какая трава так торкает?

Вы вообще-то не завбывайте что объем программ пишущихся под дексктопы в разы меньше объема enterprise и web софта.

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

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

G>>Выразительность языка заключается не в возможности решить задачу, в читаемости, поддерживаемости и расширяемости этого решения. (это упрощенно)

E>Если я верно понял, тебе хочется уметь проверять есть ли в строке не менее трёх слов подряд, упорядоченных по алфавиту?
E>Так? IMHO, это просто, понятно и поддерживаемо записывается на ЛЮБОМ АЛГОРИТМИЧЕСКОМ ЯЗЫКЕ...
Ну тогда решение на BF и Delphi в студию.

E>Ну, во всяком случае теми, кто умеет программировать...
Разница познается в сравнении.

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

C>>Вы глубоко заблуждаетесь. Лучший тому пример — Microsoft Blend, и AutoCAD, последних версий.
A>Про AutoCAD это еще кто заблуждается:

Интерфейс AutoCAD 2009 написан на WPF (.NET). Не так давно обсуждалось.

Это к слову о "пластилиновости интерфейсов дотнет", как опровержение. И, кстати, для С++ нет аналогов WPF. Так что будущее десктоп софта под Windows таки за дотнет.

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

C>>2 секунды на форму? Дело точно не в .NET.
Х>а может и в .NET, я не профайлил, знаете почему? потому что nobody care
Вот она — истина.
Во всем софте так — или есть проблемы и они исправляются (иначе конкуретны выдавят),
или эти проблемы никого не волнуют, значит это и не проблемы даже.

Быстродействие софта мало кого волнует, лишь бы visual feedback был адекватный.

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

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

E>>>Нет, ну если ты настаиваешь, что быстрый код ОБЯЗАН БЫТЬ ненадёжным и некрасивым, то да, нет...
G>>Если вы изначально занимаетесь быстротой кода, то вряд ли он будет нажедным и красивым. Наоборот — вполне.
E>Это всего лишь твоё неумение писать быстрый и качественный код...
С чего ты взял?

E>Мне известны МНОГОЧИСЛЕННЫЕ контрпримеры, так что позволь не поверить твоему голословному утверждению...
Уууу, а сколько мне известно примеров когда наступала попа из-за преждевременной оптимизации и раннего проектирования структур данных...
И когда последний раз меня пытались поставить на путь проектирования структур я долго капал на мозг начальству что это неправильно.
В итоге все работало быстрее, чем предполагалось.

G>>Я не предлагал C использовать для красивого кода.
E>Я понимаю. То есть ты предлагал делать быстрый код некрасивой и ненадёжной помойкой?
Быстры и красивый быввает очень редко. Это он может казаться красивым пока не надро какую-то мелочь поменять.

E>А зачем? Потому, что С++ освоить не можешь (эта фраза обозначает тоже самое, что и фраза: "С++ слишком сложный") , или какие-то другие причины?
С чего ты взял что я не знаю С++?

G>>Ты как-то очеь интересно говоришь о том что C# позоляет писать хороший код с малыми затратами.
E>Не хороший, а приемлемый для индусов... Тормозной и прожорливый по памяти А для "нагруженных частей" С -- так у тебя ведь выходит?
Приемлимый для индуксов и хорошый для нормальных программистов.
Ну ты достал, вот покажи где .NET тормозной?
Я модуль на C использовал там где нужна была математика, решил не писат на C# и взять готовый код и слкга допилить под свои нужды.
А "нагруженные части" — те которые обрабатывают большой объем информации в единицу времени — для них C# подходит гораздо лучше.

G>>Когда вместо индусов пишут нормальные программисты код у них получается гораздо лучше и быстрее, чем на С++.
E>Про "лучше" -- не ясны критерии, про быстрее — не верю.
Меньше ошибок, меньше кода, проще модифицировать.
Насчет быстрее можешь не верить, но современные языки спокойно сокращают в несколько раз время разработи по сравнению с C++.

G>>И только там где не хватает производительности может быть использован C.
E>Ну вот есть такая т. з., что в случае массового потребителя, производительности не хватает практически ВЕЗДЕ. Ну ценят люди скорость...
Да ну, а ты не слышал что процессор настолького компа в среднем загружен на 5%, а сервера — на 20%
На C имеет смысл писать только математику, обработка больших объемов данных гораздо лучше пишется на .NET.

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

G>Ну тогда решение на BF и Delphi в студию.
1) Я не считаю BF, asm, а так же и язык машины Тбюринга алгоритмическими...
2) Delphi я не помню совсем, но немного помню ещё PASCAL, наверное. Во всяком случае недавно что-то на нём правил. Но я пока не понял задачу. Уточни таки, а?
Хотя мне проще было бы на C/С++, конечно написать...

E>>Ну, во всяком случае теми, кто умеет программировать...
G>Разница познается в сравнении.

IMHO, разницы принципиальной нет. Хотя, возможно, я не понял задачу.

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

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

Х>>> Качественного десктопного софта на C# нет.

M>>С одной стороны виноват тот же С++. Потому что legacy и тот же ворд нет смысла переписывать с нуля
M>>С другой стороны — а что такое десктопный софт?

H>Гуглохром например, и легаси нету и работает на десктопе

У гугла столько ресурсов, что они могуть ОС в машинных кодах написать.
И если им будет надо — напишут.

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

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

G>>Круто, а фабричный метод так изобразите?
E>А зачем в данном случае фабричный метод?..
Действительно, ООП там толком нет, только пародия на него.

E>Но вообще-то возможно и изображу, правда тут надо бы уточнить, что ты понимаешь под "фабричный метод", так как может и изображу, а может и нет...
http://ru.wikipedia.org/wiki/Фабричный_метод_(шаблон_проектирования)

G>>ЗЫ. Передача указателя на стек до добра не доводит, большенство уязвимостей в ПО так и получаются.
E>А как можно было бы такой уязвимостью воспользоваться? Ну, хотя бы, гипотетически? Это же не буфер, а объект на стеке.
Я не говорю что это уязвимость. Это причина появления уязвимостей.
Например есть убрать возможность передавать указатель на стек (или сделать такую передачу безопасной), то многих уязвимостей переполнения буфера просто не появится. В managed языках как раз такой возможности нету.
И в C++ есть способ безопасной передачи указателя на стек — ссылки называется. Только на ссылках вообще ООП не сделаешь.

E>Про то, что в больших программах 99% кода достаточно глубоко запрятаны для того, чтобы не смочь породить уязвимость, я и не говорю..

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

A>Справедливости ради надо сказать, что пост там про AutoCAD2008. Но вряд-ли AutoCAD2009 что-то изменилось кардинально.
A>Так что AutoCAD из списка С# приложений вычеркивайте
Офигеть

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

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

C>>>Вы глубоко заблуждаетесь. Лучший тому пример — Microsoft Blend, и AutoCAD, последних версий.
A>>Про AutoCAD это еще кто заблуждается:

C>Интерфейс AutoCAD 2009 написан на WPF (.NET). Не так давно обсуждалось.
Почитал ветку. Ну так и правильно, GUI на С++ писать/поддерживать — это overkill, кто бы спорил. Но потроха-то там на c++ как были, так и остались. Из этого следует, то что тут неоднократно утверждалось — каждой задаче свой инструмент. GUI — С#, core — С++

Алексей

Hi criosray

C>Так что будущее десктоп софта под Windows таки за дотнет.

Где-то это я уже слышал.

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

A>GUI — С#, core — С++
надо разработчикам blend это рассказать, а то они не знают.

А что такое core ?

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

VD>>А если серьезно, то уровень дискуссии действительно просто супер. Плинтус горами покажется.
WH>Угу. Люди не знающие .НЕТ против людей не знающих С++.
WH>Смешно читать и тех и других.

Не только, люди ещё специализируются на разных направлениях.

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

G>Действительно, ООП там толком нет, только пародия на него.
По существу замечание, однако...
Вообще-то на ООП свет клином не сошёлся. И "настоящее ООП" где-то или "пародия на него" обычно не важно...

E>>Но вообще-то возможно и изображу, правда тут надо бы уточнить, что ты понимаешь под "фабричный метод", так как может и изображу, а может и нет...
G>http://ru.wikipedia.org/wiki/Фабричный_метод_(шаблон_проектирования)
Спасибо, я раньше не знал какого рода документацией пользуются в своей работе ХиндиСишники...
Смотри, такой вот код:

struct IOder {
    virtual bool IsInGoodOrder( T left, T right ) const = 0;
    virtual bool IsEqu( T left, T right ) const = 0;
};

class SortBySimilarity : public IOder {
public:
    bool IsInGoodOrder( T left, T right ) const { /*тут реализация*/ }
    bool IsEqu( T left, T right ) const { /*тут реализация*/ }

    //  фабричные методы
    static SortBySimilarity CreateBySimilarityCasesensitive( const T& pattern ) { /*тут реализация*/ }
    static SortBySimilarity CreateBySimilarityCaseinsensitive( const T& pattern ) { /*тут реализация*/ }
}

// использование
void foo( T pattern )
{
    const IOder& order = SortBySimilarity::CreateBySimilarityCasesensitive( pattern );
    data.SortBy( &order );
}

это "фабричный метод" или нет?

G>И в C++ есть способ безопасной передачи указателя на стек — ссылки называется. Только на ссылках вообще ООП не сделаешь.
Выше глянь, повнимательнее..

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

G>Стоит учесть что каждый проход GC в программе на C# очищает вс первое поколение в таком случа и двигание объектов не происходит, то немного исправляет результат в пользу C#, но даже если бы код на C# работал в 2 раза медленее, то он оказался бы в 3 раза быстрее стандартного аллокатора для C++.

И вот таки да, предположим у нас получилость так, что из-за частых выделений/освобождений памяти наш продукт на С++ работает недопустимо медленно. Что можно с этим сделать? Для начала собрать профиль размеров выделяемых блоков, который нам покажет, что большинство выделяемых блоков имеют размер 256 байт. А дальше можно сделать например так:

#include <windows.h>
#include <tchar.h>
#include <stdio.h>
#include <assert.h>

const size_t block_size = 256;
const int pool_size = 1000;

char * pool;
bool * allocated;

void * operator new[](size_t size) {
    if(size > block_size)
        return malloc(size);

    if(!pool) {
        pool = (char*)malloc(pool_size * block_size);
        allocated = (bool*)malloc(pool_size * sizeof(allocated[0]));
        memset(allocated, 0, pool_size * sizeof(allocated[0]));
    }

    for(int i = 0; i < pool_size; ++i) {
        if(!allocated[i]) {
            allocated[i] = true;
            return pool + block_size * i;
        }
    }

    return malloc(size);
}

void operator delete[](void * mem) {
    char * mem_ch = (char*) mem;

    if(mem_ch < pool || mem_ch >= (pool + pool_size * block_size))
        return free(mem);

    size_t diff = mem_ch - pool;
    assert(diff % block_size == 0);
    int block_num = diff / block_size;
    assert(block_num < pool_size);
    allocated[block_num] = false;
}

int _tmain(int argc, _TCHAR* argv[])
{
    DWORD ticks = GetTickCount();

    for(int i=0; i<1000000; i++)
    {        
        int* arr = new int[64];
        delete [] arr;
    }

    printf("%d", GetTickCount() - ticks);
    getchar();
    return 0;
}

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

Что Вы будете делать с продуктом на С#? Судорожно тыкать в разных местах gc.collect? Срочно переписывать куски кода с использованием структур?

P. S. Я понимаю, что наверняка любители писать свои менеджеры памяти сейчас найдут в моём коде, который был написан за 20 минут, и не тестировался на реальных приложениях, тысячи багов, косяков, неоптимальностей и т. д. Суть этого примера в том, чтобы показать, что есть пути решения проблемы, которые можно успешно применять.