век живи, век учись...

[Guffy]

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

[Ull9]

ну так есть стандарт, и есть его толкования и разьяснения, кто его знает, может, и даже наверняка, этот вопрос уже поднимался на C++ Standart Cometee (или как там называется святой синод). и уже толкователи Великого Стандарта уже на этот вопрос и ответили.

я же привел этот прикол не с потолка а с конференции c++.moderated.
что само по себе означает, что так оно и есть.

а привыкать к флэт модели и считать что других нет и не может быть - это нехорошо.

[Guffy]

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

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

[Ull9]

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

а вы тут "не досуг". да и еще ворчите, что нефик морочить голову.

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

[Guffy]

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

[Newton]

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

[THRESHE]

Сегодня искал утечки памяти в своем проекте и вот наткнулся на совсем непонятную вещь.

	char *p = "Helloewwkaofapwjgfipjagf";
	delete []p;

Этот код приводит к крашу после delete []p
Либо я забыл как пользоваться простым чаром вместо QString либо глюк студии...

[THRESHE]

Видимо таки глюк студии так как Xcode проглотил все то же самое без проблем

[Guffy]

Сегодня искал утечки памяти в своем проекте и вот наткнулся на совсем непонятную вещь.

	char *p = "Helloewwkaofapwjgfipjagf";
	delete []p;

Этот код приводит к крашу после delete []p
Либо я забыл как пользоваться простым чаром вместо QString либо глюк студии...

и правильно приводит. "Helloewwkaofapwjgfipjagf" - литерал. лежит в PE32 в секции rdata. и совсем не в куче. так что странно к памяти не из кучи применять delete (или free)

[homo ludens]

Видимо таки глюк студии так как Xcode проглотил все то же самое без проблем

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

[THRESHE]

и правильно приводит. "Helloewwkaofapwjgfipjagf" - литерал. лежит в PE32 в секции rdata. и совсем не в куче. так что странно к памяти не из кучи применять delete (или free)

Да в принципе и с обычно выделенной памятью было то же самое. Например

char* p = new char[10];
delete []p;

Тоже приводило к крашу

[Newton]

Да в принципе и с обычно выделенной памятью было то же самое. Например

char* p = new char[10];
delete []p;

Тоже приводило к крашу

может студия ненастоящая
так должно работать.

[lexar]

Да в принципе и с обычно выделенной памятью было то же самое. Например

char* p = new char[10];
delete []p;

Тоже приводило к крашу

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

[THRESHE]

Прикалываешь?

Нет

Может в Qt перегружен оператор delete. Буду на работе во вторник посмотрю...

[homo ludens]

Да в принципе и с обычно выделенной памятью было то же самое. Например

char* p = new char[10];
delete []p;

Тоже приводило к крашу

При разрушенной куче такое может быть вполне. Где-то раньше встретилось неправильное обращение к памяти а сработало потом.
Не знаю как по стандарту то во многих системах есть функции heap consistency checking (в GNU это функции mcheck/mprobe). Попробуй вызывать такие проверки перед удалением.

[Newton]

_heapchk в 2005 студии

[Ull9]

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

http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!378.entry

[Guffy]

занятная выходит картина кстати

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

struct A
{
	A(int v):i(v){
		std::cout<<__FUNCTION__<<' '<<i<<std::endl;
	}
	~A(){
		std::cout<<__FUNCTION__<<' '<<i<<std::endl;
	}
	int i;
	operator int() const {
		return i;
	}
	A& operator=(const A& a)
	{
		std::cout<<__FUNCTION__<<std::endl;
		i=a.i;
		return *this;
	}
};

class B
{
	const A& m_a;
public:
	B(const A& a): m_a(a){
	}
	B& operator=(const B& b){
		const_cast<A&>(m_a)=b.m_a;
		return *this;
	}
	operator int() const {
		return m_a.i;
	}
};

A foo(int v)
{
	return A(v);
}

int _tmain(int argc, _TCHAR* argv[])
{
	{
		A a1(1);
		A a2(2);
		B b1(a1);
		B b2(a2);
		std::cout<<a1<<std::endl; 
		std::cout<<a2<<std::endl; 
		std::cout<<b1<<std::endl; 
		std::cout<<b2<<std::endl; 
		b1=b2;
		std::cout<<a1<<std::endl; 
		std::cout<<a2<<std::endl; 
		std::cout<<b1<<std::endl; 
		std::cout<<b2<<std::endl; 
	}
	{
		B b3(A(3));
		std::cout<<b3<<std::endl; 
	}
	{
		B b4(foo(4));
		std::cout<<b4<<std::endl; 
	}
	{
		const A& a5=foo(5);
		std::cout<<a5<<std::endl; 
	}
	return 0;
}

такая картина:

A::A 1
A::A 2
1
2
1
2
A::operator =
2
2
2
2
A::~A 2
A::~A 2
A::A 3
A::~A 3
3
A::A 4
A::~A 4
4
A::A 5
5
A::~A 5

зы: за одно тут протестировал такую задачку. как-то хотел сделать в классе конст-референс поле на другой тип. и вот в оператора присваивания оказывается нельзя так просто присвоить ссылку. а const_cast<A&>(m_a)=b.m_a; ведет к присваиванию самого типа А (да и без const_cast тоже - присвоение типа. только компилировать не хочет) . тогда я плюнул и поменял на указатель.

[homo ludens]

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

http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!378.entry

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

Причем рекомендация avoid making the implementation classes' destructors virtual at all выглядит как-то тоже стремно. Да и компилятор ворнингами выход гадит...

Вот уж действительно - в жизни все не так, как на самом деле (с)

тогда я плюнул и поменял на указатель.

Вот-вот, у меня та же история.

[Guffy]

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

Причем рекомендация avoid making the implementation classes' destructors virtual at all выглядит как-то тоже стремно. Да и компилятор ворнингами выход гадит...

Вот уж действительно - в жизни все не так, как на самом деле (с)

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

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

struct A
{
	A() { std::cout<<__FUNCTION__<<std::endl; }
	~A() { std::cout<<__FUNCTION__<<std::endl; }
};
struct B: public A
{
	B() { std::cout<<__FUNCTION__<<std::endl; }
	~B() { std::cout<<__FUNCTION__<<std::endl; }
};
struct C
{
	C() { std::cout<<__FUNCTION__<<std::endl; }
	virtual ~C() { std::cout<<__FUNCTION__<<std::endl; }
};

struct D: public C
{
	D() { std::cout<<__FUNCTION__<<std::endl; }
	~D() { std::cout<<__FUNCTION__<<std::endl; }
};

B refB() { return B(); }
D refD() { return D(); }
B* newB() { return new B(); }
D* newD() { return new D(); }


int _tmain(int argc, _TCHAR* argv[])
{
	{
		const A& a=refB();
	}
	{
		const C& c=refD();
	}
	{
		const A* a=newB();
		delete a;
	}
	{
		const C* c=newD();
		delete c;
	}
	return 0;
}

дает

A::A
B::B
B::~B
A::~A
C::C
D::D
D::~D
C::~C
A::A
B::B
A::~A
C::C
D::D
D::~D
C::~C

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

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