FreeBSD переходит на GCC 3.4.6

> не знаю, не знаю, вот gcc 3.4.6 не может собрать FBreader,- куча
> ошибок c std::string, о чем есть соответ. багрепорты
GCC 3.4.x много чего собрать не может, как правило из-за своеобразного крепления ручек к телам авторов поделок. Про FBreader не знаю, поделись ссылкой на багрепорты.

> 4.99.10 еще не существует:) 4.99.1 это как раз последний current

dmesg на http://ianzag.megasignal.com/ "Mission impossible"? :)

ps: последний NetBSD-curent - это как минимум .23, думаю, уже выше [завтра проверю как соберется]. а вот 3.99.1 - это как раз самый первый -current :)

// wbr

обрати внимание на мажорную цифру:)

> обрати внимание на мажорную цифру:)

hm.. ну разве что отметили 4.x бранч [AFAIR уже сделали] :) ладно, завтра посмотрим..

// wbr

Как им не стыдно юзать GPL внутри BSD?

> не знаю, не знаю, вот gcc 3.4.6 не может собрать FBreader,- куча > ошибок c std::string, о чем есть соответ. багрепорты

Это проблема не gcc, а неумения афффторов писать на С++. Потому как это ламенство не знать того, что std - это namespace, которое надо либо включать полностью посредством using namespace std; либо указанием using std::string;

> FreeBSD переходит на GCC

FreeBSD переходит на GPL? Так держать! :)

>> FreeBSD переходит на GCC

>FreeBSD переходит на GPL? Так держать! :)

Анонимус, wake up, во FreeBSD всю жизнь использовался компилятор gcc.

> > не знаю, не знаю, вот gcc 3.4.6 не может собрать FBreader,- куча > ошибок c std::string, о чем есть соответ. багрепорты

> Это проблема не gcc, а неумения афффторов писать на С++. Потому как это ламенство не знать того, что std - это namespace, которое надо либо включать полностью посредством using namespace std; либо указанием using std::string;

Во-во, понапишут программ такие вот пейсатели, а потом появляются лозунги "32-ядерный Интель в каждый десктоп".. и ложки серебряные пропадают... Лучше бы на Жабе писали.

>Лучше бы на Жабе писали.

Судя по всему, придется ставить 64-ядерный проц.

Не вопрос, Ниагара уже на подходе, да и для Жабы то родная среда.

это, ты типа свои знания в C++ показал, что ли? если ты не знал, можно писать и так,-

... std::string str; str = "string"; ...

, без использования директивы using

> Это проблема не gcc, а неумения афффторов писать на С++. Потому как это ламенство не знать того, что std - это namespace, которое надо либо включать полностью посредством using namespace std; либо указанием using std::string;

или же, все-таки как белые люди, "std::string s;" а за использование директивы using расстреливать на месте без суда и следствия :-/

// wbr

а чего не на icc? непорядок! :))

:-/ А тех еще кто добавляет using в header shared-библиотек надо бить ногами очень сильно, потому как еще другим отравляют жизнь!

>:-/ А тех еще кто добавляет using в header shared-библиотек надо бить ногами очень сильно, потому как еще другим отравляют жизнь!

Shared-библиотеки, вообще-то, должны использовать не STL-типы, а POD.

То есть, вместо Somefunc(const std::string & s); Somefunc(const char * c);

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

> Shared-библиотеки, вообще-то, должны использовать не STL-типы, а POD.
То есть, вместо Somefunc(const std::string & s); Somefunc(const char * c); Потому как иначе, при сборке с другой реализацией STL, все либо не соберется, либо работать не будет.

"понял, отстал" (c) FIDO

// wbr

>это, ты типа свои знания в C++ показал, что ли? если ты не знал, 
можно писать и так,- ... std::string str; str = "string"; ... , без 
использования директивы using


Можно и презерватив на глобус натянуть, ага.

Еще можно писать в таком вот стиле:

std::string key, value;
std::map<std::string, std::string> m;
m.insert(std::pair<std::string, std::string>(key, value));

Вместо того, чтобы в начале логического блока написать
{
   using std::string;
   using std::map;
   using std::pair;
  
   string key, value;
   m.insert(pair<string, string>(key, value));
}

>> Это проблема не gcc, а неумения афффторов писать на С++. Потому как это ламенство не знать того, что std - это namespace, которое надо либо включать полностью посредством using namespace std; либо указанием using std::string;

> или же, все-таки как белые люди, "std::string s;" а за использование директивы using расстреливать на месте без суда и следствия :-/

После такихтопиков, начинай считать, что за использование си++ надо расстреливать на месте без суда и следствия...

+1. Асм и С - наше фсио.

Ясен пень!

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

Я тогда еже не знаю, что надо делать после топиков про то, как это классно - писать на ЯП, где не надо декларировать переменные перед их использованием....

Чтобы каждый потом изобретал строки или копировал память ? Если есть договоренности, что нужно использовать конкретный STL, то почему бы не использовать ? А char* это для С программистов. Объекты наше все! Хотя откровенно говоря реализация std::string больше похож на процедурное программирование, чем на ООП :)

И если еще вспомнить про параметр с char* - я даже боюсь себе представить сколько раз потом на нем вызовут strlen и пробегутся по памяти, вместо использования std::string.size()

>Чтобы каждый потом изобретал строки или копировал память ? Если есть договоренности, что нужно использовать конкретный STL, то почему бы не использовать ? А char* это для С программистов. Объекты наше все! Хотя откровенно говоря реализация std::string больше похож на процедурное программирование, чем на ООП :)

char * - это для переносимости. Почитайте того же Александреску о проектировании интерфейсов.

Если есть договоренность использовать конкретный STL, то, конечно же, нет смысла пользоваться POD.

>И если еще вспомнить про параметр с char* - я даже боюсь себе представить сколько раз потом на нем вызовут strlen и пробегутся по памяти, вместо использования std::string.size()

Ну, во-первых, можно передавать не char *, а (char *, int). А во-вторых, ничто не мешает сразу после передачи библиотечной функции char * сделать из него std::string s(szCharData);

> А во-вторых, ничто не мешает сразу после передачи библиотечной функции
> char * сделать из него std::string s(szCharData);
Мещает, точнее - душит. Жаба :)

std::string(szCharData) будет равно strcpy() и соотвественно подобие strlen :)

>std::string(szCharData) будет равно strcpy() и соотвественно подобие strlen :)

Будет. Но - один раз, только при вызове конструктора.

Внутри библиотеки никакого strlen уже не будет.

но будет-же :) потом-то понятно...

лучше пользоваться typedef,-

typedef std::string String; String key, value; std::map<String, String> m; m.insert(std::pair<String, String>(key, value));

Почему лучше,- (выше уже писали) нехорошо писать using в заголовках, а typedef,- пожалуйста

так что asm и C++,- наше все

блин, опять в одну строку получилось
короче вот так нужно:


typedef std::string String;
String key, value;
std::map<String, String> m;
m.insert(std::pair<String, String>(key, value));

Да, можно; причем лучше вынести все эти определения в отдельный файл:

namespace XXXYYY
{
typedef std::string String; 
.....
}

----

#include "STLTypes.hpp"

...
...
...

> так что asm и C++,- наше все

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

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

дык не у всех же ... а потом, естественный отбор не повредит ;)