Изучаю boost::pool и решил для общего развития перевести документацию на русский, пример. Встал вопрос о переводе того или иного термина. Например такое предложение:
Forward declarations of all the exposed symbols for this library are in the header made inscope by #include <boost/pool/poolfwd.hpp>.
если перевести буквально:
Опережающие объявления всех доступных из других единиц трансляции (?!) символов библиотеки находятся в заголовочном файле, включаемым с помощью #include <boost/pool/poolfwd.hpp>
Меня смущает слово "опережающие" и перевод терминов exposed и symbol (в данном контексте). Кто что скажет?

Также как лучше перевести the include file guards - страж заголовочного файла?

З.Ы. и ресурс слишком рекламистый, не посоветуете что-либо менее отвлекающее?

drug007, я бы советовал вместо дословного перевода делать смысловой. Такой текст воспринимается намного лучше.


  Опережающее вроде подходит, а вот "всех доступных из других единиц трансляции" мне не понятно даже по русски. exposed, я так понимаю, используется как синоним public .

это лучше не переводить.
к примеру так:



да.


прям на википедии пиши. не? ;)

Это сообщение отредактировал(а) boostcoder - 1.12.2011, 09:23

Согласен на счет смыслового перевода. Но первоначально все равно делаю близко к оригиналу, потом перечитываю и то, что не по-русски переписываю уже своими словами. Кстати, приходится обращать внимание на детали, что помогает самому лучше понять предмет, как в анекдоте - пока вам объяснял, сам уже понял. 
Да, exposed именно в смысле public, но как это красиво перевести на русский? И symbols тут же не в значении "символ", а в смысле "конструкция", скорее всего.

Надо будет попробовать википедию    

Это сообщение отредактировал(а) drug007 - 1.12.2011, 09:27

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


да, конструкция. но лучше оставить символ. в контексте, все равно ничего другого мне в голову не пришло.

Добавлено через 3 минуты и 32 секунды

в поиске вводишь "boost.pool", тебе говорят что такой страницы нет. и там есть красная ссылочка "Создать страницу". имхо, стабильнее и более популярного ресурса для доки не сыскать.

drug007, боюсь что термин symbols слишком специфичен, в литературе часто так и пишут символ. symbol скорее это символьный идентификатор. Тут используется термин symbol в значении линковочных символов, т.е. языковых конструкций, которые попадают в объектный файл в символьном представлении вместо подстановки адреса. 

Тогда сделаю так 'symbol' = "символ".
Что-то вики не дает сохранять изменения - одну страницу сохранил и все. :( Надеюсь это временно.

Хмм... Что-то на вики меня встретили недружелюбно -  статьи пометили как спам. Там можно размещать доки все-таки или нет? Вопрос там этот, конечно , тоже задам.

Что-то с викой не очень дружно получается, но надежды не теряю. По крайней мере перевод делаю и возник такой вопрос (описывается упорядоченный pool, где указатели на свободные блоки памяти хранятся в сортированном по адресам блоков списке):
However, freeing an object can be O(N) in the number of currently free blocks which can be prohibitively expensive in some situations.
Я перевел как:
Тем не менее, освобождение объекта может быть O(N) от текущего числа свободных блоков, которое может быть запредельно дорогим в некоторых ситуациях. 
Вот меня смущает перевод фрагмента "... in the number of currently free blocks..."

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

Это сообщение отредактировал(а) drug007 - 1.12.2011, 14:01

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


так?:
Тем не менее, освобождение объекта может иметь сложность O(N) от текущего числа свободных блоков, которое может быть запредельно дорогим в некоторых ситуациях.


прав.

Вместо википедии тогда уж лучше использовать викиучебник   

Викиучебник мне тоже уже посоветовали на самой вики, но теперь проблема в том, что вики не дает редактировать большие тексты, только буквально 10 предложений. Вчера весь день промучался - при чем эта проблема уже известна на той же вики, но полноценного решения не имеет. Решил пока не потерял запал на перевод заняться самим переводом, а выложить уже потом можно будет.



Например удаленная статья в вики - вообще обвинили в нарушении авторских прав. Чьи права я там нарушил?
А вот сам викиучебник
Но тут все криво, т.к. я еще не очень уверенно работаю в вики + недоступно полноценное редактирование.


Да, сложность как раз нужный термин.


Спасибо за ответы.

бред какой-то %)



нормально. потом "губы наведешь".

drug007, пообщался я с модератором Википедии, и он извинился за то что не внимательно прочитал "Boost Software License", и сказал что страница будет восстановлена. Вот только нужно подать заявку админу. Об этом сейчас и треплюсь.

drug007, в общем, тут описан процесс подачи заявки.

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

Подскажите, как правильнее перевести:
1) Simple segregated storage - Хранилище с простым разделением/разбиением? может какой-то соответствующий устоявшийся термин уже есть?

2) Simple segregated storage addresses both of these issues. Almost all memory overhead is done away with, and all allocations can take place in a small amount of (amortized) constant time. - как здесь перевести amortized - я не совсем понял.

разбиением.


