здрасти...объясните плиз

создаем что-то типа буфера

char buf[100];-100 чаров
потом из этой памяти берем определенное число
char * p=new (buf)char[120]-чаров

почему компилятор не выдает ошибки...разве тут не будет переполнения..
даже если for'ом заполнить область на которую ссылается p...ошибки тоже не возникает...
в чем прикол...мож я что недопонял :qstn

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

от оно как..лан спасибо вопрос исчерпан... 

Добавлено @ 17:28 
ух ты какой кавардак будет если напортачить...  

 Не хочешь сам контролировать доступ к памяти - используй managed технологии. Такие как Java и .NET

нет уж...я привык думать сам!

Вместо массивов используй стандартный контейнер vector из STL. Тогда не придется следить за индексами...
Там еще и list eсть и stack и queue...  

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

странный вопрос

на стеке. buf указывает на начало

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

Если повезёт - может пролететь   Управление паметью непостижимо...

у меня в VS2005 выдает, C2660


даже если напишешь

то это как "повезет-не повезет"

В VS2005 деьаг версия успешно компилится и успешно вылетает. Самое интересное, что релиз тупо выводит три восклицтаельных знака   

И как такое смогло скомпилиться? Я что-то не понял...


  
Блин! Я что, перестал русский язык знать?! Что не пост - то ошибка в родном языке! Иногда править ленюсь, а потом стыдно! Наверное это программерская болезнь...

Это сообщение отредактировал(а) Anikmar - 7.2.2007, 20:50

Откуда взялся такой синтаксис ?

threef, я привел цитату Любителя - выше моего поста.... Он написал, что компилится нормально, а я удивился - как такое может скомпилиться?

а я из loopback-а, с первого поста. 
Компилится, работает 
остается предложить сделать delete [] p
Пойду за мылом и веревкой.

Тьфу, это я уже запутался...
char * p=new (buf)char[120]
Эта конструкция ничего не нарушает.
Мы приводим указатель на char к указателю на char - так как buf в чистом виде является именно этим.

В языке Си имя массива без скобок является указателем на начало массива.

так что 
char *b
char bb[10]

b и bb эквивалентны.

это все ясно....но не потеме..



не говори сам в шоке..

там кто-то говорил что на VC ошибка при компиляции возникает см. пост 1
так на BC++ 6 голяк...даже не заикнулся  ..

хорошо я так для прикола решил проверить...теперь буду внимательно_ОЧЕНЬ_этим пользоваться...
а то в проге лям такой допустишь, и до нового года искать ошибку будешь...  

ничего мы не приводим
эта конструкция placement new называется

с чего это вдруг? это разные типы и никакой эквиваленции быть не может
другое дело, что компилятор неявно прииводит char[] к char* в некоторых случаях

Может я неправильно выразился.
Имя массива является указателем.
Некоторое исключение составляет явное определение размера массива.
Запись такого вида:


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

а не константным указателем случайно? (это про отличие b и bb)

1. Имя массива является конст антным указателем - этог только в С было...
В С++ имя массива приводится к указателю в некоторых случаях...
2. Не советую использовать такие конструкции... Там не хватает как минимум new

Иначе можно нарваться... 

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

Я именно про конструкцию:


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

Anikmar, сорри в апострофах, конечно - писал быстро, ошибся чуток.

Короче, в билдере все работает как надо - выводит !?! как и положено.
Я пас - студию, к сожалению, не знаю.

Любитель, в 2003 вылетает и в release и в Debug

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

vinter, почему константа? если написать const char *p = "ку-ку"; тогда константа...

Ща для интереса гляну в стандарт.

Добавлено @ 00:36 
Может плохо смотрел, но в черновике стандарта ни слова не нашел про константу....   

стандарт в глаза не видел
но верю Струструпу char *p = "111"; , и const char *p = "111"; одно и тоже  

Сам техт "!!!" - это константа (присваивается же только указатель), она хранится где-то в памяти, и при попытке изменить её скорее всего программа вылетит.

Да почему? Объясните, мне, дураку?

Во многих старых учебниках по Си давалось предупреждение:
"С осторожностью изменяйте текстовые строки - при установке опции компилятора "соединять одинаковые строки" вы можете получить нежелательные результаты"

То, что так делать не надо - я даже спорить не буду, но то, что стандарт это не запрещает - это факт.



Это сообщение отредактировал(а) Anikmar - 9.2.2007, 01:19

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

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

Я начинал с турбо си, и в одном из учебников даже разбирался код, меняющий строку (не помню для чего, помню, что экономил память). 

ИМХО Такие действия допустимы в плане ненарушения стандарта, но бессмыслены во всех остальных планах.

gcc 4.1.1 тоже вылетает

