Cудьба Mono

Если в плюсы запихнуть ещё и gc, то они станут не меньшим дерьмом, а большим.

Если в плюсы запихнуть ещё и gc, то они станут не меньшим дерьмом, а большим.

а зачем пихать именно В ПЛЮСЫ? Ты уже можешь перезагружать operator new/operator delete, и потому можешь реализовывать в плюсах _любые_ стратегии управления памяти. В том числе и сборку мусора. В том числе и в самую примитивную реализацию алгоритма Бейкера, которая похоже и юзается в этом вашем сишарпе.

а зачем пихать именно В ПЛЮСЫ?

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

перезагружать operator new/operator delete

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

Сборщик для плюсов существует, BoehmGC. Но это консервативный сборщик, реализовать полноценный stop-n-copy gc для плюсов невозможно.

Ты уже можешь перезагружать operator new/operator delete, и потому можешь реализовывать в плюсах _любые_ стратегии управления памяти.

Вранье. Неплоскую память типо как в win16 или 32-битовые интерфейсы дающие доступ к памяти сверх 2Гб ты через operator new/delete не заюзаешь.

Если в плюсы запихнуть ещё и gc, то они станут не меньшим дерьмом, а большим.

а зачем пихать именно В ПЛЮСЫ? Ты уже можешь перезагружать operator new/operator delete, и потому можешь реализовывать в плюсах _любые_ стратегии управления памяти. В том числе и сборку мусора. В том числе и в самую примитивную реализацию алгоритма Бейкера, которая похоже и юзается в этом вашем сишарпе.

Object obj = new Object();
int x = &obj;
Object yoba = x;

Прошла сборка мусора, obj переместился и yoba невалиден. Доступно объясняю?

Object obj = new Object();
int x = &obj;
Object yoba = x;

Type mismatch.

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

я не виноват, что ты не в состоянии осилить такие в общем-то несложные и удобные вещи.

Но это консервативный сборщик, реализовать полноценный stop-n-copy gc для плюсов невозможно.

ПОЧЕМУ не подскажешь?

Вранье. Неплоскую память типо как в win16 или 32-битовые интерфейсы дающие доступ к памяти сверх 2Гб ты через operator new/delete не заюзаешь.

в моей рабочей станции всё равно 1.5Гб. А на тех серверах, где это надо, установлена 64х битная ОС. Т.ч. свои интерфейсы и прочие костыли можешь затолкать обратно. Мне они не нужны.

Забыл typecast сделать, но идею ты понял, надеюсь.

Фиг знает, в Go указатель — такая же валидная ссылка на объект*.

* — под словом объект имеются в виду структуры, интерфейсы, функции и прочие типы, потому как объектов в жабовом смысле этого слова в Go нет.

Неплоскую память типо как в win16 или 32-битовые интерфейсы дающие доступ к памяти сверх 2Гб ты через operator new/delete не заюзаешь.

И почему же? Адресную арифметику использовать не получится, а объекты памяти - вполне.

Вранье. Неплоскую память типо как в win16 или 32-битовые интерфейсы дающие доступ к памяти сверх 2Гб ты через operator new/delete не заюзаешь.

Т.ч. свои интерфейсы и прочие костыли можешь затолкать обратно. Мне они не нужны.

Нкто тебя не спрашивает что тебе нужно. Есть практическая необходимость заюзать интерфейс, мапящий страницы по требованию. Все, С++ в ауте, юзаем POD-структуры.

Выше по треду я привел пример. С, C++ не позволяют реализовать подобное, т.к. язык позволяет манипулировать адресами объектов.

Я не знаю какой сборщик реализован в go, возможно там не используется stop-n-copy.

Object obj = new Object();
int x = &obj;
Object yoba = x;

Прошла сборка мусора, obj переместился и yoba невалиден. Доступно объясняю?

вполне. Вот только ты забыл о том, что вторая строчка твоего кода это на самом деле конструктор копирования (или ещё и оператор преобразования в int), и вот именно этот конструктор копирования как раз и сохранит информацию о том, что объект был перемещён/переименован. В твоём коде ошибка - new выдаёт указатель на объект. Этот указатель можешь копировать куда угодно, и сколько угодно. Однако, если ты копируешь сам объект, то вызывается конструктор копирования, или operator=(), которые и сохраняют информацию о появлении новой копии. Если ты забил на них - твои проблемы. У меня во всех классах, где это не нужно они в секции private, потому подобный код тупо не скомпиллится.

Там может быть реализован какой угодно сборщик, это деталь реализации, которая не должна волновать программиста.

вторая строчка твоего кода это на самом деле конструктор копирования

Вот из-за такого С++ и не любят. Выглядит как присваивание, хочется, чтобы работало как присваивание. А на деле? Undefined behavior.

И почему же? Адресную арифметику использовать не получится, а объекты памяти - вполне.

Мы уже говорили на эту тему. В win16 блоки памяти идентифицировались не указателем, а хендлом. Чтобы получить указатель и с ними дальше работать надо было вызвать lock(). После окончания надо было вызвать unlock() чтобы блок памяти мог перемещаться и уйти в своп при необходимости. Адреса живых С++-ных объектов в функции манипулирующие блоками памяти передавать нельзя.

В win16 блоки памяти идентифицировались не указателем, а хендлом. Чтобы получить указатель и с ними дальше работать надо было вызвать lock().

И почему это нельзя сделать через умный уеказатель?

Адреса живых С++-ных объектов в функции манипулирующие блоками памяти передавать нельзя.

Можно, просто нужно понимать последствия. Кстати, какое это имеет отношение к твоей фразе:

Absurd> Неплоскую память типо как в win16 или 32-битовые интерфейсы дающие доступ к памяти сверх 2Гб ты через operator new/delete не заюзаешь.

Нкто тебя не спрашивает что тебе нужно. Есть практическая необходимость заюзать интерфейс, мапящий страницы по требованию. Все, С++ в ауте, юзаем POD-структуры.

почему «в ауте»? Самый простой вариант - перезагружаем new, и делаем так, что-бы он выдавал некий уникальный дескриптор объекта. Вот и всё. А всю хитрую реализацию прячем в этот наш new. Хоть win16, хоть Linux64. Если есть желание и необходимость - можешь хоть распределённую «память» таким образом сделать, на дисках 100500 серверов.

// test.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <iostream>

class Object
{
public:
	void Show()
	{
		std::cout << "Object" << '\n';
	}
};

int _tmain(int argc, _TCHAR* argv[])
{
	Object* obj = new Object();
	obj->Show();
	int addr = (int)&obj;
	Object* yoba = (Object*)addr;
	yoba->Show();
	std::cin.get();
	return 0;
}

Вот исправленный рабочий код. Убери stdafx и замени декларацию main и будет компилироваться gcc. Как ты будешь изменять содержимое addr при сборке мусора?

Самый простой вариант - перезагружаем new, и делаем так, что-бы он выдавал некий уникальный дескриптор объекта.

Похоже, Абсурдег намекает на то, что из new можно вернуть только адрес, но не дескриптор. Впрочем, это вполне можно обойти для случая мапинга по запросу.

Выше по треду я привел пример. С, C++ не позволяют реализовать подобное, т.к. язык позволяет манипулировать адресами объектов.

в каком смысле «манипулировать»? Если ты написал x = new Object, то ты с этим x никак не можешь _манипулировать_, единственное что ты можешь - это в точности скопировать данный указатель. Если ты написал x++, то это в любом случае ведёт к UB, и в C++ и в простом C.

