» хочу начать учить с++

ironwit

Цитата:

подробнее или урлы

Копни на google/yandex - информации уйма!
Вот тебе ссылка на корневую страницу COM из MSDN - http://www.microsoft.com/com/

dremon

Цитата:

Надо сразу с STL и iostream начинать.

А поподробнее? Вы ведь все таки с чайником общаетесь

dremon

Цитата:

А вот этого не надо Надо сразу с STL и iostream начинать.

iostream нужно понимать и уметь пользовать, но вот использовать лучше stdio. и удобнее и быстрее и безопаснее.

WTL - это Windows Template Library.
с ATL и STL (соответственно ActiveX Template Library и Standard Template Library),
то я думаю, ее можно использовать.
ATL и STL грамотно написаны и удобны.
Я думаю WTL это альтернатива MFC.

взял на одном форуме. Оно?

Цитата:

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

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


Цитата:

Я думаю WTL это альтернатива MFC

WTL похоже заглохла как проект.

dremon

Цитата:

Насчет удобства и безопасности - как раз все наоборот

Да, пожалуй удобство, дело сугубо индивидуальное. А безопасность... Пока что, библиотека iostream под всеми платформами содержит огромное количество багов и проблем с многопоточностью.
Вот пример кода, который имеет как пробемы с потоками так и со скоростью:


Код:
cout<<1<<2<<3<<4<<endl;

ironwit

Цитата:

Оно?

Угу

Ryback

Цитата:

iostream нужно понимать и уметь пользовать, но вот использовать лучше stdio. и удобнее и быстрее и безопаснее

Да. Перед использованием STL сначала надо понять, как вообще работают шаблоны в C++ (лучше Страуструпа это еще никто не расписал). И учесть, что есть много реализаций STL - SGI/HP/MS/STLPort. Но это уже частное.

После этого к stdio возврата уже не будет - STL удобнее и безопаснее, правда медленнее. Начинать надо с stdio - так проще, хотя сам Страуструп этого и не рекомендует

Ryback

Цитата:

А с каких это пор коммерческая оценка продукта влияет на его функциональность? И почему в таком случае ты VC не трогаешь? Или сам занисаешься коммерческой разработкой именно под ним и с использованием коммерческого софта, такого как Oracle/mssql/прочее?

Да, я занимаюсь коммерческим программированием, но при этом если есть альтернатива между платным и бесплатным soft, то буду выбирать именно бесплатный. Тому есть несколько причин:
1. снижается общая стоимость моего продукта
2. зачастую у бесплатных прог открыт исходный код, что дает возможность лучше выявлять его ошибки и ставить обновления

Добавлено
Ryback

Цитата:

Да, пожалуй удобство, дело сугубо индивидуальное. А безопасность... Пока что, библиотека iostream под всеми платформами содержит огромное количество багов и проблем с многопоточностью

А как же STLPort? Поставь - посмотри. Мутексов и критических секций в работе с ним никто не отменял, но он нормально работает в потоковых приложениях и позволяет спокойно передавать данные из exe в dll и обратно.

Bloody_Nokia_Adept

Цитата:

Да, я занимаюсь коммерческим программированием, но при этом если есть альтернатива между платным и бесплатным soft, то буду выбирать именно бесплатный. Тому есть несколько причин:
1. снижается общая стоимость моего продукта
2. зачастую у бесплатных прог открыт исходный код, что дает возможность лучше выявлять его ошибки и ставить обновления

1. По-моему, в проекте надо использовать, то, что лучше всего подходит и соответсвует требованиям.
Возвращаясь к тем же orb - тебе нужен event или transaction service, ты же не будешь их сам писать для omniorb?
2. Бесплатное не значит открытое. Да и как часто ты выявлял ошибки в чужих системах?

Bloody_Nokia_Adept

Цитата:

Меня конечно забросают камнями, но Borland - тупиковая линейка продуктов

Однозначно! (в смысле второе )

Ryback

Цитата:

даже простому MySQL/mSQL
все таки не стоит их ставить в одну категорию.

Стоит! По меньшей мере первую.
Посмотри сюда:
http://www.eweek.com/article2/0,3959,293,00.asp
http://www.eweek.com/slideshow/0,3018,sid=0&s=1590&a=23120,00.asp
MySQL наступает на пятки Ораклу(!)