ЗЫ. но не всегда, только без оптимизации, с оптимизацией выводит оба раза "!!!"

Это сообщение отредактировал(а) nickless - 9.2.2007, 01:58

Чтож - значит уже два компилятора буду знать   

Тем не менее - теоретически код правильный.

НО! ТАК ДЕЛАТЬ НЕ НАДО! (имхо)

а с какой стати
int *p=0;
const int *p=0;
одинаковыми стали...первый раз такое слышу!!!?

Добавлено @ 11:26 
они интерпритируются по разному...

Добавлено @ 11:32 

     char *p="!!!";
     const char *p1="!!!";
-----------------------это разные вещи

не перевирай мои слова, я это сказал только про char

почитай топик нормально, мы уже выяснили, что кроме чисто сишного турбо С, и борланда компиляторы не дают так делать, т.к считают это КОНСТАНТОЙ и из этого следует, что это идентичные вещи и никаких разных интерпретаций!

Указатель никто и не пытался менять. Выясняли про собственно строку - в какую память он помещается.

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

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

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

А по поводу к чему преобразовывается - посмотрел используя type_id. Указатель вида char*p = "jsjsjsj"; и просто char *p имеют одинаковый тип (по крайней мере в борланде).

а причем тут область памяти....ты не путаешь указатель на константу с константным указателем?

есть разница между целочисленной константой и литеральной
если есть целочисленная константа

то компилятору не составит труда в качестве одного из операндов команды записать непосредственно 5, потому что это значение константы известно
код 

может выглядеть так

со строковыми литералами сложнее: непосредственно ее в команду никак не подставишь в отличие от целочисленной константы, поэтому она помещается в read-only секцию данных а в качестве операнда используется ее адрес в этой секции
для GCC это будет так для кода


при этом при загрузке исполняемого файла и просмотре заголовков секций находится read-only секция и ее содержимое помещается в какую-то физическую страницу памяти, а в соответствующем этой странице элементе таблицы страниц сбрасывается флаг W, и дальнейшее обращение к ней с целью записи приводит к #PF 
А то, что какой-то Borland допускает изменение константной строки, то это говорит о "качестве" компилятора

Это сообщение отредактировал(а) MAKCim - 10.2.2007, 11:03

На мой взгяд следовало бы вообще запретить

только

  

Стало быть так: если мы объявляем массив с инициализацией - его менять можно?
А если строку (которая тоже является массивом) то нельзя?
Если я пишу так


Объясните где тут логика и чем строка отличается от массива?! Если я хочу инициализировать массив символов строкой - то в чем собственно проблема? Почему я потом не могу ее поменять?


Остаюсь при своем мнении - Борланд позволяет делать то, что не запрещено стандартом и он тут абсалютно прав.

Добавлено @ 12:32 


Делаю так - и все в порядке?

Мы говорим не о возможности изменить УКАЗАТЕЛЬ, а о возможности изменить область памяти, на которую он ссылается!

строка - константна по своей природе и располагается в read-only области памяти (при выполнении программы)
в этом случае мы просто получаем ее адрес и изменить не можем


а в этом создаем копию строки в стеке (read-write область памяти)

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

и дальше можем изменять любой элемент a
конструкция же

вообще банально проста (даже нет никакой символьной строки - просто символы)


Это сообщение отредактировал(а) MAKCim - 10.2.2007, 13:09

он не размещает константу (в данном случае символьную) в read-only секции данных - вот здесь его "хорошие" качества проявляются

Это из чего следует?

Я программист. Мне нужен строка флагов. Я могу ее создать двумя способами:

char Options[] = "AAABBBCCDDEEFF";

или

char *Options = "AAABBBCCDDEEFF";

Язык мне это разрешает, никакого запрета нет.

Если абстрагироваться от мысли, что строка, это обязательно текстовая константа, выводимая на экран и рассматривать ее как инициализированный массив char - то все в порядке.

Я не говорю, что так нужно делать. Я говорю о том, что теоретически можно. Но не нужно.

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

Вот тут для меня загадка. И это, называется оптимизацией? Зачем две одинаковые строки в памяти?

Резюме: мы такой баян растянули - что скоро остальные смеяться будут. Все равно каждый останется при своем мнении.
Я остаюсь при таком: Делать так не стоит - так как непринято, противоречит хорошему тону программирования и т.п. Но к ошибке приводить это также не должно.

из того, что ты не можешь написать

равно как


это пример, естественно оптимизация возможна, но факт остается фактом: в одном случае мы используем указатель на строку в read-only секции, в другом - мы ее создаем (а уж с оптимизацией или нет - зависит от компилятора)

должно

это не тот случай, где возможны мнения

Да ладно уж. Мнения возможны всегда, даже если они неправильбные - это просто ошибочные мнения.