Если ты желаешь сделать объект, который как в других ЯП должен сам удаляться и сам создаваться, то ты можешь воспользоваться концепцией «умных указателей» Джеффа, обернув в него свой объект. Оператор new в таком случае будет отдавать не просто указатель, а указатель на «умный указатель», который и возьмёт на себя все заботы о выделении/уничтожении объектов. С т.з. синтаксиса ничего не изменится, ибо operator->() тоже перезагружается, и на самом деле мы вовсе не теряем контроль над «манипуляциями».

Накладных расходов при этом ровно 0 (ноль), ибо в других ЯП будут выполнятся ровно те же самые действия, просто в C++ их надо прописать явно.

Я не знаю какой сборщик реализован в go

вот и я про то. Только мысы знает, что за сборщик в сишарпе. И только я знаю, что за сборщик в моём проекте. А суть в том, что в моём проекте сборщик оптимальный для моего проекта, а в си шарпе сборщик тоже оптимальный. Но не для меня и не для тебя, а для мысы. Такие дела...

А суть в том, что в моём проекте сборщик оптимальный для моего проекта

Кстати, а какой в твоем проекте сборщик мусора? %)

Вот из-за такого С++ и не любят. Выглядит как присваивание, хочется, чтобы работало как присваивание. А на деле? Undefined behavior.

а на деле для меня это конструктор копирования. И для моего компилятора - тоже. А что кажется разным phpшным и сишарповым быдлокодерам - меня волнует чуть менее чем никак. С этим ничего не поделать уже... Я повторяю - дрель это хреновый молоток, потому-что это не молоток. Тут та же история - ты увидел непонятный инструмент, похожий на молоток. Но это НЕ молоток. Добро пожаловать в C++, детка. В нём есть мощные и красивые вещи, и никого не волнует, что они там на что-то для кого-то похожи.

Мы уже говорили на эту тему. В win16 блоки памяти идентифицировались не указателем, а хендлом. Чтобы получить указатель и с ними дальше работать надо было вызвать lock(). После окончания надо было вызвать unlock() чтобы блок памяти мог перемещаться и уйти в своп при необходимости. Адреса живых С++-ных объектов в функции манипулирующие блоками памяти передавать нельзя.

повторяю - оберни свой хендл в «умный указатель», и пользуйся им как обычно.

непонятный инструмент, похожий на молоток. Но это НЕ молоток.

Вся суть С++ в двух предложениях.

Когда в любом нормальном языке пишешь a = b, то компилятор считает то что справа и присваивает тому, что слева. И только в плюсах происходит какая-то мутная херня с лишними вызовами.

в каком смысле «манипулировать»? Если ты написал x = new Object, то ты с этим x никак не можешь _манипулировать_, единственное что ты можешь - это в точности скопировать данный указатель. Если ты написал x++, то это в любом случае ведёт к UB, и в C++ и в простом C.

Я сохранил адрес объекта в переменную. Как сборщик мусора будет различать int с данными от int c указателями? В консервативном сборщике он тупо просматривает все выровненные данные и если значение попадает в диапазон допустимых адресов, сборщик считает объект достижимым. Он не может отличить число от указателя. Поэтому в консервативном сборщике невозможно перемещение объектов используемое в stop-n-copy алгоритме.

Накладных расходов при этом ровно 0 (ноль), ибо в других ЯП будут выполнятся ровно те же самые действия, просто в C++ их надо прописать явно.

Ты ничего не знаешь о сборщиках мусора. В нормальных gc мертвые объекты не трогаются вообще, на скорость влияет только количество живых объектов.

а на деле для меня это конструктор копирования

Это не gc. Это стратегия управления памятью, почитай что такое gc, для начала.

Как ты будешь изменять содержимое addr при сборке мусора?

никак. Ибо

int addr = (int)&obj;

это UB, и как это будет работать я не знаю, и знать не хочу. Мы про сборщик мусора, а не про костыли для говнокода рассуждаем.

Похоже, Абсурдег намекает на то, что из new можно вернуть только адрес, но не дескриптор.

можно вернуть объект, который при разименовании прикидывается указателем на нужный нам объект с помощью перезагрузки operator->(). Таким образом мы получаем «указатель», который ведёт себя как обычный указатель, и тем не менее, указателем НЕ является, а имеет дополнительный функционал, который и даёт возможность организовать сборку мусора и/или что угодно.

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

из new можно вернуть только адрес, но не дескриптор.

можно вернуть объект, который при разименовании прикидывается указателем на нужный нам объект

Видно, я что-то упустил из последних лет развития Си++. Можешь дать пример кода, где из new возвращается не указатель?

Кстати, а какой в твоем проекте сборщик мусора? %)

самый простой - объекты НИКОГДА не удаляются, а только создаются новые. Это самый быстрый способ «удаления» объектов потому, что они в моём случае ПОЧТИ никогда не удаляются (но иногда, очень редко, это необходимо. В итоге примерно 0.1% памяти теряется, за то во первых быстродействие delete максимальное (равно 0(нулю)), а во вторых, затраты памяти минимальные (например ваш любимый алгоритм Бейкера тратит ровно 100% памяти, а мой 0.1%, т.е. ровно в 1000 раз меньше).

Кстати, а какой в твоем проекте сборщик мусора? %)

самый простой - объекты НИКОГДА не удаляются

Если это и сборщик мусора, правильнее назвать его не «простым», а «вырожденным».

непонятный инструмент, похожий на молоток. Но это НЕ молоток.

Вся суть С++ в двух предложениях.

то, что дрель != молоток, не говорит о том, что дрель хуже молотка. Она не хуже и не лучше. Просто ей надо пользоваться иначе.

Когда в любом нормальном языке пишешь a = b, то компилятор считает то что справа и присваивает тому, что слева. И только в плюсах происходит какая-то мутная херня с лишними вызовами.

потому-что C++ это ООП, а operator=() это просто один из методов объекта. ИМХО вполне логично. В ООП вообще нет и быть не может операции «равно», должен быть (и он есть) метод, который копирует значение одного объекта в другой. И ессно мы _должны_ иметь возможность его перезагружать, хотя-бы для того, что-бы выполнить пресловутое ваше gc. Очевидно, без перезагрузки operator=() никакого gc у нас не получится.

Что до лишних вызовов, то их и нет. int x = 5; компиллится именно в то, что ты подумал, без всяких operator=(), и Object x = y; тоже компиллится в memcpy(), если конечно мы это не изменили (например для той же gc).

Я сохранил адрес объекта в переменную. Как сборщик мусора будет различать int с данными от int c указателями?

ты споришь со мной за C++, но при этом аргументация у тебя в стиле C. Оператор new в C++ тебе выдаст _объект_, а никакой не адрес. А этот объект в состоянии запомнить, на кого он «указывает», на данные, или ещё на что. Если тебе это конечно надо. Компилятор тебе просто не позволит преобразовать твой «указатель» скажем в int, если ты конечно явно не пропишешь оператор преобразования (что очень удобно, например для адресации 38го элемента коллекции. В каком смысле он «38й» - решать исключительно тебе)

В консервативном сборщике он тупо просматривает все выровненные данные и если значение попадает в диапазон допустимых адресов, сборщик считает объект достижимым. Он не может отличить число от указателя. Поэтому в консервативном сборщике невозможно перемещение объектов используемое в stop-n-copy алгоритме.