приближенное/устредненное.

Ого, вот это надмозг-стайл.  В мемориз!

Ваши варианты?

http://ru.wikibooks.org/wiki/Boost.Pool

думаю, стОит добавить ссылку на источник.
а вообще, замечательно потрудился!  
на википедии страницу восстановить не желаешь?

зы
раскидаю ссылку по известным мне сборникам переводов.

Спасибо за оценку и за продвижение ссылки! =)
Правда я еще не закончил - у меня проблемы с редактированием, сохраняет результат редактирования даже не через раз, а через 10. Очень много времени уходит на пустое ожидания сохранения результатов. Поэтому все медленно идет. По той же причине пока не планирую восстанавливать страницу на википедии, хотя по идее это будет просто. Пока планирую завершить викиучебник в ближайшее время (как инет дома появится). 


З.Ы. Если держать и в википедии и в викиучебнике - не будет ли лишнего дублирования?

а хз. об этом тебе модераторы сообщат   

Не дают мне забыть про  перевод доки к boost::pool  и встал у меня такой вопрос - в английском есть два термина alignment и padding. Я термин alignment перевожу как выравнивание блока памяти по адресу, а термин padding перевожу как заполнение, когда блок памяти дополняется пустыми (ничего не значащими) символами, чтобы блок памяти всегда имел определенный фиксированный размер.
Может есть какой-то еще нюанс, что я упустил?

все правильно.

я там кстати ссылку на буст.пул добавил ;)

Ок

там это где? =)

тут: http://ru.wikibooks.org/wiki/Boost.Pool

Тьфу, точно, как не догадался? =) 
Скоро дело вообще "попрет". Вот бы еще какую статистику получить, пользуется ли народ учебником или нет. А еще бы обратную связь получить - ух! А то я сам чувствую иногда, что мало перевода, надо бы живых мыслей добавить. Да на все не замахнешься, а вот на "оживление" каких-то наиболее важных моментов можно было бы.

Термины лучше не переводить. Так и писать транслитом.
Аббревиатуры НИ В КОЕМ СЛУЧАЕ не переводить. Только зараженный грибами мозг может перевести IDE как ИСР(В книге Программист-прагматик).

  

Про ИСР - хороший пример, как не надо делать. =)
 Но некоторые термины (как alignment и padding) лучше перевести - мне кажется выравнивание и заполнение понятнее будет алаймента и паддинга. На всякий случай я в скобках оставляю оригинальный термин.

Не могу точно перевести следующий текст (сам смысл не 100% понимаю):
 (взято отсюда) я перевел так:
New-выражение первым аргументом типа std::size_t  передает функции выделения размер выделяемой памяти. Значение аргумента не должно быть меньше размера создаваемого объекта; значение может быть больше размера создаваемого объекта только если объект является массивом. Для массивов типов char и unsigned char разница(?) между результатом new-выражения и адресом, возвращаемым функцией выделения должна быть целым, кратным(??) наиболее строгим требованиям к выравниванию (3.9) объекта любого типа, чей размер не превышает размер создаваемого массива. [Примечание: В следствии того, что предполагается, что функции выделения возвращают указатели на хранилище, имеющее необходимое выравнивание для объектов любого типа, это ограничение на выделение массивов разрешает использование распространенной идиомы выделения символьных массивов, которые используются для размещения объекты других типов.]

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

думаю речь о том, что выделенный массив char должен быть выровнен по самой строгой границе. Т.е. если объекты размером 8 байт должны быть выровнены по границе 64-х битного слова. Т.е. адрес приведенный к int должен делиться без остатка на 8.

Это понятно. Непонятно что за разница имеется в виду между new-выражением и функцией выделения. 
Как следует из стандарта, new-выражение вызывает функцию выделения для непосредственного выделения памяти. При этом new-выражение знает о типе для которого выделяется память, а функция выделения нет. Т.е. возможно, что функция выделения выделит память невыравненную нужным образом и выравнивание должно выполнить new-выражение? Может быть это имеется в виду под разницей? Т.е. new-выражение должно выделить память для типа с выравниванием 8 байт, а функция выделения выделила блок памяти с адреса 0х0ААА4, т.е. выравненный по 4 байтной границе. Тогда new-выражение проигнорирует первые четыре байта и вернет не 0хААА4, а вернет 0хААА8? Может здесь это имеется в виду? 
В пользу моих логических рассуждений еще говорит фраза "...this constraint on array allocation overhead permits the common idiom...", буквально означающая "...это ограничение накладных расходов на выделение массивов позволяет использовать общую идиому..."

drug007, в любом случае, malloc возвращает область выровненную по самой строгой границе. Если ты используешь ее, то расслабься.

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

Это сообщение отредактировал(а) bsa - 26.1.2012, 10:33

bsa, конечно же вы правы, именно строгое выравнивание. 

Вообще, я решил оставить этот вопрос про разницу между результатом new-выражения и результатом функции выделения памяти - буду считать что понял и перевел правильно. А если неправильно - то все равно всем без разницы   , я время только зря трачу. А вам, bsa, спасибо за диалог.