static float *tmp = new... это общепринято?
Странный вопрос. Не принятно такое. 
По сравнению с "программистом Васей, который пишет на Дельфи", это таки прогресс.
Ну захотелось чуваку синглтон, ну он его и сделал... А то что память не освобождается при выходе из программы - ну это некрасиво конечно, но в общем ничего страшного.
бывает, что не освобождать память выгоднее (по соображениям скорости чем освобождать
Какая нах скорость? Тут ключевое(во всех отношениях) слово - static
а в какой момент статики в функциях инициализируются?
size точно уже задан в этот момент?
просто интересно.
size точно уже задан в этот момент?
просто интересно.
Слуш, ПэЖэ, я заметил
криво выглядит, конечно, но почему бы и нет? Если размер массива не очень велик и подобных функций не очень много, то на здоровье
криво выглядит, конечно, но почему бы и нет? Если размер массива не очень велик и подобных функций не очень много, то на здоровье
> а в какой момент статики в функциях инициализируются?
В момент первого использования
>size точно уже задан в этот момент?
Вопрос к автору кода
В момент первого использования
>size точно уже задан в этот момент?
Вопрос к автору кода
Это не криво. Именно так и делают синглтоны(да, да, я знаю что их делают не только так, но и так тоже).
>В момент первого использования
шо серьёзно? компилятор городит хитрый флажок и при каждом вызове проверяет? хы.
(ну естественно если выражение не константное)
шо серьёзно? компилятор городит хитрый флажок и при каждом вызове проверяет? хы.
(ну естественно если выражение не константное)
нах такой кривой синглтон? /*риторически*/
вот если создавать некий объект как static, который потом создаст и удалит массив... тут хоть контроль будет некий над поведением выделенного ресурса
вот если создавать некий объект как static, который потом создаст и удалит массив... тут хоть контроль будет некий над поведением выделенного ресурса
А как ты будешь реализовывать phoenix синглтон с помощью твоей идиомы? Ты можешь гарантировать нужный тебе порядок удаления статических объектов? Вот тебе usecase:
1) Удалился твой синглтон лога(статический объект)
2) Один из деструкторов статических объектов хочет писать в лог.
3) segfault
1) Удалился твой синглтон лога(статический объект)
2) Один из деструкторов статических объектов хочет писать в лог.
3) segfault
не, я понимаю, что с таким подходом проблем не оберёшься, но надо же думать, когда что-то реализуешь! А в твоём случае, но если там не массив, а например хэндл на открытый логфайл, его просто обязательно надо закрыть!
в общем, опять скатились на обсуждение синглтонов
в общем, опять скатились на обсуждение синглтонов
может там сначала вызывается другая функция, которая инициализирует все статические переменные, а потом меняет указатель на адрес самой функции и вызывает её?
может уж тогда код правит? меняет жмп на нопы
а может перемещает код функции на несколько байтов назад %
говоря о такой конструкции как о синглтоне не стоит забывать, что такая конструкция в h файле породит статических объектов по числу включений h файла в срр файлы. 2 включения в разные срр - два объекта, по одному на каждый срршник.
ты не в теме -- код в функции.
На сколько такое принято в программистской практике? мне подобное как-то противоестественно...
это абсолютно не принято на практике, ( в использовании float еще полбеды - все зависит от того как выглядит new, можно изъебнуться конечно и такую конструкцию сделать неприемлимой а если вместо float будут сложные объекты которые будут держать ресурсы системы, деструктор для них не вызовется => последствия могут быть любыми. ( память освободится при выходе без базара, но деструкторы вызываться не станут ).
я в теме, код в ф-ии, а ф-ия ___вместе___ со своим телом в аш файле и ты получаешь по объекту на каждый срр-файл, ферштейн? именно это имелось ввиду.
уверен? 
ну код функции уж точно не стоит писать в аш-файле.
Почему?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Типа наглая ложь и все такое 
1. чтобы не компилировать несколько раз один и тот же код
2. чтобы не засорять аш-файлы
2. чтобы не засорять аш-файлы
1. А писать всюду один и тот же код --- лучше?
2. Большего мусора, чем в заголовочных файлах, нигде нет,
так что одно определение ничего не решит.
---
...Я работаю антинаучным аферистом...
2. Большего мусора, чем в заголовочных файлах, нигде нет,
так что одно определение ничего не решит.
---
...Я работаю антинаучным аферистом...
1. нет. а один раз написать и откомпилировать, а потом всё время вызывать не судьба?
2. конечно, если пихать туда всё что попало, то так и будет. а если писать нормально, то мусора будет мало.
2. конечно, если пихать туда всё что попало, то так и будет. а если писать нормально, то мусора будет мало.
1. Это:
а) приводит к замедлению;
б) всё равно съедается при оптимизации.
2. Мусор там, в основном, из-за препроцессора,
так что --- даже если там будет куча определений функций ---
большего мусора не будет.
---
...Я работаю антинаучным аферистом...
а) приводит к замедлению;
б) всё равно съедается при оптимизации.
2. Мусор там, в основном, из-за препроцессора,
так что --- даже если там будет куча определений функций ---
большего мусора не будет.
---
...Я работаю антинаучным аферистом...
1.
а) какой ужас! боже мой! давайте все функции делать инлайновыми теперь!
б) что съедается?
2. из-за какого препроцессора? препроцессор взял и напихал туда мусор? фу, какой плохой препроцессор! как ему не стыдно?
а) какой ужас! боже мой! давайте все функции делать инлайновыми теперь!
б) что съедается?
2. из-за какого препроцессора? препроцессор взял и напихал туда мусор? фу, какой плохой препроцессор! как ему не стыдно?
1. Предложи компилятор, проводящий оптимизацию всей программы.
2. Сишного.
Из-за убожества сей, без него не обойтись.
Напихал, конечно, человек.
Если б это делала машина, include лежал бы не в /usr а в /var.
---
...Я работаю антинаучным аферистом...
2. Сишного.
Из-за убожества сей, без него не обойтись.
Напихал, конечно, человек.
Если б это делала машина, include лежал бы не в /usr а в /var.
---
...Я работаю антинаучным аферистом...
1. нет уж, увольте.
2. это предубеждение, можно без него обойтись. я обычно обхожусь (ну, кроме, include, естественно).
2. это предубеждение, можно без него обойтись. я обычно обхожусь (ну, кроме, include, естественно).
1. Значит, единственным предубеждением остаётся мнимое засорение заголовочных файлов.
2.1. Когда научишься обходится без #include, напиши.
2.2. Из-за таких нелюбителей препроцессора, дублируется код,
что приводит к появлению кучи почти совпадающих файлов,
наподобие *div, strtoXXX, vXXXprintf и т. п.
---
...Я работаю антинаучным аферистом...
2.1. Когда научишься обходится без #include, напиши.
2.2. Из-за таких нелюбителей препроцессора, дублируется код,
что приводит к появлению кучи почти совпадающих файлов,
наподобие *div, strtoXXX, vXXXprintf и т. п.
---
...Я работаю антинаучным аферистом...
> ну код функции уж точно не стоит писать в аш-файле.
Посмотри например сюда:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/sys...
Посмотри например сюда:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/sys...
Ой бля, что только сишники не делают чтобы сэмулировать шаблоны 
1. не мнимое и не предубеждение. а куда многократная перекомпиляция подевалась?
2.1. Вряд ли, я последнее время мало на С пишу.
2.2. У меня ничего не дублируется. А вот из-за таких любителей препроцессора некоторые заголовочные файлы невозможно читать.
2.1. Вряд ли, я последнее время мало на С пишу.
2.2. У меня ничего не дублируется. А вот из-за таких любителей препроцессора некоторые заголовочные файлы невозможно читать.
>1. Значит, единственным предубеждением остаётся мнимое засорение заголовочных файлов.
Нет. Есть еще такая штука как бинарная совместимость. Хотя куда тебе...
Нет. Есть еще такая штука как бинарная совместимость. Хотя куда тебе...
1. Ты не предложил _хорошо_ оптимизирующего компилятора.
2.1. Тем хуже для тебя.
2.2.1. Это просто говорит о том, что тебе это не критично,
например, ты можешь использовать один числовой тип.
Либо за тебя это делает компилятор.
2.2.2. Писать надо уметь читаемо.
Либо придумать способ создавать эти заголовочные файлы из более читаемого источника.
---
...Я работаю антинаучным аферистом...
2.1. Тем хуже для тебя.
2.2.1. Это просто говорит о том, что тебе это не критично,
например, ты можешь использовать один числовой тип.
Либо за тебя это делает компилятор.
2.2.2. Писать надо уметь читаемо.
Либо придумать способ создавать эти заголовочные файлы из более читаемого источника.
---
...Я работаю антинаучным аферистом...
Бинарная совместимость чего с чем?
Хотя куда тебе...
---
"Narrowness of experience leads to narrowness of imagination."
Хотя куда тебе...
---
"Narrowness of experience leads to narrowness of imagination."
1. действительно, я не предложил.
2.1. ужас. сижу и плачу.
2.2.1. абсолютно согласен. я не против inline-функций вообще, наоборот я их использовал и использую, я говорю, что ту функцию, в которой встречается статический массив не стоит делать инлайн. Потому что вряд ли ей понадобится такая оптимизация. Точнее не ей, а её вызовам.
2.2.2. Учиться, учиться и учиться.
2.1. ужас. сижу и плачу.
2.2.1. абсолютно согласен. я не против inline-функций вообще, наоборот я их использовал и использую, я говорю, что ту функцию, в которой встречается статический массив не стоит делать инлайн. Потому что вряд ли ей понадобится такая оптимизация. Точнее не ей, а её вызовам.
2.2.2. Учиться, учиться и учиться.
1. Значит, другого способа оптимизации и тем самым
устранения многократной пересборки (пока) нет.
2.1. Можешь радоваться тому, что избавлен от этих трудностей.
2.2.1. А почему это её не стоит делать встраиваемой?
Отказываться от скорости из-за капризов очередного пророка?
2.2.2. Значит, нечитаемость как довод против
определения функций в заголовочных файлах отбрасываем.
---
...Я работаю антинаучным аферистом...
устранения многократной пересборки (пока) нет.
2.1. Можешь радоваться тому, что избавлен от этих трудностей.
2.2.1. А почему это её не стоит делать встраиваемой?
Отказываться от скорости из-за капризов очередного пророка?
2.2.2. Значит, нечитаемость как довод против
определения функций в заголовочных файлах отбрасываем.
---
...Я работаю антинаучным аферистом...
2.1. Спасибо. Сейчас начну.
2.2.1. Да какая на Си может быть скорость? Надо на ассемблере писать.
2.2.2. Нет, не значит.
2.2.1. Да какая на Си может быть скорость? Надо на ассемблере писать.
2.2.2. Нет, не значит.
2.2.1. При наличии оптимизирующего компилятора и умении писать --- приличная,
сравнимая с ассемблерной, если не лучше.
2.2.2. Предложи другой способ избежать дублирования встраиваемого кода.
---
...Я работаю антинаучным аферистом...
сравнимая с ассемблерной, если не лучше.
2.2.2. Предложи другой способ избежать дублирования встраиваемого кода.
---
...Я работаю антинаучным аферистом...
2.2.1. Сравнимая -- это не интересно. Сравнимую можно и без (инлайн функций со статическими массивами) иметь.
2.2.2. something.h:
void f; // blah-blah
int g; // la-la-la
#include "something.cpp"
2.2.2. something.h:
void f; // blah-blah
int g; // la-la-la
#include "something.cpp"
2.2.1. Сложно сказать, надо проводить испытания.
Но всё равно сомнительно, чтобы невозможно было выиграть время на вызовах.
Это какие-то сферические процессоры.
2.2.2. Это, во-первых, использует препроцессор,
во-вторых, может привести к потере скорости на вызовах,
в-третьих, загромождает пространство имён.
Поясняю последнее.
Мне больше нравится, когда перемещение называется "move",
а не "this_damn_type_move", в особенности, когда "this_damn_type" очевиден из окружения.
---
...Я работаю антинаучным аферистом...
Но всё равно сомнительно, чтобы невозможно было выиграть время на вызовах.
Это какие-то сферические процессоры.
2.2.2. Это, во-первых, использует препроцессор,
во-вторых, может привести к потере скорости на вызовах,
в-третьих, загромождает пространство имён.
Поясняю последнее.
Мне больше нравится, когда перемещение называется "move",
а не "this_damn_type_move", в особенности, когда "this_damn_type" очевиден из окружения.
---
...Я работаю антинаучным аферистом...
а зачем макросы в h-файлах-то использовать?
если не хочешь засорять неймспейсы и хочешь чтобы был ясен контекст, то надо их писать в c-файлах.
вообще требования:
1. не засорять неймспейс
2. использовать функции с именами мув вместо мой_отличный_тип_мув
3. не писать один и тот же код несколько раз
не совместимы, имхо.
если не хочешь засорять неймспейсы и хочешь чтобы был ясен контекст, то надо их писать в c-файлах.
вообще требования:
1. не засорять неймспейс
2. использовать функции с именами мув вместо мой_отличный_тип_мув
3. не писать один и тот же код несколько раз
не совместимы, имхо.
> а зачем макросы в h-файлах-то использовать?
Затем, чтобы одновременно удовлетворять все три требования,
которые ты считаешь несовместимыми.
---
"Расширь своё сознание!"
Затем, чтобы одновременно удовлетворять все три требования,
которые ты считаешь несовместимыми.
---
"Расширь своё сознание!"
ок, я, правда, имел ввиду другой неймспейс
но писать макросы это всё равно разврат.
и заметь, что это ты жалуешься на убогость С и замусоренность h-файлов. ещё есть проблемы, про которые ты говоришь -- а они ещё хуже.
Так что при твоём подходе возникает куча проблем.
но писать макросы это всё равно разврат.
и заметь, что это ты жалуешься на убогость С и замусоренность h-файлов. ещё есть проблемы, про которые ты говоришь -- а они ещё хуже.
Так что при твоём подходе возникает куча проблем.
А то что память не освобождается при выходе из программы - ну это некрасиво конечно, но в общем ничего страшного.
А вот скажите, если сделать dlopen/dlclose несколько раз, а в .so-шке вот такой static ... = new ... написан, то будет течка, а?
Вполне возможно. Смотря как сделан dlopen/dlclose
Оставить комментарий
pulmo
Встретил сегодня вот такой код у "коллеги":внутри функции которая вызывается очень часто:
size задается 1 раз в начале работы, delete [] tmp; нигде не делается.
На сколько такое принято в программистской практике? мне подобное как-то противоестественно...