ну и что?

Ты ничего не знаешь о сборщиках мусора. В нормальных gc мертвые объекты не трогаются вообще, на скорость влияет только количество живых объектов.

пока памяти немеренно они действительно не трогаются. Но если ты засрал всю выделенную тебе память, сборщик просто вынужден будет перед выделением памяти выяснить, какой объект действительно мёртвый, а какой ещё жив. В упомянутой тобой примитивной схеме, которой уже лет 50, сборщик тупо копирует живые объекты во вторую область памяти. Эта стратегия довольно просто реализуется на C++, путём перезагрузки оператора new, который и будет этим заниматься при необходимости. Это делается в базовом классе, от которого наследуются все классы, которые нуждаются в таком gc. Живость объектов можно реализовать по разному, например подсчётом ссылок на объект. Ссылки будут увеличивать operator=() для такого «указателя», т.о. мы всегда будем знать, сколько «указателей» ссылается на наш объект. Очевидно, есть смысл запретить создавать объекты напрямую, минуя наш «указатель», для этого нужно например сделать конструкторы его private. Тогда кодеры никак не смогут манипулировать нашими объектами напрямую, а только лишь посредством наших «указателей».

ООП вообще нет и быть не может операции «равно»

без перезагрузки operator=() никакого gc у нас не получится.

Жж0ш напалмом.

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

я ждал сего глубокомысленного замечания, потому нагуглил для тебя 877 примеров допустимого кода на сишарпе: http://govnokod.ru/csharp

сборщик (и любой другой код) НЕ обязан учитывать говнокод, который приводит к UB. Твой пример некорректен, вне зависимости от (не)использования gc.

Видно, я что-то упустил из последних лет развития Си++. Можешь дать пример кода, где из new возвращается не указатель?

ты не понял - я предлагаю возвращать указатель на специальный объект, который ведёт себя как указатель. И кроме того, я предлагаю запретить использовать данный класс иначе, чем через наш «указатель».

Похоже на намеренный отстрел яиц. Лучше бы сразу на 0 поделил

Если это и сборщик мусора, правильнее назвать его не «простым», а «вырожденным».

угу. Это никак не отменяет того факта, что он мне сэкономил уйму времени. По ТЗ объекты таки иногда уничтожаются, и это надо было тоже учесть. Если-бы я использовал обычную дефолтную стратегию, я потерял-бы кучу времени и сил, и в рантайме, и при разработке, ибо дефолтная стратегия совсем не учитывает такой случай. Схема Бейкера ещё хуже в данном случае...

ты споришь со мной за C++, но при этом аргументация у тебя в стиле C. Оператор new в C++ тебе выдаст _объект_, а никакой не адрес. А этот объект в состоянии запомнить, на кого он «указывает», на данные, или ещё на что. Если тебе это конечно надо. Компилятор тебе просто не позволит преобразовать твой «указатель» скажем в int, если ты конечно явно не пропишешь оператор преобразования (что очень удобно, например для адресации 38го элемента коллекции. В каком смысле он «38й» - решать исключительно тебе)

Я тебе привел пример компилируемого валидного С++ кода. Как ты будешь реализовывать stop-n-copy сборщик в таком случае?

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

Хватит чушь пороть, сборщик проходит по графу достижимых объектов и копирует их в новую область, мертвые объекты он не трогает. Для оптимизации используются также другие стратегии (например барьеры записи и поколения объектов) так что каждый раз полный граф проходить сборщику не нужно.

Это делается в базовом классе, от которого наследуются все классы, которые нуждаются в таком gc. Живость объектов можно реализовать по разному, например подсчётом ссылок на объект. Ссылки будут увеличивать operator=() для такого «указателя», т.о. мы всегда будем знать, сколько «указателей» ссылается на наш объект.

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

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

ты не понял

Так уж ты объясняешь.

я предлагаю возвращать указатель на специальный объект

т.е. new Foo() возвращает не Foo *, а FooPtr *? Не подходит, ибо на указателе нельзя перегрузить operator->. Т.е.

Foo *f = new Foo();
f->m(); // так нельзя - используется обычный operator->

Нужно примерно так:

Foo *f = new Foo(); // мапит память и запоминает указатель в глобальной таблице

f->m();

delete foo; // убирает указатель из глобальной таблицы и анмапит память

я ждал сего глубокомысленного замечания, потому нагуглил для тебя 877 примеров допустимого кода на сишарпе: http://govnokod.ru/csharp

Как этот код влияет на работоспособность шарпового gc?

Схема Бейкера ещё хуже в данном случае...

Схема Бейкера рассчитана на долгоживущие программы, которые постоянно создают и уничтожают объекты. Твоя программа явно не такая.

Жж0ш напалмом.

не путай операцию, и operator=(), который на самом деле является методом класса.

Похоже на намеренный отстрел яиц. Лучше бы сразу на 0 поделил

+1

а потом можно порассуждать, о том, какие хреновые CPU делает Intel (или AMD, зависит от религиозных предпочтений аффтора).

(не по теме сообщения, ответом на которое является этот коммент)

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

Мы вот тоже на жаве имеем метапрограммирование, функциональщину, множественное наследование и прямое управление памятью путем эмуляции всей это херни (или в твоей терминологии «сделали это сами»), но это ведь не повод утверждать, что полученное — это Java. Это какой-то метаязык, исходный код на котором находится исключительно в наших головах, а потом руками транслируется в код на жаве. Другой язык, не сама Жава. Иногда мы формализуем этот язык, получается DSL, для которого пишем на жаве интерпретатор или компилятор — и тогда уже даже внешний наблюдатель сможет понять, что это нифига не жава. Идея, мысль, алгоритм - они должны напрямую выражаться в терминах языка. Это когда ты хочешь отфильтровать коллекцию и пишешь «collection.sort», вместо написания эмуляции путем использования цикла. Это когда ты хочешь отнаследовать объект А от Бэ и пишешь «A extends Бэ», а не склеиваешь структуры-таблицы виртуальных функций с ручным разрешением конфликтов.

ООП вообще нет и быть не может операции «равно»
без перезагрузки operator=() никакого gc у нас не получится.

не путай операцию, и operator=()

Я их уж 20 лет как перестал путать %) А ты объяснишь, какое отношение имеет operator= к сборке мусора, и почему операции «равно» в ООП нет и не может быть? Питон с тобой не согласен.

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

кажется ты ещё не понял, что с таким подходом как ты предлагаешь, можно сравнивать что угодно с чем угодно, но только НЕ C++. Ибо в C++ по умолчанию нет НИЧЕГО. Встроенные фичи (даже если они есть) максимально простые и тривиальные. Такие как оператор копирования (который тупо переносит содержимое), или оператор new (который не менее тупо вызывает malloc() или что там в текущей системе за неё).

Мы вот тоже на жаве имеем метапрограммирование, функциональщину, множественное наследование и прямое управление памятью путем эмуляции всей это херни (или в твоей терминологии «сделали это сами»), но это ведь не повод утверждать, что полученное — это Java. Это какой-то метаязык, исходный код на котором находится исключительно в наших головах, а потом руками транслируется в код на жаве. Другой язык, не сама Жава.

вот в том-то и оно - в жаве это не принято. В отличие от C++, где ВСЁ приходится либо делать самому, либо использовать чужие наработки, которые к самому C++ имеют мало отношения.

