On 2012-04-14 14:42, M.M. wrote:
> Jeśli coś (jakiś inny język,
> albo zarządca) potrafi ten problem rozwiązać, to to coś prawdopodobnie
> zostało napisane właśnie w C albo w C++.

Co to ma do rzeczy?

> Wystarczy że za każdym razem przed
> użyciem wskaźnika aplikacja poprosi o ten wskaźnik jakąś warstwę pośrednią.

To oznacza przeraźliwy burdel w kodzie. Zamiast skupić się na algorytmie
bedziesz w kółko przeliczał wskaźniki co oznacza dodatkową, nienaturalna
dla C/C++ składnię. Oczywiście wszystko można opakować w klasy (sam tak
mam) ale co z tego - dalej jest nienaturalne.

> Wtedy warstwa pośrednia może dowolnie realokować przydzieloną pamięć.

To szczególnie łatwe kiedy na uC pracuje dodatkowo np. dma.

> W
> przypadku aplikacji wielowątkowych trochę trudniejsza sprawa. Aplikacja
> jeszcze musi powiedzieć zarządcy że już nie używa danego wskaźnika, aby
> ten wiedział które obszary w danej chwili może bezpiecznie realokować.

Właśnie wynadujesz kwadratowe koło. Aplikacja *nie* powinna nic o
pamięci wiedziec poza tym że może jej użyć. Inaczej wrócą czasy jak
przeliczanie segmentów w gównianym 8086.

> Tak
> czy inaczej da się to rozwiązać i nie wydaje się to zbytnio skomplikowane.

Walcz więc. Jesli zrobisz to w sposób który nie kradnie cykli w
systemach RT to zbawisz cale pokolenia programistów uC. I nie, nie można
wziąść wiekszego procka.

> Ale właśnie tak jak powiedziałem na początku, jakieś środowisko taki mechanizm
> może zapewniać i programista który tego problemu nie przewidzi nie zrobi
> sobie krzywdy, a programista w C/C++ musi od razu tak aplikację zaprojektować.

Nie da się zaprojektować sensownie aplikacji, kiedy musisz co instrukcję
sprawdzać czy ten wskaźnik to dalej jest ten sam co przed chwilą.