Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, samius, Вы писали:
S>>Я ж написал, что не уверен в случае одноядерной машины. Но что в многоядерной его точно нет. А ты сказал, что все наоборот. Вот и рассказывай нафига интерлокед на многоядерной машине. CC>Да потому, что интерлокед как таковой только для многоядерной и нужен.
CC>Безотносительно к принципам организации менеджера памяти в .NET
Ненене, вопрос конкретно в том, нафига интерлокед нужен многоядерному GC? Не виляй. Речь шла именно о GC. И "наоборот" писал ты!
Я допускаю, что в случае одноядерной системы я ляпнул что-то не то. Уже дважды написал, что не уверен! Но ты не написал что не уверен, когда писал что все наоборот. Вот давай, объясняйся
CC>Неправильно только одно: зачем на С++ реализовывать такой аллокатор?
Речь шла не об «зачем», а об «какой угодно» и «вообще любой».
CC>Неправильно только одно: зачем на С++ реализовывать такой аллокатор?
Чтобы ускорить аллокацию. В такой модели менеджер будет катастрофически быстро выделять память всегда в конце пула, а не искать в цепочках чанков дыры подходящего размера от освобождённых ранее объектов.
CC>Пользы от него будет меньше чем неудобств.
В C++, очевидно, да.
CC>Более того, зачем его реализовывать как глобальный?
Ок, пойдём на уступки. Не надо глобальный, пусть будет просто аллокатор, удовлетворяющий требованиям из пункта «Allocator Requirements» Стандарта.
CC>К примеру стоит прикручивать нечто подобное только для алгоритмов, у которых фрагментация памяти является побочным эффектом.
Во-первых, совсем непросто вычленить такие алгоритмы, да и неблагодарное это дело.
Во-вторых, даже если мы сумели выделить такой алгоритм, мы не можем вызывать функции (в том числе стандартные), которые принимают аргумент по ссылке. (У меня крутятся мысли о том, как это можно было бы обойти, но это очень далеко от «какой угодно» и «вообще любой»).
CC>Еще раз говорю: не надо тупо копировать идеи и подходы из других платформ.
...в платформы, крайне плохо для того предназначенные.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Qbit86, Вы писали:
CC>>>По своей сути С++ позволяет реализовать какой угодно аллокатор. CC>>>Сравнение в таком случае С++ аллокатора (который может быть вообще любым) с конкретной реализацией GC не имеет смысла по определению.
Q>>Как на C++ реализуется перемещающий менеджер памяти? CC>Можно. CC>Но с заменой указателей на обёртки и вводом ограничений на использование сырых указателей.
Правильно, надо написать CLR или JRE, они ведь на C++.
Только еще придется переписать код стандартной библиотеки, чтобы она работала с новым менеджером памяи и новыми примитавами.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, CreatorCray, Вы писали:
G>>>>надо разделять данные между потоками и\или использовать атомные операции. G>>>>второе далеко не всегда доступно (в C++ например не доступно при выделении памяти). CC>>>Ты про что вообще? G>>В .NET насколько я понимаю выделение памяти реализовано как interlocked add указателя. CC>Понятнее не стало. CC>Что именно ты имел в виду под "второе далеко не всегда доступно (в C++ например не доступно при выделении памяти)."? CC>Аллокацию в С++ через инкремент указателя сделать можно. Вот только с деаллокацией придется погеморроиться.
Не просто погеморроиться, а сильно погеморроиться.
CC>Не надо тупо копировать решения их других платформ с их особенностями.
А никто их копировать не собирается.
Здравствуйте, Qbit86, Вы писали:
CC>>Неправильно только одно: зачем на С++ реализовывать такой аллокатор? Q>Речь шла не об «зачем», а об «какой угодно» и «вообще любой».
Ну так не надо передирать идею. Есть проблема — надо придумать решение.
Готовое решение с другой платформы передирать глупо — платформы слишком разные.
Вот я про что: что делать на С++ точно такой же по алгоритму аллокатор как в .NET просто глупо.
CC>>Неправильно только одно: зачем на С++ реализовывать такой аллокатор? Q>Чтобы ускорить аллокацию. В такой модели менеджер будет катастрофически быстро выделять память всегда в конце пула, а не искать в цепочках чанков дыры подходящего размера от освобождённых ранее объектов.
Странный подход. Есть алгоритмы аллокации которым не надо ничего искать.
Надо использовать их, а не тупо пытаться адаптировать технологию с другой платформы.
CC>>Еще раз говорю: не надо тупо копировать идеи и подходы из других платформ. Q>...в платформы, крайне плохо для того предназначенные.
Ты хочешь скопировать готовое решение проблемы, реализованное под конкретную платформу.
А надо разработать алгоритм, который на данной платформе будет решать такую же проблему.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>Правильно, надо написать CLR или JRE, они ведь на C++. G>Только еще придется переписать код стандартной библиотеки, чтобы она работала с новым менеджером памяи и новыми примитавами.
Ну это ж вам до зубовного скрежета хочется именно глобальный перемещающий менеджер.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, VladD2, Вы писали:
VD>И вообще, твои слова банальная демонстрация некомпетентности. Лисп изначально имел сборщик мусора и стало быть делать урезанные в нем не имело никакого смысла.
При чем тут "урезание"? До сих пор в разных реализациях Лиспа и даже интерпретаторов Схемы используются разные подходы к "механике" замыканий, от этого и есть основная несовместимость на уровне исходников.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здесь два соображения. Первое — что какими бы "какими-то" эти финны ни были, но их книга издана и в Финляндии, и в СССР. Второе — что описанный подход вполне соответствует идее об устранении побочных эффектов (чистоты) в функциональных программах. По-моему, вполне достаточные основания считать, что подобная реализация замыканий имела место быть в определённом историческом периоде и можно даже допустить, что серьёзно обсуждалась в качестве "правильной".
При наличии возможностей изменять значения переменных byvalue и есть "единственно-правильный" вид замыканий. А вообще, там приемов несколько — например есть реализации лиспов/схем, где после присвоения нового значения переменной создается новая одноименная переменная, которой оперирует текущий контекст исполнения, т.е. даже используя механизм byname как более "легковесный", получается поведения как при byvalue.
Здравствуйте, vdimas, Вы писали:
V>При чем тут "урезание"? До сих пор в разных реализациях Лиспа и даже интерпретаторов Схемы используются разные подходы к "механике" замыканий, от этого и есть основная несовместимость на уровне исходников.
Для CL все прописано в стандарте. Схема же язык практически чисто функциональный, для нее данный аспект не важен.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>При чем тут "урезание"? До сих пор в разных реализациях Лиспа и даже интерпретаторов Схемы используются разные подходы к "механике" замыканий, от этого и есть основная несовместимость на уровне исходников.
VD>Для CL все прописано в стандарте. Схема же язык практически чисто функциональный, для нее данный аспект не важен.
На CL мир клином не сошелся, например нет его реализаций под управляемые платформы типа Java или .Net. Далее, в различных реализациях Схемы есть возможность изменять значения переменных, поэтому способ реализации замыканий играет роль (сейчас в ходу сразу три стандарта Схемы, с 4-го по 6-й). В общем, тут спорить не о чем, я когда-то изучил десятки исходников лисп и схем, и обнаружил, что способов реализации как замыканий, так и контекста исполнения (разновидность "замыкания" текущего потока) множество.
Бардак, согласись, но если в Схеме хоть идет все более глубокое стандартизирование, не привязанное к конкретной реализации, то Лисп страшно далек от подобного. Собственно, CL своими библиотеками и расширениями оказал плохую службу этому направлению, продлив жизнь своего диалекта Лиспа. Посмотрев чуть выше, нет никаких причин использовать Лисп при наличии Схемы, тем более, что после 6-го стандарта ожидается приличная пауза м/у их выходами, т.е. будет достаточно времени для "вымывания" из обращения предыдущих двух.
Здравствуйте, vdimas, Вы писали:
V>На CL мир клином не сошелся, например нет его реализаций под управляемые платформы типа Java или .Net. Далее, в различных реализациях Схемы есть возможность изменять значения переменных, поэтому способ реализации замыканий играет роль (сейчас в ходу сразу три стандарта Схемы, с 4-го по 6-й). В общем, тут спорить не о чем, я когда-то изучил десятки исходников лисп и схем, и обнаружил, что способов реализации как замыканий, так и контекста исполнения (разновидность "замыкания" текущего потока) множество.
Спорить с тем, что есть можество разных реализаций языка которому 50 лет я не буду. К не буду спорить о том, что если в языке есть императивное присвоение и замыкания, то полноценным замыканием будет только то, что позволяет изменять захваченые переменные из замыкания.
V>Бардак, согласись, но если в Схеме хоть идет все более глубокое стандартизирование, не привязанное к конкретной реализации, то Лисп страшно далек от подобного. Собственно, CL своими библиотеками и расширениями оказал плохую службу этому направлению, продлив жизнь своего диалекта Лиспа. Посмотрев чуть выше, нет никаких причин использовать Лисп при наличии Схемы, тем более, что после 6-го стандарта ожидается приличная пауза м/у их выходами, т.е. будет достаточно времени для "вымывания" из обращения предыдущих двух.
Интересное мнение, но к делу не относящееся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>При наличии возможностей изменять значения переменных byvalue и есть "единственно-правильный" вид замыканий.
Мне тоже кажется, что, во всяком случае, "от рождения" замыкания должны были быть именно такими. Потом просто обобщили подход на разные способы использования.
V>А вообще, там приемов несколько — например есть реализации лиспов/схем, где после присвоения нового значения переменной создается новая одноименная переменная, которой оперирует текущий контекст исполнения, т.е. даже используя механизм byname как более "легковесный", получается поведения как при byvalue.
Интересно, хотя я такой именно реализации, кажется, не встречал. Наверное, смотрел плохо.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, criosray, Вы писали:
NBN>>>Я когда пишу на С++ — просто выделяю память, и не занимаюсь её освобожденим — пока в этом нет необходимости.
C>А необходимость возникает только тогда, когда продакшн билд начинает течь, как дырявое решето?
C>Еще интересно было бы увидеть что-то вроде RhinoMocks — библиотеки для мокинга объектов (свойства, методы, события).
Нууу, просить генерировать код в рантайм не совсем корректно, хотя и для С++ таким макаром иногда поступают. И вообще, в С++ принятно тестировать в юнит-тестах сам код, а не бинарные сборки, что в свою очередь легко делается через инклюды и прочий развитый препроцессинг. В общем, подход к юнит-тестированию совсем другой и нет смысла тратить время на неприменимый и безбенифитный (для С++) способ юнит тестирования, предназначенный для совсем других условий.
ГВ>>С другой стороны, в самом по себе паттерне IoC ничего запредельного нет, мне сейчас любопытно поиграться в тех ограничениях, которые ты предложил. C>Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.
Рефлексия она и в африке рефлексия. Развитый подобный фреймворк под нейтив — это разве что COM и пляски вокруг typelib-ов и prog ID. ActiveX site — как раз своего рода "конфигурируемый" в рантайм IoC-контейнер, правда в ограниченном множестве интерфейсов.
VD>Спорить с тем, что есть можество разных реализаций языка которому 50 лет я не буду. К не буду спорить о том, что если в языке есть императивное присвоение и замыкания, то полноценным замыканием будет только то, что позволяет изменять захваченые переменные из замыкания.
Что-то я логики не понимаю относительно "полноценности". Один из самых популярных сценариев замыканий — это просто карринг, некая "параметризация" ф-ии. И вот мы, типа, параметризировали ф-ию одним из аргументов, а потом, ввиду передачи этого параметра по ссылке, можем получить абсолютно непредсказуемые эффекты в моменты вызова этой ф-ии. Что, собственно, частенько и происходит. Где уж тут полноценность? ИМХО, полноценность — это когда мы можем явно указать требуемую семантику, и сдается мне, что семантикой по-умолчанию должна быть, разумеется, byvalue, как наименее "граблястая".
Здравствуйте, vdimas, Вы писали:
C>>Еще интересно было бы увидеть что-то вроде RhinoMocks — библиотеки для мокинга объектов (свойства, методы, события).
V>Нууу, просить генерировать код в рантайм не совсем корректно, хотя и для С++ таким макаром иногда поступают. И вообще, в С++ принятно тестировать в юнит-тестах сам код, а не бинарные сборки,
Вы вообще понимаете о чем говорите? Что такое модульное тестирование? Что значит "тестировать код, а не сборки"? Это, простите, бред.
Модульное тестирование подразумевает: а) тестирование состояния объектов, б) тестирование операбельности объектов. Препроцессингом ничто из перечисленного протестировать не возможно.
V>что в свою очередь легко делается через инклюды и прочий развитый препроцессинг. В общем, подход к юнит-тестированию совсем другой и нет смысла тратить время на неприменимый и безбенифитный (для С++) способ юнит тестирования, предназначенный для совсем других условий.
Почему он вдруг стал безбенефитным? Чем С++ такой особенный? Модульное тестирование программ на С++ как минимум не менее полезное, чем модульное тестирование программ на С#, Java, Python, и т.д.
Если код покрыт тестами, то его гораздо проще рефакторить и модифицировать.
ГВ>>>С другой стороны, в самом по себе паттерне IoC ничего запредельного нет, мне сейчас любопытно поиграться в тех ограничениях, которые ты предложил. C>>Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.
V>Рефлексия она и в африке рефлексия. Развитый подобный фреймворк под нейтив — это разве что COM и пляски вокруг typelib-ов и prog ID.
А COM тут при чем вообще?
V>ActiveX site — как раз своего рода "конфигурируемый" в рантайм IoC-контейнер, правда в ограниченном множестве интерфейсов.
Я очень надеюсь, что Вы пошутили...
Здравствуйте, criosray, Вы писали:
C>Вы вообще понимаете о чем говорите? Что такое модульное тестирование? Что значит "тестировать код, а не сборки"? Это, простите, бред. C>Модульное тестирование подразумевает: а) тестирование состояния объектов, б) тестирование операбельности объектов. Препроцессингом ничто из перечисленного протестировать не возможно.
Похоже, ты не понял основной посыл насчет тестирования исходников в С++ в противовес тому, что и как тестируется с помощью моков.
V>>что в свою очередь легко делается через инклюды и прочий развитый препроцессинг. В общем, подход к юнит-тестированию совсем другой и нет смысла тратить время на неприменимый и безбенифитный (для С++) способ юнит тестирования, предназначенный для совсем других условий.
C>Почему он вдруг стал безбенефитным? Чем С++ такой особенный?
Моковский подход и не был для С++ никогда бенефитным. Вложения труда не окупятся, поэтому там немного по-другому.
C>Модульное тестирование программ на С++ как минимум не менее полезное, чем модульное тестирование программ на С#, Java, Python, и т.д.
А это ты кому и о чем? Просто лозунги?
ГВ>>>>С другой стороны, в самом по себе паттерне IoC ничего запредельного нет, мне сейчас любопытно поиграться в тех ограничениях, которые ты предложил. C>>>Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.
V>>Рефлексия она и в африке рефлексия. Развитый подобный фреймворк под нейтив — это разве что COM и пляски вокруг typelib-ов и prog ID. C>А COM тут при чем вообще?
При том, что популярные IoC контейнеры для .Net до компиляции в глаза не видели оперируемые интерфейсы и конструкторы реализующих их классов. Такие шутки делаются лишь через метаинформацию, пример которой для нейтива есть typelib из COM, так же как и ср-ва для построения проксей для OLE-совместимых сигнатур.
V>>ActiveX site — как раз своего рода "конфигурируемый" в рантайм IoC-контейнер, правда в ограниченном множестве интерфейсов. C>Я очень надеюсь, что Вы пошутили...
Ну это ж вам до зубовного скрежета хочется именно глобальный перемещающий менеджер.