Идея, мысль, алгоритм - они должны напрямую выражаться в терминах языка. Это когда ты хочешь отфильтровать коллекцию и пишешь «collection.sort», вместо написания эмуляции путем использования цикла.

именно. Потому в C++ нет, не было, и не будет никакого sort(). Но ты можешь заюзать STL, можешь заюзать ещё что-то, или даже сделать свой sort().

Я их уж 20 лет как перестал путать %) А ты объяснишь, какое отношение имеет operator= к сборке мусора

когда ты пишешь x = y, объект y выходит за пределы периметра, и мы теряем над ним контроль. И потому не можем отличить нужный объект от мусора.

Если нам нужна сборка мусора, то нам нужен особая операция =, которая не только копирует объект, но и сохраняет инфу о том, что у этого объекта получилась копия. И если уничтожается x, то сборщик мусора не будет уничтожать этот объект, т.к. знает, что есть копия y. А если копий нет, то можно и уничтожить объект, на который не ссылается ни одна переменная.

и почему операции «равно» в ООП нет и не может быть? Питон с тобой не согласен.

операция = в пайтоне совсем не простое копирование, а очень сложное преобразование.

Ибо в C++ по умолчанию нет НИЧЕГО

Кроме 500 страниц спеков, описывающих всякие извращения с оператором присваивания. Что такое ООП? Наличие ключевого слова class?

Будь C++ нормальным языком, в нём не было бы возможности переопределить оператор присваивания. Потому что этот оператор должен действовать единственным образом — скопировать структуру данных справа налево. Если это объект, так пусть просто скопирует все поля этого объекта. Если среди них есть какие-нибудь указатели и хочется скопировать не указатели, а данные по ним, то пусть программист определяет у класса метод Copy(), который будет явно вызываться.

И будет две различных операции, каждая для своей цели. a = b ≠ a = b.Copy()

операция = в пайтоне совсем не простое копирование, а очень сложное преобразование.

Если справа атомарный тип, он копируется. Если справа объект, то копируется ссылка на него. Вот и всё.

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

Отлично объяснил, почему С++ больше не нужен ж)

Байткод -> Ассемблеры -> Макроязыки (с ассемблерными вставками) -> Процедурные и прочие языки начала второго поколения (со вставками макросов и ассемблеров) -> Переходные объектно-ориентированные и функциональные языки (со вставками на процедурщине) -> Развитые ооп и фн языки (прямая поддержка рефлексии/интроспекции, прямая поддержка DSL и кодогенерации, contextual keywords, contextual code, etc) -> Декларативные языки с управляющими вставками

Твой С++ — остался где-то там в прошлом, в переходе от машинного кода к чему-то что может херачить человек. Отличный язык, года для 90-ого, все еще хороший для 98-ого. Погляди-ка на календарь, сейчас 2012. Сейчас даже пролог уже устарел. Через десять лет станет 2022, а еще через пару десятков лет мы будем старичками, а люди будут смеяться от одной мысли о ручном управлении написанием кода.

В С++ нету sort. В нем нету вообще ничего, что сейчас нужно. Поэтому он и не нужен //кэп

a = b.Copy()

бросай программирование - оно не для тебя

Если нам нужна сборка мусора, то нам нужен особая операция =, которая не только копирует объект, но и сохраняет инфу о том, что у этого объекта получилась копия.

Для консервативного сборщика, единственно возможного в Си/Си++, ничего подобного не нужно. Для не-консервативного... думаю, тоже не обязательно.

операция = в пайтоне совсем не простое копирование, а очень сложное преобразование.

Вообще-то это именно простое копирование, поверь старому Питон-прогеру. Но вопрос был не о копировании, а об операции сравнения:

drBatty> в ООП вообще нет и быть не может операции «равно»

бросай программирование - оно не для тебя

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

остался где-то там в прошлом

конечно, сейчас рулят ведь не C/Obj-C/C++, а Java и C#, правда рулят они как-то странно

В С++ нету sort

вот так новость

даже пролог

Как будто у пролога были шансы.

C рулит там, где его ниша — программирование всяких низкоуровневых вещей. Obj-C рулит на айфонах и только, да и то в последнее время использования этой какашки можно избегать и там.

А С++… популярен примерно по той же причине, что и пхп в вебе.

Это обычная практика в языке Go

это имеет смысл только в том случае, если Copy() вернет ссылку, и a будет просто ссылаться на новую копию, иначе будет оверхед на ровном месте, если уж и делать такой метод, то только b.Copy( a )

А С++… популярен примерно по той же причине, что и пхп в вебе.

конечно, всякие компиляторы, кады, фотошопы, топовые игры, браузеры и их движки, СУБД и пр. - обычные поделки

А С++… популярен примерно по той же причине, что и пхп в вебе.

конечно

А это и правда так %) На тот момент просто не было ничего лучше и скромнее по ресурсам.

всякие компиляторы, кады, фотошопы, топовые игры, браузеры и их движки, СУБД

Почти все «компиляторы, кады, фотошопы и браузеры» начали писаться 20 лет назад (или больше). А топовые игры - ниша относительно небольшая, да и там уже не чистый Си++.

На тот момент просто не было ничего лучше и скромнее по ресурсам.

лучше ЯП точно были, это любой анонимус с ЛОРа подтвердит ) а насчет «скромнее по ресурсам» - ничего не поменялось

Почти все «компиляторы, кады, фотошопы и браузеры» начали писаться 20 лет назад (или больше)

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

насчет «скромнее по ресурсам» - ничего не поменялось

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

Почти все «компиляторы, кады, фотошопы и браузеры» начали писаться 20 лет назад (или больше)

далеко не все

Примеры?

это показатель того, что никакие новые ЯП не способны произвести революцию

(пожимая плечами) А революций вообще было мало, и связаны они не с языками, а с парадигмами.

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

представь себе, ресурсов больше, но и те же браузеры теперь работают с HTML 5, а не тупо рендерят табличку с текстом, СУБД работают с гораздо большим объемом данных и т.д.

Примеры?

легко - вспомни тему про NoSQL, сам найдешь там примеры для СУБД, насчет компиляторов - вспомни хотя бы про clang, браузеры 20-летней давности это вообще раритеты и т.д.

(пожимая плечами) А революций вообще было мало

(делая удивленное лицо) да ладно

вспомни тему про NoSQL, сам найдешь там примеры для СУБД

CouchDB на Эрланге, Cassandra на Яве. Ниша Си++ всё сжимается.

насчет компиляторов - вспомни хотя бы про clang

Изначально они хотели интегроваться в GCC, так что особого выбора у них не было.

браузеры 20-летней давности это вообще раритеты и т.д.

Да ладно? Кодовая база IE примерно такого возраста, то же про Firefox и Opera.

А революций вообще было мало

(делая удивленное лицо) да ладно

Напомни мне штук 5 последних %)

CouchDB на Эрланге, Cassandra на Яве. Ниша Си++ всё сжимается.

кто-то говорил, что на других ЯП нет СУБД? они были еще до С++ (что логично), ничего с тех пор не поменялось, и странно делать вид, что новых СУБД на С и/или С++ почти нет, когда их легко можно найти в списке популярных, собс-но о чем и был разговор

Изначально они хотели интегроваться в GCC, так что особого выбора у них не было.

был - C + другой ЯП

Да ладно? Кодовая база IE примерно такого возраста, то же про Firefox и Opera.

