Cудьба Mono

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

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

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

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

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

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

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

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

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

Общеупотребимое название таки «шарп»

Ладно, диезом буду называть.

Называть крестами C# - вообще непонятно откуда такое можно было взять?

# == решетка из четырех крестов ☺

Ну да хрен с ним, можешь привести пару примеров из личной практики написания кода?

На этом г. я ничего не делал, не делаю и не собираюсь. В профиле — ссылки на мои велосипеды на sourceforge и гуглокоде. Все на сях. Если бы я это делал на диезе, задолбался бы вусмерть!

Я не знаю какой сборщик реализован в 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() чтобы блок памяти мог перемещаться и уйти в своп при необходимости. Адреса живых С++-ных объектов в функции манипулирующие блоками памяти передавать нельзя.

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

открой для себя перезагрузку new, и забей на эти стратегии.

В том-то и дело, что в ваших недоязыках стратегия всего ОДНА, а в C++ можно взять ЛЮБУЮ. По умолчанию там самая простая - явно создаём объект, потом явно его удаляем. Это просто, быстро, экономично, но не всегда удобно. Ну и кто мешает в случаях, когда это неудобно, реализовать любую другую стратегию? Ту самую, которая более удобна.

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

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

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

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

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

Что-нибудь посложнее хелловорлдов писал?

ты ответишь наконец на вопрос: зачем тебе нужен такой недоделанный код?

ngen используется для убыстрения запуска часто запускаемых сборок, т.к. исключает стадию jit-компиляции. RAM он не жрет.

ну расскажи мне тупому, КАК он работает? Хранит часто запускаемые сборки в астрале?

Общеупотребимое название таки «шарп»

подтверждаю. Знакомые маздайные быдлокодеры _говорят_ именно «сишарп», и никак иначе. Они похоже по ночам именно на него и фапают...

ngen используется для убыстрения запуска часто запускаемых сборок, т.к. исключает стадию jit-компиляции. RAM он не жрет.

ну расскажи мне тупому, КАК он работает? Хранит часто запускаемые сборки в астрале?

Почему в астрале? В кэше.

На этом г. я ничего не делал, не делаю и не собираюсь.

- Абраша, вы Моцарта любите?
- Нет, говно страшное
- Как же так! А вы где слушали?!
- А мне Рабинович напел
(С)

В профиле — ссылки на мои велосипеды на sourceforge и гуглокоде. Все на сях. Если бы я это делал на диезе, задолбался бы вусмерть!

ссылка на гуглокод не работает, на sf ничего безумно сложного и нереализуемого на C# не увидел. На C# может даже попроще было бы кое-где.

Нкто тебя не спрашивает что тебе нужно. Есть практическая необходимость заюзать интерфейс, мапящий страницы по требованию. Все, С++ в ауте, юзаем 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 можно вернуть только адрес, но не дескриптор. Впрочем, это вполне можно обойти для случая мапинга по запросу.

ты ответишь наконец на вопрос: зачем тебе нужен такой недоделанный код?

man «программирование управляемое данными»

ну расскажи мне тупому, КАК он работает? Хранит часто запускаемые сборки в астрале?

На винте, где же еще?

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

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

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

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

В том-то и дело, что в ваших недоязыках стратегия всего ОДНА, а в C++ можно взять ЛЮБУЮ. По умолчанию там самая простая - явно создаём объект, потом явно его удаляем.

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

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

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

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

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

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

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

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

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

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

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

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

Почему в астрале? В кэше.

а кеш - в астрале? Ведь:

RAM он не жрет.

пруфлинк: Cудьба Mono (комментарий)

в каком смысле «манипулировать»? Если ты написал 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, и как это будет работать я не знаю, и знать не хочу. Мы про сборщик мусора, а не про костыли для говнокода рассуждаем.

пруфлинк: Cудьба Mono (комментарий)

Не распарсил, это к чему?

Похоже, Абсурдег намекает на то, что из 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).