klau

Цитата:

А как насчет .NET? Кто-нибудь считает что у данной платформя есть будушее? Сказали что она очень сильно отличаетcя от 6.0

Да отличается. Я не мацал ее. Но думаю будущее есть в любом случае, хотя бы потому что билли грохнул в нее слишком много бабок. Если оно стоящее - замечательно. Если нет - оно продолжит ряд преуспевающих разочарований типа Visual Basic, ActiveX, MSSQL итд.

dremon

Цитата:

А вот этого не надо Надо сразу с STL и iostream начинать.

Аргументы в студию!
ПМСМ, надо начинать как раз с stdio, stdlib ну и вообще с того, что в *никсах я называю libc

Ryback

Цитата:

Возвращаясь к тем же orb - тебе нужен event или transaction service, ты же не будешь их сам писать для omniorb?

Разумеется нет - если это кем-то было создано ранее и нормально себя зарекомендовало, то стоит использовать


Цитата:

Бесплатное не значит открытое

Угу


Цитата:

Да и как часто ты выявлял ошибки в чужих системах?

Нечасто
Только в тех, с которыми приходилось плотно работать. Об исправлении правда речи не шло.

Bloody_Nokia_Adept

Цитата:

позволяет спокойно передавать данные из exe в dll и обратно

фантастика

Добавлено
mymuss

Цитата:

Стоит! По меньшей мере первую.

я имел в виду сравнение MySQL/msql

mymuss

Цитата:

MySQL наступает на пятки Ораклу(!)

Это выходит за рамки темы, но все же... Далековато еще до пяток оракла
Нет:
1. триггеров
2. хранимых процедур
3. сравнимой масштабируемости
4. отказоустойчивости

Часть из перечисленного появится в версии 5, но как это будет реализовано еще не известно. Вот... Я сам АБД и работаю с Oracle9i и MS SQL 2000. Дома разворачивал MySQL 4 - смотрл сравнивал. Есть вещи более удобные, но далеко ему еще до оракла.

Если ставить базу не корпоративного уровня, то MySQL потянет

Bloody_Nokia_Adept

Цитата:

Разумеется нет - если это кем-то было создано ранее и нормально себя зарекомендовало, то стоит использовать

ты не понял. этих сервисов нет у omniorb. а они тебе нужны. вот и прийдется выбирать что-то другое. например orbit.

Bloody_Nokia_Adept

Цитата:

Нет:
1. триггеров
2. хранимых процедур

Кажется, уже в 4.1 будут. Вместе с сабселектами.


Цитата:

3. сравнимой масштабируемости
4. отказоустойчивости

Это почему же?


Цитата:

Есть вещи более удобные, но далеко ему еще до оракла.

Но цена! Цена!!! Да и я в общем-то имелл в виду большу производительность

Bloody_Nokia_Adept

Цитата:

4. отказоустойчивости

Ну, зачем нужна она ораклу - понятно - по крайней мере, mysql-4.1-alpha ( _alpha_ !) не падает от запросов

Код:
SELECT TO_TIMESTAMP_TZ('2003-02-016 12:00:00 -8:00','- some long string -') FROM DUAL;

klau
mymuss
Я попробовал .NET, мне понравилось. Одно большое НО. Если программировать на нем - лучше использовать C#. На С++ этот процесс содержит избыточное количество геморроя. Кроме того мне все еще диковато, что динамически объект создаю, а удалять его не надо - сам исчезнет.
А в целом очень занятная печенюшка. Существенно удобнее чем MFC etc.

mymuss

Цитата:

Аргументы в студию!
ПМСМ, надо начинать как раз с stdio, stdlib ну и вообще с того, что в *никсах я называю libc

Ты тогда выучишь язык C. И будешь писать программы на C++ в стиле C - в функциональном стиле. Методика, которая хороша для написания дров и кернела, для прикладного программирования и тем более для обучения не очень подходит.

У C++ есть стандартная библиотека, совершенно независимая от LIBC. Она называется STL и iostreams. stdio и LIBC - это стандартные библиотеки языка C.

Добавлено
Ryback

Цитата:

Вот пример кода, который имеет как пробемы с потоками так и со скоростью:
Код:
cout<<1<<2<<3<<4<<endl;
а вот пример который быстрее и не требует синхронизации в многопоточном приложении:
Код:
fprintf(stdout, "%d%d%d%d\n", 1, 2, 3, 4);

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

Вот тебе другой пример:

char buf[255];
scanf("%s", buf);

и второй вариант:
std::string buf;
std::cin >> buf;

Еще пример (с ошибкой):
char *buf = "Hello, world!";
printf("%s", &buf); // из-за лишнего & программа даст runtime ошибку.

string buf = "Hello, world!";
std::cout << buf; // ошибиться просто невозможно.

какой из них нагляднее для чтения, безопаснее и понятнее?
Вообще использование переменного числа параметров - это очень опасная вещь. Забудешь в спецификации к printf/scanf поставить значок % (или что-нибудь типа этого) - и все, большие шансы что твое приложение накроется. Ищи потом ошибку.

dremon

Цитата:

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

Почему же, стоит. Сколько вызовов функций происходит в первом примере? А во втором? Или мы быстродейсвие на глаз оцениваем?


Цитата:

Вот тебе другой пример:

char buf[255];
scanf("%s", buf);

Стоп, писать программы с ошибками и приводить их в качестве примера???
scanf("%254s", buf);


Цитата:

Еще пример (с ошибкой):
char *buf = "Hello, world!";
printf("%s", &buf); // из-за лишнего & программа даст runtime ошибку.

вывод моего компилятора:


Цитата:

/home/voodoo/test.cc: In function `int main()':
/home/voodoo/test.cc:6: warning: char format, pointer arg (arg 2)

Уважаемый, кто вам доктор, что вы не можете правильно пользовать stdio? Если вы забывете ставить проценты или лепите лишний &, то ошибки будут в программе на любом языке.

Ryback

Цитата:

вывод моего компилятора

Как оказалось VC++ не делает таких проверок

dremon

Цитата:

char buf[255];
scanf("%s", buf);

Действительно, зачем провоцировать переполнение буфера?
Согласен с тем, что stl в данном случае удобнее - все проверки перекладываем на него.

Mickey_from_nsk
mymuss

Да, но использовать его только для c# не очень выгодно. Получается что продукт работает на 20% своей мощности. Скажем, скоро появится с++билдер с поддержкой для с# - если нужно только с шарп, то можно его т.к. легче.
В НЕТе воде как можно создать универсальные приложения (часть на шарпе, часть на джаве, часть на с++) и это должно работать. Не говорю о том, что этот список возможных частей будет расширяться.

Цитата:

Сколько вызовов функций происходит в первом примере? А во втором? Или мы быстродейсвие на глаз оцениваем?

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

Цитата:

Стоп, писать программы с ошибками и приводить их в качестве примера???

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


Цитата:

вывод моего компилятора:

Вот блин, далась тебе эта stdio-библиотека!
Ну хорошо - замени строку "%s" на strFormatSpec, а эту переменную инициализируй в другом модуле.
Посмотрим, что скажет твой компилятор. Вообще на его сообщения полагаются только новички и писать программу не думая, надеясь что умный компилятор обо всем предупредит - это уровень детского сада.

Добавлено
Ryback, здесь вообще разговор идет о C++, а не о C и stdio. А то уже в соседней теме один человек посоветовал инициализировать массив объектов вызовом memset, тоже упирая на быстродействие.
Еще раз скажу - LIBC имеет отношение к C++ не более, чем MFC или ATL. Читайте стандарт языка и не давайте глупых советов.

dremon

Цитата:

Кто же это оценивает быстродействие по количеству вызываемых функций?

в случае если есть функция, которая записывет один символ и вызывается 5 раз и есть функция, записывающая 5 символов сразу. одинаковым способом. что быстрее? мы же не сравниваем fork() и puts(), мы сравниваем одинаковые по выполняемым действиям вещи.


Цитата:

Я могу написать программу, в которой вообще не будет ни одной функции, но которая будет очень сильно тормозит

и не сомневаюсь


Цитата:

Мы говорим о надежности и безопасности. Ошибки времени выполнения имеют к этой теме прямое отношение.

то есть ты можешь забыть как передавать в printf строку, но не забыть облепить критическими секциями/мутексами std::<<cout<<.... заботясь о том чтобы каждая строка в программе выполнялась на одном потоке, таким образом создавая шедевры прграммирования?
монстр.

в догонку.

Код:
std::string buf = "Hello, world!";
std::cout << &buf << endl;

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

Цитата:

то есть ты можешь забыть как передавать в printf строку, но не забыть облепить критическими секциями/мутексами std::<<cout<<.... заботясь о том чтобы каждая строка в программе выполнялась на одном потоке, таким образом создавая шедевры прграммирования?

Это вообще без комментариев.

Цитата:

Этот код делает то, что ты хотел от него?

Этот код не вызовет сбой в работе программы, а напечатает точно то, что ты хочешь напечатать - адрес переменной buf. В случае stdio ты хочешь сделать одно, а делаешь другое. Почувствуй разницу.

Цитата:

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

Я тебе про Фому, а ты мне про Ерему. Обращай внимание на сообщения компилятора, они для этого и нужны. но я тебе уже привел пример, когда твой любимый gcc тихо промолчал. Профессионалы не делают глупых ошибок. На то они и профессионалы с опытом работы.


Добавлено
Ryback, ты почему-то упорно стараешься доказать, что бесконтрольность и слабая типизация C-стиля лучше, чем сильная типизация C++-стиля, приводя в качестве аргумента высосанную из пальца производительность функции fprintf и непонятные фразы про многопоточные проблемы в библиотеке iostream. Это выглядит просто нелепо и заставляет усомниться в квалификации. Поэтому спорить с тобой я больше не буду.

dremon

Цитата:

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

брррр. Ты что, считать не умеешь? В случае с iostream ты пять раз вызовешь operator<<, который пять раз вызовет функцию печати целого числа. Короче, напиши тест и сравни. Я сравнил, прежде чем постить.


Цитата:

Это вообще без комментариев.

почему же? Я что-то не так написал? Ты сам писал мне про то, что надо пользоваться обьектами синхронизации. Или ты не знаешь к чему приводит их чрезмерное употребление?


Цитата:

Этот код не вызовет сбой в работе программы, а напечатает точно то, что ты хочешь напечатать - адрес
переменной buf. В случае stdio ты хочешь сделать одно, а делаешь другое. Почувствуй разницу.

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


Цитата:

Профессионалы не делают глупых ошибок. На то они и профессионалы с опытом работы.

ой. а что же тогда было в твоих примерах, как не глупые ошибки?

Ладно. Постараемся подвести итоги.
1. stdio быстрее
2. stdio надежнее с точки зрения многопоточных программ
3. stdio чревато глупыми ошибками
4. использование iostream в большой программе только загромождает код





Добавлено
dremon


Цитата:

Ryback, ты почему-то упорно стараешься доказать, что бесконтрольность и слабая типизация C-стиля лучше, чем сильная типизация C++-стиля, приводя в качестве аргумента высосанную из пальца производительность функции fprintf и непонятные фразы про многопоточные проблемы в библиотеке iostream. Это выглядит просто нелепо и заставляет усомниться в квалификации. Поэтому спорить с тобой я больше не буду.

Да уж, хватит. Последней фразой ты лишь подтвердил не знание реализаций C stream library и С++ iostreams, в том числе и в многопоточных приложениях.

Цитата:

брррр. Ты что, считать не умеешь? В случае с iostream ты пять раз вызовешь operator<<, который пять раз вызовет функцию печати целого числа. Короче, напиши тест и сравни. Я сравнил, прежде чем постить

Пусть общественность нас рассудит.

Цитата:

Да уж, хватит. Последней фразой ты лишь подтвердил не знание реализаций C stream library и С++ iostreams, в том числе и в многопоточных приложениях

Ты мне напомнил самого себя лет эдак 6 или 7 назад

dremon

Цитата:

Пусть общественность нас рассудит.

А сам ты тест написать не можешь? Ну тогда - ау, общественность!!


Цитата:

Ты мне напомнил самого себя лет эдак 6 или 7 назад

давай без этого обойдемся.

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

dremon

Цитата:

Пусть общественность нас рассудит

Рассудит...

Я Ryback знаю не один год и работаем с ним вместе. То, что мы тут с ним пофлеймили это был прикол с его стороны (я только потом узнал, кто был за этим ником). С/С++ он знает отменно. Это факт.

Пусть я не согласен с ним в плане удобства пользования stdio/iostream, но то, что он приводил реальные и главное правильные примеры - факт! Все его примеры кода основаны на стандарте, который:
1. гарантирует атомарность операций stdio
2. четко описывает использование iostream

Цитата:

Пусть я не согласен с ним в плане удобства пользования stdio/iostream, но то, что он приводил реальные и главное правильные примеры - факт!

Хорошо. Рассмотрим правильные примеры.
1. Рассмотрим производительность (хоть и это и очень глупо сравнивать производительность консольных или тем более файловых операций на разных библиотеках - они сами по себе медленные). Возьмем этот пример:
printf("%d%d%d%d", 1,2,3,4,5);
cout<<1<<2<<3<<4<<5;
В первом случае библиотечная функция printf займется разбором строки, поиском спецификаций %d, и для каждой такой спецификации в итоге вызовет функцию печати этого числа в стдио. Для непонятливых - смотри реализацию этой функции в исходниках.
Во втором случае 5 раз будет вызвана функция печати числа в стдио.
Еще что-то нужно пояснять в плане производительности?

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


Цитата:

гарантирует атомарность операций stdio

"Я шизею, дорогая редакция". С чего это ты взял, что stdio гарантирует атомарность операций? Каких конкретно операций? fprintf? Ничего подобного.

Цитата:

четко описывает использование iostream

где?


Добавлено
Я могу еще раз сказать то, что уже говорил дважды, но почему-то это было проигнорировано. LIBC - это библиотека для языка C. У него есть свои преимущества и своя ниша. Язык C++ - это другой язык. У него есть своя библиотека, включенная в стандарт языка. Советовать использовать в нем LIBC это все равно, что советовать использовать в нем ассемблерные вставки для увеличения производительности и надежности. Звучит так же нелепо.

dremon

Цитата:

Еще что-то нужно пояснять в плане производительности?

Да не надо ничего пояснять. Ты примеры попробуй. Хотябы с printf() с его разбором шаблонов, не говоря про самые простые, без парсинга, типа fwrite.

Цитата:

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

Я с этим согласен. Да, использование stdio провоцирует глупые ошибки, но "Профессионалы не делают глупых ошибок".



Цитата:

"Я шизею, дорогая редакция". С чего это ты взял, что stdio гарантирует атомарность операций? Каких конкретно операций? fprintf? Ничего подобного.

Не надо только шизеть.
Это из документации на LIBC
"The POSIX standard requires that by default the stream operations are atomic. I.e., issueing two stream operations for the same stream in two threads at the same time will cause the operations to be executed as if they were issued sequentially." Я верю, ибо глядел исходники. И проверял на разных платфрмах.
А это с whitepapers c www.unix.org: "The POSIX.1 and C-language functions that operate on character streams (represented by pointers to objects of type FILE) are required by POSIX.1c to be implemented in such a way that reentrancy is achieved (see ISO/IEC 9945:1-1996, §8.2)."


Цитата:

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

Абсолютно согласен, что C++ другой язык со своей библиотекой. Но какую ты напишешь программу, пользуясь только стандартом 14882? Калькулятор? Не больше. И никуда от GLIBC не денешься, будут у тебя там и pthread_create() и accept() и write(), read(). Так вот, вопрос то, что кому удобнее был сразу закрыт. А вот вопрос производительности один из нас так и не хочет проверить на практике. С многопоточностью вроде как разобрались, или нет?

dremon
Ryback
Bloody_Nokia_Adept
Общественность приперлась, встречайте!

Итак, дабы расставить все точки над i, решил провести маленький тест.
Использовалось: Athlon 1000Mhz, FreeBSD 4.6.2-STABLE, gcc 2.95.3, perl 5.8.0, Benchmark 1.04

Итак!
Мамба намба ван:

Код:
#include <stdio.h>
или
#include <iostream.h>

int main (int argc, char **argv)
{
int i;
fprintf(stdout, "%d%d%d%d\n", 1, 2, 3, 4);
или
cout<<1<<2<<3<<4<<endl;
exit (0);
}