я конечно исходный код IE/Opera не видел, не скажу, но webkit, например, взяв изначально KHTML, был полностью переписан с нуля, браузеры вроде Chrome/Safari etc. тоже написаны с чистого листа, Firefox с его XUL тоже не 20 лет, Gecko пожалуй тут самый старый, но и его еще рано записывать в клуб «за 20»

Напомни мне штук 5 последних %)

я забыл добавить один тег к своей фразе

Можно, просто нужно понимать последствия.

С точки зрения стандарта если ты сделаешь lock(), создашь там объект, и вызовешь unlock(), то после следующего lock() объект будет невалиден если окажется по другому адресу. Если надо его как-то подвинуть в памяти, то нужно использовать placement new с конструктором копирования, про которые типовое сишное API ничего не знает.

Неплоскую память типо как в win16 или 32-битовые интерфейсы дающие доступ к памяти сверх 2Гб ты через operator new/delete не заюзаешь.

Такое и имеет.

CouchDB на Эрланге, Cassandra на Яве. Ниша Си++ всё сжимается.

кто-то говорил, что на других ЯП нет СУБД?

Нет. Кто-то говорит, что ниша Си++ уменьшается (за счет проникновения туда managed-языков).

странно делать вид, что новых СУБД на С и/или С++ почти нет

Кроме Mongo, какие?

webkit, например, взяв изначально KHTML, был полностью переписан с нуля

«С нуля» - это значит «выбросили KHTML и написали всё заново», а такого не было. Понятно, что от изначального KHTML осталось мало или вообще ничего, но код переписывался частями.

я конечно исходный код IE/Opera не видел

В About IE 3.0 было сказано «разработано на основе NCSA Mosaic».

Firefox с его XUL тоже не 20 лет

Да блин, причем тут XUL (а так же {Spider,Trace,Ion}Monkey и прочее). Есть кодовая база, она постепенно дорабатывается, модифицируется, чистится и т.д. Но она никогда не выбрасывается полностью, и за счет этого остается написанной на том, на чем была изначально (или, как в случае GCC, может медленно перейти в другой язык).

браузеры вроде Chrome/Safari etc. тоже написаны с чистого листа,

Они оба на webkit, правильно? Странное у тебя понятие о «с нуля».

Если надо его как-то подвинуть в памяти, то нужно использовать placement new с конструктором копирования, про которые типовое сишное API ничего не знает.

про которые типовое сишное API ничего не знает.

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

давно с тобой не разговаривал, забыл, сколь ты любишь соскакивать с темы.

Нету никакого соскока. Разговор шел о возможностях которые дает перегрузка operator new. По стандарту operator new должен возвращать указатель, хендл вернуть он не имеет права. Если же он получит хендл, залочит кусок памяти по хендлу и вернет указатель, то хендл будет потерян. Следовательно, нужную логику на operator new реализовать невозможно, чтд. Уводом разговора с сторону было твое упоминание смарт-указателей. О смарт-указателях речь не шла, речь в ветке шла о перегрузке operator new. Я ясно выражаюсь?

Нет. Кто-то говорит, что ниша Си++ уменьшается

кто-то говорил «почти нет», ну ок

Кроме Mongo, какие?

из РСУБД отмечу drizzle, который уже лишь формально форк mysql, по факту - новая СУБД с новым кодом на С++, из встраиваемых - конечно sqlite, ну еще всякие redis, virtuoso, memcached, это если говорить про известные на С и С++, менее известных будет конечно побольше, но думаю их вспоминать нет смысла

В About IE 3.0 было сказано «разработано на основе NCSA Mosaic».

что не гарантирует, что в IE9 есть хоть строчка старого кода, и что он вообще на C++

Да блин, причем тут XUL (а так же {Spider,Trace,Ion}Monkey и прочее). Есть кодовая база, она постепенно дорабатывается, модифицируется, чистится и т.д

современные браузеры не монолитны, v8, xulrunner, *Monkey и пр. - вполне себе отдельные проекты, на базе которых написаны не только браузеры, и не только на С и С++

Они оба на webkit, правильно? Странное у тебя понятие о «с нуля».

если что webkit часть safari, а chrome чуть больше чем простая оболочка к нему, но да - «с нуля» некорректная формулировка в общем случае

осталось мало или вообще ничего, но код переписывался частями.

люди вон quake 2 на Java переписывали или sqlite, было бы желание - уйти на другой ЯП не так сложно, особенно, если надо лишь скопировать готовое, Apple и не такое проворачивала, вот только вариантов у них особо и не было, C/Obj-C/C++ - вот пожалуй и все

из РСУБД отмечу drizzle, который уже лишь формально форк mysql

что не гарантирует, что в IE9 есть хоть строчка старого кода

Похоже, ты и в самомо деле не понимаешь простых вещей. Ну и ладно.

redis, memcached

Это Си, не Си++.

virtuoso,

Если ты о http://en.wikipedia.org/wiki/Virtuoso_Universal_Server, то «The Virtuoso project was born in 1998 from a merger of the OpenLink data access middleware and Kubl RDBMS».

из встраиваемых - конечно sqlite

2000 год - не сказать, чтобы новая; Си, не Си++.

современные браузеры не монолитны, v8, xulrunner, *Monkey

v8 - это вообще из другого браузера, xulrunner содержит в себе копию Gecko, *Monkey вырос в кодовой базе Mozila и просто не мог быть на чем-то, кроме Си++ (по крайней мере, пока не взлетел Rust).

люди вон quake 2 на Java переписывали или sqlite, было бы желание

Никто и не говорил, что переписать невозможно.

уйти на другой ЯП не так сложно

Гг.

давно с тобой не разговаривал, забыл, сколь ты любишь соскакивать с темы.

Нету никакого соскока.

Еще бы ты признался.

Разговор шел о возможностях которые дает перегрузка operator new.

...после чего ты привел в пример сегментированную модель памяти Win16, которая ломает _абстрактную машину Си_, и по привычке полил Си++.

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

А ты не теряй его.

О смарт-указателях речь не шла, речь в ветке шла о перегрузке operator new. Я ясно выражаюсь?

Распределять память в сегментах Win16 можно с помощью оператора new. Я ясно выражаюсь?

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

А ты не теряй его.

Стандарт требует чтобы operator new возвращал void*. Какие-то обертки вокруг хендлов блока или сами хендлы оттуда возвращать нельзя.

Распределять память в сегментах Win16 можно с помощью оператора new.

Единственный прямой способ - явно выделить блок памяти нужного размера при помощи внешнего API, а потом разместить в ней объект при помощи placement new. Потом вызвать деструктор явно и удалить блок памяти при помощи внешнего API. Прямого способа скрыть эти телодвижения от клиента кода здесь не существует.

Похоже, ты и в самомо деле не понимаешь простых вещей. Ну и ладно.

просто ты придаешь некоторым вещам гипертрофированное значение, вот первый gcc был на паскале и что? а ведь «переезд» состоялся в рамках одного проекта, а не сознательного переписывания в новый продукт, как в drizzle

Это Си, не Си++.

спасибо, К.О., теперь перечитай предыдущие сообщения

2000 год - не сказать, чтобы новая

зато уже родились клоны на других ЯП - не взлетели

v8 - это вообще из другого браузера
xulrunner содержит в себе копию Gecko

К.О. сегодня в ударе

Гг.

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

вот первый gcc был на паскале и что?

http://gcc.gnu.org/wiki/History

