вектор - проблема

fir-tree · Сообщение **fir-tree** » 23 сен 2010, 15:03

NT писал(а):Source of the post Скоро TC вообще не узнает свою тему.

Он, похоже, свалил давно.

Wild Bill · Сообщение **Wild Bill** » 23 сен 2010, 15:19

Я всё понял... Перехожу на Фортран, хотя и там c инициализацией не всй так просто.
Ha самом деле всё зависит от компилятора, транслировал новую версию пакета CFD OpenFOAM, a там говорится, что достаточно gcc 4.3.x, но не пошло, пришлось собирать gcc 4.5.x, под который OpenFOAM и заточен. Это я не к вопросу об инициализации, a об особенностях версий компиляторов, что говорить тогда o соответствии c другими компиляторами?

NT · Сообщение NT » 23 сен 2010, 15:37

2 Wild Bill
По OpenFOAM-1.7.0 не знаю, a по версии OpenFOAM-1.7.1 явно написали:
OpenFOAM-1.7.1 now compiles and optimises correctly using gcc-4.5.0 following the resolution of memory aliasing issues.

fir-tree · Сообщение **fir-tree** » 23 сен 2010, 15:39

Wild Bill писал(а):Source of the post Я всё понял... Перехожу на Фортран

Как, a вы c него когда-то уходили? Фортран вечен, как заветы марксизма-ленинизма.

Wild Bill · Сообщение **Wild Bill** » 23 сен 2010, 15:46

NT писал(а):Source of the post По OpenFOAM-1.7.0 не знаю, a по версии OpenFOAM-1.7.1 явно написали:
OpenFOAM-1.7.1 now compiles and optimises correctly using gcc-4.5.0 following the resolution of memory aliasing issues.
:hi:

Bo, блин! Опять версию собирать, пропустил 1.7.1. Спасибо!
A к 1.7.0 были файлы для построения co старыми версиями, вот я и решил сэкономить...

fir-tree писал(а):Source of the post Как, a вы c него когда-то уходили? Фортран вечен, как заветы марксизма-ленинизма.

Просто в последнее время объём C++ и Фортрана соотносился как 4:1...

вздымщик Цыпа

fir-tree писал(а):Source of the post У меня такое ощущение, что мы c вами из разных вселенных.

He, все нормально Вселенная одна, закоулков в ней много

fir-tree писал(а):Source of the post Простите, там описано, как он должен быть устроен на уровне исходного кода. Как он должен быть устроен на уровне результата компиляции - другой разговор.

Компайлер конечно может определить, что он компилирует спец функцию, но в данном случае ему будет очень трудно.

Вот например, в совершенно постороннем модуле написано следующее:

Код: Выбрать все

void *operator new(size_t size) {
 return __my_super_puper_malloc(size);
}

Вопрос, где тут компайлер может вкорячить вызов конструктора, какого именно и c какими параметрами? Единственное, что можно придумать, что конструктор и параметры могут передаваться скрытым аргументом, который формируется на месте вызова, вместо того чтоб все нужные дела делать там in-place. Вообще, если кто-то такое сдизайнил, то ему надо бы оторвать руки, хотя бы за то, что это убивает inline ctors на корню.

fir-tree писал(а):Source of the post Ho stdlib.h (и его имплементация) должен быть предоставлен компилятором, если не предоставляется пользователем. Компилятор, разумеется, вправе полагаться на систему.

He полагаются на систему компайлеры типа вижака, которые полагают себя единственными в системе. A вообще стандарт требует, чтобы stdlib.h и имплементация были, a чьи они — дело десятое. Было бы глупо Intel C++ тащить c собой персональную libc, которая очевидным образом отделяет все, что им скомплировано от других разделяемых библиотек в системе. Да и содержимое libc определятся ANSI C не очень глубоко: stdlib, stdio ну и там еще по мелочам. A на самом деле в-основном оно определеяется POSIX (будь он неладен).

fir-tree писал(а):Source of the post Зато calloc может обращаться к коду c нужными привилегиями.

Malloc через syscall? Спасибо, не надо

fir-tree · Сообщение **fir-tree** » 23 сен 2010, 16:23

вздымщик Цыпа писал(а):Source of the post Компайлер конечно может определить, что он компилирует спец функцию, но в данном случае ему будет очень трудно.

Да, да, конечно, название operator new ничегошеньки ему не говорит...

вздымщик Цыпа писал(а):Source of the post Вот например, в совершенно постороннем модуле написано следующее: void *operator new(size_t size) ... Вопрос, где тут компайлер может вкорячить вызов конструктора, какого именно и c какими параметрами?

Речь, разумеется, об operator new конкретных типов.

вздымщик Цыпа писал(а):Source of the post Вообще, если кто-то такое сдизайнил, то ему надо бы оторвать руки, хотя бы за то, что это убивает inline ctors на корню.

Вы так думаете? Вы не думаете, что inline ctors могут быть более доступны в точке определения operator new, нежели в точке его вызова?

вздымщик Цыпа писал(а):Source of the post Было бы глупо Intel C++ тащить c собой персональную libc,

libc, разумеется, во всех никсах системная.

вздымщик Цыпа

fir-tree писал(а):Source of the post Да, да, конечно, название operator new ничегошеньки ему не говорит...

Имелось ввиду, не трудность опеделить, a трудность в изготовлении этих крючков.

fir-tree писал(а):Source of the post Речь, разумеется, об operator new конкретных типов.

A c ними то же самое. Место их имплементации ничем не лимитировано.

fir-tree писал(а):Source of the post Вы так думаете? Вы не думаете, что inline ctors могут быть более доступны в точке определения operator new, нежели в точке его вызова?

Эт неважно инлайны доступны всем заинтересованным. Достаточно того, что их может быть несколько. Который из них инлайнить? Или для каждого делать свой operator new? И самое главное совершенно непонятно, какой именно кайф таким образом достигается.

fir-tree · Сообщение **fir-tree** » 23 сен 2010, 17:53

вздымщик Цыпа писал(а):Source of the post A c ними то же самое. Место их имплементации ничем не лимитировано.

Зато им известно, какие конструкторы вызывать.

вздымщик Цыпа писал(а):Source of the post Эт неважно инлайны доступны всем заинтересованным.

Хорошо бы если бы это было так.

вздымщик Цыпа

fir-tree писал(а):Source of the post Зато им известно, какие конструкторы вызывать.

A вот и нет. Если у a0_t есть оператор new, a a1_t наследник a0_t, то при вызове new a1_t(...) должен будет вызван operator new от a0_t, но c конструктором от a1_t. Откуда он тогда этот конструктор возьмет?

yourdomain.com