"bla-bla-bla"[0] - Такая конструкция запрещена синтаксисом самого языка.

Что не запрещено стандартом должно быть разрешено. Никто не давал права трактовать стандарт по своему усмотрению. Я ничего не нашел в стандарте по поводу запрета изменения строки. Конечно, этот способ скорее пережиток Си и MSDOS, но ничего криминального я не вижу. Моя память - что хочу то и делаю!

сейчас открыл Страуструпа и убедился
тип "example" ~ const char[8]
т. е Borland не прав - он обязан располагать "example" в read-only секции (конечно, если формат exutable файла их предусматривает... если нет - в топку такой формат)

Надеюсь, вопрос исчерпан?

Это сообщение отредактировал(а) MAKCim - 10.2.2007, 13:41

А я с этим и не спорил - именно поэтому так нельзя: "example"[0] = 1;

Пример:
    const int pInt[3] = {1,2,3};
    int *t;
//    pInt[2] = 5; - Нельзя менять константный объект

    t = (int*)pInt;
    t[1] = 2; // Теперь можно - и ничего мы не нарушили (кроме здравого смысла) И ничего не вылетело

у меня вылетело, это раз
во-вторых тут опять запись в read-only секцию
Anikmar, 
каким компилятором пользуешься?

Добавлено @ 13:47 

да ладно   

BCB 6.0

я бы его выбросил   

И так вылетит?

Anikmar, 
да
на самом деле в этом случае GCC располагает массив в read-only секции, но уменьшает ESP, не нарушая тем самым семантику использования таких массивов
в 

или

мы получаем адрес массива в read-only секции и  в итоге вылет
т. е компилятор умен и дает нам пинок под зад   (правда с задержкой до run-time) за нашу неграмотность
вот это я понимаю - качество

Это сообщение отредактировал(а) MAKCim - 10.2.2007, 13:59

а у меня(VS 2003) нет, да и с чего это оно должно вылететь, когда const снят?? 

Качество? А для чего тогда конструкция const_cast в языке предусмотрена? Я неправильно ее использовал?

какое качество?? я сознательно снимаю константность!!! это противоречит свободе!

const_cast<> можно использовать для псевдоконстантных переменных
т. е

MAKCim, первый раз такое слышу, в Страуструпе не нашел(толстая книга очень), но у Шилдта не слова про ограничения использованиия const_cast(кроме здравого смысла), к тому же студия меня еще ни разу не подводила, и если она позволяет делать такое, то я ей вполне доверяю..

Зашел на сайт страуструпа. Тоже такого не нашел

Добавлено @ 14:18 

Это говорит о низком качестве поддержки стандарта. Разработчики не парились - и просто запретили.

Да, на VC++ 2005 такое катит

скорее наоборот ибо
const_cast<> лишь анулирует const в семантическом контексте, т. е на уровне конструкций исходного кода,
истинный const-объект должен помещаться в read-only память
const_cast<> разрешит компилятору использовать const-объект как не-const, но только на уровне исходного кода

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

возвращающая некоторрое значение, но неизменяющая строку (по хорошему, конечно, конст должен стоять - но такое возможно). Вот здесь юзаем конст-каст.

Это сообщение отредактировал(а) Любитель - 10.2.2007, 16:43

Любитель, 
да, так оно и есть

А я и пишу семантическими конструкциями. И если четко непрописано, что менять нельзя - значит можно.

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

В стандарте четко сказано, что такое преобразование возможно, но осуждается. Осуждается, но не запрещается. Хотя бы на приведенном примере. То, что это противоречит здравому смыслу - я не спорю, но это отдельная тема.

Кстати, некторые примеры на Си показывали как делать полиморфный код. И эти коды рабочие (под ДОС). Не знаю как под виндами. Это уже прямая запись в сегмент кода (я не знаю доступен он для записи или нет). Но стандарт Си это разрешает (в Си++ не смотрел).

В общем как я и сказал все равно каждый останется при своем мнении.

Я остаюсь на стороне стандарта.

   Не ссорьтесь, горячие финские парни!   

Стандарт стандартом, а от реализации не убежишь

Anikmar, 
бесполезно с вами спорить
следуйте стандарту и будьте счастливы   

Давно предлагал свернуть этот баян.

  

Итак - все довольны   

Но борланд в очередной раз опозорился

Имеется мнение, что const_cast<type> равносильно (type*) и было введено лишь из соображений читабельности кода  Собственно в С было (type), в С++ static_cast<> и т.д.
Но почему помещается объект не в read-only - непонятно 

Это сообщение отредактировал(а) Xenon - 10.2.2007, 20:39

да понятно почему   

MAKCim, а как тогда сделать неизменяймый участок памяти?

const - когда быть, когда не быть