Pastel (если ты о нем) вообще не был написан Столлманом и уж тем более не был «первым gcc»: «I concluded I would have to write a new compiler from scratch. That new compiler is now known as GCC"ю

Это Си, не Си++.

спасибо, К.О., теперь перечитай предыдущие сообщения

Я лучше перечитаю сообщение, на которое ответил изначально:

PlarFox> А С++… популярен примерно по той же причине, что и пхп в вебе.

wota> конечно, всякие компиляторы, кады, фотошопы, топовые игры, браузеры

И после этого ты приводишь мне продукты на Си.

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

Приведешь пример, где Яббл бы переписывал программы с одного языка на другой, да хоть какие-нибудь переписывания больших продуктов (нет, sqlite и quake2 не считаются большими)? Лично я слышал только о фейле Корела.

благо думать о совместимости и пр. тут не приходилось

Переезды Яббла m68k -> ppc и ppc -> x86 смотрят на тебя с непониманием.

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

А ты не теряй его.

Стандарт требует чтобы operator new возвращал void*. Какие-то обертки вокруг хендлов блока или сами хендлы оттуда возвращать нельзя.

Сделай глобальную таблицу, отображающую хэндл в void *, возвращай void *, и в delete находи хэндл и удаляй его. Такая очевидная мысль тебе в голову не приходила?

Единственный прямой способ - явно выделить блок памяти нужного размера при помощи внешнего API, а потом разместить в ней объект при помощи placement new.

И это тоже работа с «неплоской памятью» через new,

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

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

Будь C++ нормальным языком, в нём не было бы возможности переопределить оператор присваивания. Потому что этот оператор должен действовать единственным образом — скопировать структуру данных справа налево. Если это объект, так пусть просто скопирует все поля этого объекта. Если среди них есть какие-нибудь указатели и хочется скопировать не указатели, а данные по ним, то пусть программист определяет у класса метод Copy(), который будет явно вызываться.

если-бы это был просто оператор копирования, то сборщик мусора никогда-бы не узнал про копию. Но это ещё не самое печальное - проблема в том, что внутри класса нельзя даже выделить память, а потом в деструкторе её освободить - память будет освобождена дважды, что приведёт к UB. Ведь указатель ты предлагаешь «просто копировать».

И будет две различных операции, каждая для своей цели. a = b ≠ a = b.Copy()

и захрена? лично мне достаточно operator=()

Сделай глобальную таблицу, отображающую хэндл в void *, возвращай void *, и в delete находи хэндл и удаляй его. Такая очевидная мысль тебе в голову не приходила?

Костыль среди океана плюсовых костылей. BTW, я видимо не такой говнокодер как ты, поэтому мне первой на ум пришла мысль как его отыскивать за атомарное время без привлечения глобальных структур. Надо выделить sizeof(HANDLE) + sizeof(T) и разместить этот хендл перед блоком. Вернуть указатель указывающий на первый байт после HANDLE.

Единственный прямой способ - явно выделить блок памяти нужного размера при помощи внешнего API, а потом разместить в ней объект при помощи placement new.

И это тоже работа с «неплоской памятью» через new,

Речь в ветке идет о практической пользе от возможности перегрузки operator new в пользовательском типе. А placement new это глобальный оператор.

Если справа атомарный тип, он копируется. Если справа объект, то копируется ссылка на него. Вот и всё.

a, b = b, a

что слева/справа?

Для консервативного сборщика, единственно возможного в Си/Си++, ничего подобного не нужно. Для не-консервативного... думаю, тоже не обязательно.

ошибаешься.

Вообще-то это именно простое копирование, поверь старому Питон-прогеру. Но вопрос был не о копировании, а об операции сравнения:

drBatty> в ООП вообще нет и быть не может операции «равно»

я говорил про операцию копирования, которая в C/C++ называется «равно». Операция сравнения это «==». Её в ООП тоже нет, а есть метод operator==().

Для консервативного сборщика, единственно возможного в Си/Си++, ничего подобного не нужно. Для не-консервативного... думаю, тоже не обязательно.

ошибаешься.

Ошибаюсь насчет чего - консервативного или не-консервативного?

drBatty> в ООП вообще нет и быть не может операции «равно»

я говорил про операцию копирования, которая в C/C++ называется «равно».

Операция копирования в Си++ называется «присвоить».

I concluded I would have to write a new compiler from scratch. That new compiler is now known as GCC

ты «случайно» не заметил такую фразу - «but I managed to adapt and use the C front end that I had written», т.е. имело место именно переписывание, пусть и далеко не всего кода, как и, внезапно, в том же drizzle, где не ставили цель сделать обычный форк вроде mariadb, например, а сели и написали новый код

Я лучше перечитаю сообщение, на которое ответил изначально:

ок, только не забывай читать и другие

И после этого ты приводишь мне продукты на Си.

предварительно написав про С, так бывает - разговор уходит в сторону, особенно если кто-то комментирует со стороны, рад что мы разобрались

Приведешь пример, где Яббл бы переписывал программы с одного языка на другой

ты не поверишь, но у Яббла есть своя ОС, в ней есть программы, и они как ни странно «переписывались с одного языка на другой», почитай про finder, например, это такой file manager, легко нагуглишь

Переезды Яббла m68k -> ppc и ppc -> x86 смотрят на тебя с непониманием.

они смотрят на тебя, переписывание KHTML к ним отношения не имеет

А это и правда так %) На тот момент просто не было ничего лучше и скромнее по ресурсам.

как и сейчас...

Почти все «компиляторы, кады, фотошопы и браузеры» начали писаться 20 лет назад (или больше). А топовые игры - ниша относительно небольшая, да и там уже не чистый Си++.

C++ никогда и не был «чистым». Он всегда был расширяем, причём и вверх и вниз.

а сели и написали новый код

под этим подразумевается и переписывание с С на С++, если вдруг опять будет недопонимание

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

но для решения той же задачи тебе понадобится на два порядка больше ресурсов. Игрушкой на 640х480 пикселей ты никого уже не удивишь. Разве что на Nokia3110.

распиаренное говнище.

ты «случайно» не заметил такую фразу - «but I managed to adapt and use the C front end that I had written»

И тем не менее, никакой «первой версии GCC на Pascal» не существовало.

И после этого ты приводишь мне продукты на Си.

предварительно написав про С

Из продуктов на Си++, написанных после 2000 года, имеем Монго. И игры, да.

ты не поверишь, но у Яббла есть своя ОС, в ней есть программы, и они как ни странно «переписывались с одного языка на другой», почитай про finder, например

Finder - это, конечно, мощно. Уровня серьезного CAD, не меньше. А под «переписывались» имеется в виду «Finder was rewritten using the Cocoa API» или переписывание на Си++ 1991 года?

думать о совместимости и пр. тут не приходилось

Переезды Яббла m68k -> ppc и ppc -> x86 смотрят на тебя с непониманием.

они смотрят на тебя, переписывание KHTML к ним отношения не имеет

А, то есть переписанный KHTML мог быть несовместимым. Okay.

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

но

Что «но»? Было сказано, что насчет ресурсов ничего не поменялось.

для решения той же задачи тебе понадобится на два порядка больше ресурсов.

Какой «той же»? Ядро стало использовать в 100 раз больше памяти? Компиляторы? X? xterm и mc? Emacs?

А вот fullhd видео «раньше» просто не было.

А топовые игры - ниша относительно небольшая, да и там уже не чистый Си++.

C++ никогда и не был «чистым».

Мне было бы интересно услышать твое определение «чистого» Си++. Сам я говорил о том, что в движках используется несколько языков.

И тем не менее, никакой «первой версии GCC на Pascal» не существовало.

ок, но как видишь «форки» вполне допускают смену ЯП

Из продуктов на Си++, написанных после 2000 года, имеем Монго. И игры, да.
Finder - это, конечно, мощно. Уровня серьезного CAD, не меньше.
А, то есть переписанный KHTML мог быть несовместимым. Okay.

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

никакой «первой версии GCC на Pascal» не существовало.

ок, но как видишь «форки» вполне допускают смену ЯП

GCC является форком Pastel? Okay.

твои аргументы слишком серьезны и достоверны

Это очищенная версия твоих аргументов.

man кавычки, ну и не pastel напрямую, а промежуточного форка pastel, кода от pastel в результате в gcc нет, но для тебя это же не аргумент - тебе важней «кодовая база» и ее развитие

Это очищенная версия твоих аргументов.

а мои - твоих, итого ты получил свои «дистиллированные» аргументы

тебе важней «кодовая база» и ее развитие

Ее инерция.

Нету никакого соскока. Разговор шел о возможностях которые дает перегрузка operator new. По стандарту operator new должен возвращать указатель, хендл вернуть он не имеет права. Если же он получит хендл, залочит кусок памяти по хендлу и вернет указатель, то хендл будет потерян. Следовательно, нужную логику на operator new реализовать невозможно, чтд. Уводом разговора с сторону было твое упоминание смарт-указателей. О смарт-указателях речь не шла, речь в ветке шла о перегрузке operator new. Я ясно выражаюсь?

не ври. Изначально речь шла о смарт-указателях И презагрузке new.

одно без другого не имеет смысла в C++.

Ошибаюсь насчет чего - консервативного или не-консервативного?

у тебя взаимоисключающие параграфы в одном предложении:

Для консервативного сборщика, единственно возможного в Си/Си++, ничего подобного не нужно. Для не-консервативного... думаю, тоже не обязательно.

как можно такой бред оспаривать?

Операция копирования в Си++ называется «присвоить».

операция копирования в C++ называется копированием. Есть также operator=() и конструктор копирования. Но это не совсем то.

Какой «той же»? Ядро стало использовать в 100 раз больше памяти? Компиляторы? X? xterm и mc? Emacs?

для задачи вывода на экран изображения. Хотя бы. Экран стал несколько больше, чем 640х480. xterm, mc, и даже emacs никогда не тормозили, да и сейчас не тормозят. Да только никому они не нужны.

Такие дела.

А вот fullhd видео «раньше» просто не было.

ага. было не full и не hd.

C++ никогда и не был «чистым».

Мне было бы интересно услышать твое определение «чистого» Си++. Сам я говорил о том, что в движках используется несколько языков.

учись читать - как я могу дать определение того, чего (по моим же словам) никогда не было? Свои фантазии объясняй сам, пожалуйста.

Ошибаюсь насчет чего - консервативного или не-консервативного?

у тебя взаимоисключающие параграфы в одном предложении:

От человека, который не понял фразу «stop'n'copy gc», это звучит особенно веско.

xterm, mc, и даже emacs никогда не тормозили, да и сейчас не тормозят.

Ну слава ТНБ, хоть какие-то задачи не требуют в 100 раз больше.

Да только никому они не нужны.

Говори за себя.

как я могу дать определение того, чего (по моим же словам) никогда не было?

То есть определение дать не можешь, но знаешь, что не было. Бывает.

От человека, который не понял фразу «stop'n'copy gc», это звучит особенно веско.

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

Говори за себя.

за себя и говорю - юзаю VIM... Такие дела...

То есть определение дать не можешь, но знаешь, что не было. Бывает.

и не говори - например я не могу дать определение концу света. Но таки знаю, что в моей реальности его ещё не было. А ты можешь?

что слева/справа?

Тьюплы. Но это не отменяет того факта, что a просто присвоится значение b и b просто присвоится значение а.

Тьюплы. Но это не отменяет того факта, что a просто присвоится значение b и b просто присвоится значение а.

ну тогда расскажи, во что это «просто» скомпиллируется.

одно без другого не имеет смысла в C++.

Обычно в качестве достоинства выставляют ортогональность. А у плюсофагов вон оно как.

одно без другого не имеет смысла в C++.

Обычно в качестве достоинства выставляют ортогональность. А у плюсофагов вон оно как.

как «так»? В других ЯП дополнительная функциональность гвоздями прибита к операции «равно» (копирование), а в C++ этого нет. И это хорошо, ибо нет оверхеда в большинстве случаев, когда никакие сборщики мусора не нужны. А когда нужны - можно это реализовать.

Обычно в качестве достоинства выставляют ортогональность. А у плюсофагов вон оно как.

В других ЯП дополнительная функциональность гвоздями прибита к операции «равно» (копирование), а в C++ этого нет.

А что там в operator= можно такого сделать? Сконструировать временный объект, а потом обменять pimpl-ы? Дык в других языках объекты и являются своими pimpl-ами.

А что там в operator= можно такого сделать? Сконструировать временный объект

зачем? Например мне тут доказывали, что gc в рамках C++ невозможен, доказательство сводилось к коду, в котором как раз и вызывалась функция копирования «равно». При этом, для доказывающего было очевидным, что = просто тупо копирует, а значит сборщик мусора не знает, что у объекта появилась копия. И таким образом, gc не сможет этот мусор собрать. Но на самом деле вызывался конструктор копирования, который и имеет возможность сообщить сборщику о факте появления новой копии. В самом примитивном варианте можно увеличить счётчик ссылок на 1, и вообще ничего не копировать, а просто использовать старый объект.

В самом примитивном варианте можно увеличить счётчик ссылок на 1, и вообще ничего не копировать, а просто использовать старый объект.

Инфраструктурного кода который не относится к решаемой программистом проблеме существовать не должно.

Инфраструктурного кода который не относится к решаемой программистом проблеме существовать не должно.

какая разница, куда загнать данный код? В код сишарпа, или в код базового класса в C++? Когда я решаю какую-то проблему пользуясь этим базовым классом, я совсем не интересуюсь, каким образом он считает сцылки, и вообще, считает-ли их.

А код он всё равно _будет_, и мне проще иметь возможность его менять.

Когда я решаю какую-то проблему пользуясь этим базовым классом, я совсем не интересуюсь, каким образом он считает сцылки, и вообще, считает-ли их.

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

А код он всё равно _будет_, и мне проще иметь возможность его менять.

Ты просто лентяй и тебе влом разбираться в больших сложных фреймворках.

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

с чего он будет падать-то? пойми, в C++ технологию сборки мусора можно применять _локально_, в пределах одного какого-то класса, которому это _действительно_ нужно. В большинстве случаев необходимости в gc нет никакой. Вот в C++ её и не применяют (в 95% классов). Потому, если уж обнаружился какой-то глюк gc, то его можно с лёгкостью локализовать и исправить. В отличие от...

Ты просто лентяй и тебе влом разбираться в больших сложных фреймворках.

...и это тоже.

с чего он будет падать-то? пойми, в C++ технологию сборки мусора можно применять _локально_, в пределах одного какого-то класса, которому это _действительно_ нужно.

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

Ты просто лентяй и тебе влом разбираться в больших сложных фреймворках.

...и это тоже.

Ну я конечно понимаю что легче заниматься решением уже решенных проблем чем нерешенных.

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

что в этом плохого?

Ну я конечно понимаю что легче заниматься решением уже решенных проблем чем нерешенных.

дело не в этом. Знаешь, почему до сих пор не сделали автомобиль для всех? Просто потому, что потребности у всех разные. Кому-то нужен порше, кому-то москвич, а кому-то камаз. И именно по этому до сих пор не придумали идеальную стратегию распределения памяти - она в 95% случаев будет НЕ идеальной, и в 50% случаев - унылым говном.

К счастью, в бОльшей части кода можно обойтись и неоптимальным распределителем, лишние 5% памяти и прочих ресурсов - небольшая плата за универсальность. Но не всегда, и не везде.

Вот возьми тот же алгоритм Бейкера, который здесь обсуждался. Он отлично работает (хотя и отъедает вдвое больше памяти чем нужно) пока памяти достаточно. Но как только программа подходит к пределу, этот ваш stop'n'copy вешает вашу программу намертво. Не, я согласен, это тоже решение. Но согласись, не всегда оно допустимо.

В итоге, я не смогу написать даже программу управления сливным бачком в унитазе(на сишарпе) - надо СРОЧНО клапан открывать, а оно мне тут мусор собирает. Я понимаю, такое будет происходить не часто, но тем не менее это будет не слишком-то и приятно. Такие дела.

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

что в этом плохого?

Ну то есть ты в универсальной стратегии управления ходом выполнения не видишь ничего плохого, а в универсальной стратегии управления памятью - видишь. Хотя есть асинхронная модель где определить владельца данных передаваемых от обработчика к обработчику однозначно бывает нелегко.

Знаешь, почему до сих пор не сделали автомобиль для всех? Просто потому, что потребности у всех разные. Кому-то нужен порше, кому-то москвич, а кому-то камаз. И именно по этому до сих пор не придумали идеальную стратегию распределения памяти - она в 95% случаев будет НЕ идеальной, и в 50% случаев - унылым говном.

Отговорка программистов-прокрастинаторов которые изучают Computer Science за деньги фирмы вместо того чтобы решать проблемы фирмы. И при этом не обращают внимания на возможности библиотек, за которые уже фирмой уплачены деньги. То-то Том Кайт когда его нанимают спасать очередной фейловый проект первым делом вычищает унылые костыли заменяющие функциональность которая в сервере уже есть, спроектирована и написана экспертами и хорошо отлажена.

 0 LOAD_FAST                1 (b)
 3 LOAD_FAST                0 (a)
 6 ROT_TWO             
 7 STORE_FAST               0 (a)
10 STORE_FAST               1 (b)

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

Ну то есть ты в универсальной стратегии управления ходом выполнения не видишь ничего плохого, а в универсальной стратегии управления памятью - видишь.

синхронную модель мне никто не навязывает, он только «поощряется», и это хорошо, ибо синхронная модель тупо проще, а стало быть асинхронную следует применять лишь тогда, когда нужно. А вот управление памятью в сишарпе такое, какое есть. И ничего я с ним поделать не могу. Разве что сишарп перекомпиллирую. Но это невозможно, ибо сырцов нет, да если они и были, то тут ведь пишут, что сишарп докомпилливается у клиента...

Хотя есть асинхронная модель где определить владельца данных передаваемых от обработчика к обработчику однозначно бывает нелегко.

я знаю. Именно в таких случаях и есть смысл применять сборку мусора. Однако, накой эта сборка например для выделения памяти под строчку, которую никто, кроме этого кода всё равно не будет использовать, да и не сможет, даже если захочет? А таких строчек 99% ваще-то.

Отговорка программистов-прокрастинаторов которые изучают Computer Science за деньги фирмы вместо того чтобы решать проблемы фирмы. И при этом не обращают внимания на возможности библиотек, за которые уже фирмой уплачены деньги. То-то Том Кайт когда его нанимают спасать очередной фейловый проект первым делом вычищает унылые костыли заменяющие функциональность которая в сервере уже есть, спроектирована и написана экспертами и хорошо отлажена.

Ой, да ладно!

И где я к этому призывал? Лично я не вижу ничего плохого например в STL, и прочих библиотеках (в т.ч. и коммерческих), вот только я также не вижу никакой необходимости прибивать гвоздями этот функционал к самому языку. К примеру мне и в голову не придёт писать собственный std::string - именно по озвученной тобой причине. Кроме того, если я уж сподобился юзать например Qt, то я буду юзать также и QString, а не что-либо другое. Но на кой хрен мне сдался String в самом ЯП?? Ну а свой класс(шаблон) my_string я если и буду писать, то только в том случае, если:

1. у меня какие-то особые строки, СОВСЕМ не такие, на которые заточен std::string

2. и кроме того, работа с этими строками занимает ЗНАЧИТЕЛЬНУЮ часть ресурсов.

Если хоть один из этих пунктов не выполнен, я даже думать не стану о своём велосипеде.

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

откуда ему это знать? Каким образом сборщик мусора узнаёт, что данные в переменной можно безболезненно удалять? Если мы используем подсчёт ссылок, то ответ очевиден - тогда, и только тогда, когда счётчик ссылок будет равен 0. С другой стороны, кто этот счётчик увеличивает? Ответ также очевиден - операция «равно» и увеличивает. Вот только ты этого не видишь. И не только не видишь, но и не можешь никак контролировать.

синхронную модель мне никто не навязывает, он только «поощряется», и это хорошо, ибо синхронная модель тупо проще, а стало быть асинхронную следует применять лишь тогда, когда нужно

Вот написание гуя это прямо такая вот редкая задача которая редко нужна, например. И поручают ее обычно только выпускникам Berkley и MIT.

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

Выдели себе для своих CERN-овских рассчетов огромный массив и размести его в статическом scope. GC его трогать не будет.

1) у меня какие-то особые строки, СОВСЕМ не такие, на которые заточен std::string. 2) и кроме того, работа с этими строками занимает ЗНАЧИТЕЛЬНУЮ часть ресурсов.

Ты конечно же можешь привести примеры таких задач? Или это абстрактные построения?

Вот написание гуя это прямо такая вот редкая задача которая редко нужна, например. И поручают ее обычно только выпускникам Berkley и MIT.

а если мне нужен гуй, я его не стану писать. Зачем? Мало что-ли тулкитов на любой вкус? А уж прицепить свою функцию к чекбоксу я как-нибудь осилю.

Выдели себе для своих CERN-овских рассчетов огромный массив и размести его в статическом scope. GC его трогать не будет.

открой наконец Кнута, и узнай о разряжённых матрицах. Причём без всяких GC.Искусство программирования, том 1, 2.2.6

Ну и освежи для себя 2.3.5 оттуда-же, что-бы не говорить ерунды (кстати, Кнут на ассемблере захерачил GC, и ничего - работает даже. Так то)

Ты конечно же можешь привести примеры таких задач? Или это абстрактные построения?

да что-то в голову не приходит ничего интересного. Я же говорю, IRL достаточно STL или средств тулкита. Когда-то давно пришлось делать...

Про сборщик мусора я уже говорил - мне как-то понадобился вырожденный сборщик, который ничего не собирает. Но удаление там тоже таки было (просто память не освобождалась, типа как в tar --delete или CD-R).