Re[5]: Строки в С и С++
От: achp  
Дата: 30.12.03 10:03
Оценка:
Здравствуйте, dad, Вы писали:

dad>таким образом стандартная бибилотке становится "частью" языка. т.е. функцию strlen можно рассматривать как языковую конмтрукцию, а не бибилотечную ?


Именно, и причем так и делается. Открой, к примеру файл cl.exe из MSVC++ 6 и разгляди его. Ты там много названий функций найдешь, прежде всего встроенные (intrinsic) функции: memcpy, strchr и т. д...

Конечно, компилятор знает семантику этих функций и, в принципе, имеет все возможности оптимизировать код с их применением.
Да здравствует ИМХО!
Re[5]: Строки в С и С++
От: jazzer Россия Skype: enerjazzer
Дата: 30.12.03 10:05
Оценка:
Здравствуйте, dad, Вы писали:

dad>ты прямо как пророк каждый раз новые истины открываешь.


ПК>>Если компилятор может наверняка "убедиться", что строка не изменяется и

ПК>>содержимое строки или ее длина ему уже "известны", он вполне может заменить вызов
ПК>>стандартной функции strlen на соответствующее значение. Ничто
ПК>>не запрещает компилятору использовать информацию о семантике стандартных функций
ПК>>для оптимизации.

dad>Разве стандарты на библиотеку коррелируются со стандартами на язык вцелом?


Более того, они являются частью стандарта на язык.

dad>Т.е. гипотетически можно разработать некую библиотеку "проллобировать" ее в комитете и ее семантика будет учитываться разработчиками компилятора?

dad>таким образом стандартная бибилотке становится "частью" языка. т.е. функцию strlen можно рассматривать как языковую конмтрукцию, а не бибилотечную ?

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

ПК>>Более того, если транслятор "умеет" анализировать функции, определенные в разных

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

dad>а что он может "анализировать" ? например, если возвращаемая значение зависит от текущего времени ?


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

dad>хотя, это очень интересно. т.е. на данный момент это усложняет программирование на c++

dad>так как делает написание портируемого кода очень трудоемким , но в перспективе , когда компиляторы "дорастут" до стандарта это делает язык очень мощным.

как же оно усложнит портируемость, когда это касается в основном только оптимизации?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[6]: оффтоп про знание языка
От: dad  
Дата: 30.12.03 10:14
Оценка:
ПК>Именно так. Необходимость реализации стандартных библиотек, фактически, всеми
ПК>разработчиками компиляторов является одним из факторов того, что "фичи" в них
ПК>включаются с особой осторожностью.

таким образом резюме составленное вот так:

языки: c++
бибилотеки: stl

выдает человека (вроде меня) который не знает что такое c++
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Re[6]: Строки в С и С++
От: dad  
Дата: 30.12.03 10:22
Оценка:
dad>>хотя, это очень интересно. т.е. на данный момент это усложняет программирование на c++
dad>>так как делает написание портируемого кода очень трудоемким , но в перспективе , когда компиляторы "дорастут" до стандарта это делает язык очень мощным.

J>как же оно усложнит портируемость, когда это касается в основном только оптимизации?


я про тоже — отделение портируемости от оптимизации усложняет первое. если я пишу портируемый код я должен помнить об оптимизации и чем она "разноцветне" тем сложнее мне делать портиуремый код. или отказаться от оптимизации. когда "оптимизация" станет стандартизованной а не "незапрещенной", тогда будет значительнее круче , ведь так?
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Re[7]: оффтоп про знание языка
От: Павел Кузнецов  
Дата: 30.12.03 10:26
Оценка:
Здравствуйте, dad, Вы писали:

d> таким образом резюме составленное вот так:

d> языки: c++
d> бибилотеки: stl
d> выдает человека (вроде меня) который не знает что такое c++

Хм... Вопрос, конечно, интересный. Думаю, это сильно зависит от того, кто именно
будет оценивать такое резюме. Во всяком случае, лично мне было бы без разницы,
написал бы ты:
  языки: c++
  бибилотеки: stl

или так:
  языки: c++ (в т.ч. stl)

Главное, что STL по твоим словам тебе известна. А решающим все равно были бы
анализ твоего кода, собеседование и т.п.
Posted via RSDN NNTP Server 1.7 "Bedlam"
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[8]: Строки в С и С++
От: Андрей Галюзин Украина  
Дата: 30.12.03 11:07
Оценка:
>> Имелась в виду именно strlen, а не какая-либо функция вообще.

aa> А чего в ней есть такого неземного? Чем она отличается от прочего разнообразия функций?


Функция стандартной библиотеки C. Компилятор "знает" стандартную библиотеку и может проводить оптимизации недоступные для
пользовательких функций.
Кроме того strlen (как и некоторые другие функции стандартной библиотеки) имеет внутреннюю (intrinsic) форму, например для VC. Что
подтверждает ее "неземное" происхождение

--
aga
Posted via RSDN NNTP Server 1.7 "Bedlam"
Re[7]: Строки в С и С++
От: jazzer Россия Skype: enerjazzer
Дата: 30.12.03 11:56
Оценка: +1
Здравствуйте, dad, Вы писали:


dad>>>хотя, это очень интересно. т.е. на данный момент это усложняет программирование на c++

dad>>>так как делает написание портируемого кода очень трудоемким , но в перспективе , когда компиляторы "дорастут" до стандарта это делает язык очень мощным.

J>>как же оно усложнит портируемость, когда это касается в основном только оптимизации?


dad>я про тоже — отделение портируемости от оптимизации усложняет первое. если я пишу портируемый код я должен помнить об оптимизации и чем она "разноцветне" тем сложнее мне делать портиуремый код. или отказаться от оптимизации. когда "оптимизация" станет стандартизованной а не "незапрещенной", тогда будет значительнее круче , ведь так?


не совсем. На разных плаформах возможны разные оптимизации, и стандартизировать их не удастся. Достаточно уже inline.
А так — разные компиляторы, а тем более на разные платформы, генерят разный по качеству, скорости и размеру код, так что разница в методах оптимизации вообще роли не играет.
Программа ведь всегда будет работать, оптимизация — это просто фича сверху, но ни в коем случае не изменение семантики.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: Строки в С и С++
От: dad  
Дата: 30.12.03 12:13
Оценка:
J>не совсем. На разных плаформах возможны разные оптимизации, и стандартизировать их не удастся. Достаточно уже inline.
J>А так — разные компиляторы, а тем более на разные платформы, генерят разный по качеству, скорости и размеру код, так что разница в методах оптимизации вообще роли не играет. Программа ведь всегда будет работать, оптимизация — это просто фича сверху, но ни в коем случае не изменение семантики.

а причем тут платформа?
если я пишу такой код
for ( i = 0 ; i < strlen(src) ...
я не уверен что он будет оптимизирован, если бы подобная оптимизация (хотябы стандартных функций) _строго_ регламентировалась стандартом было бы мощнее.
а если бы еще и та оптимизация о которйо упоминал Павел, то было бы еще мощнее.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Re: Строки в С и С++
От: Воронков Василий Россия  
Дата: 30.12.03 15:32
Оценка:
Здравствуйте, Сергей Аристов, Вы писали:

СА>Статья:



СА>Авторы:

СА> Сергей Аристов

СА>Аннотация:

СА>Это первая часть, в которой обсуждаются «традиционные» строки в С. В С++ существуют более удобные механизмы для работы со строковыми данными, эти механизмы рассматриваются во второй части статьи. А зачем вообще обсуждать неудобные С-строки, если есть С++? К сожалению, совсем забыть о строках в стиле С нельзя по двум причинам:
СА>1. существует большое библиотек (например, API операционных систем) работающих именно с С-строками
СА>2. строковые классы в С++ все равно основаны на традиционных С-строках, и если мы хотим разобраться в том, как они работают, нам придется понимать их основы.

Очень похоже на главу из какого-то учебника.
Re: Строки в С и С++
От: adontz Грузия http://adontz.wordpress.com/
Дата: 01.01.04 21:58
Оценка:
Здравствуйте, Сергей Аристов, Вы писали:

Статья для новичков, это ИМХО хорошо.
А вот то что написано не очень.

SetWindowText(hwnd, "Новый заголовок окна");

Зачем в таком платформонезависимом материале такая специфичная для ОС функция, да ещё и из графического режима? Неужели в консоли ничего не нашлось?


Исторически символ занимает 1 байт, в этом случае он имеет тип char.

Известно что sizeof(char) == 1 и sizeof(любой тип) это целое число. То что char это один байт нигде не указано.


В свою очередь многобайтные кодировки можно разделить на кодировки с фиксированным количеством байтов — каждому символу соответствует одинаковое количество байтов, и «плавающие», в которых один символ может представляться разным количеством байтов в зависимости от его содержимого. К первым относятся кодировки типа Unicode, в которой каждый символ представлен двумя байтами, ко вторым — UTF-8 и др. Плавающие кодировки — отдельная тема, языки С/С++ не предлагают для них никакой поддержки.

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


В С/С++ существует специальный тип для многобайтных символов — wchar_t

Просвятите, разве wchar_t стандартизирован?


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

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


Напомню, что c массивом элементов типа char связан указатель на char

Что значит связан? Леночкой Гименея?


wchar_t sym;
sym=L'ab';

Это вообще не корретная запись. Вам должна выдатся ошибка или на худой конец предупреждение. Надо либо так
wchar_t sym;
sym='ab';

Лио так
wchar_t sym;
sym=L'a';



Существует специальный формат для записи символьных литералов – слеш, за которым идет код символа

Не слеш, а обратный слеш.


Применение же этих операций к строкам либо вообще запрещено

С каких это пор над указателями запрещена математика?


Снизить риск такого развития событий способна функция

char* strncpy(char* dest, const char* src, size_t count)

Последний параметр – максимальное количество копируемых символов. Таким образом, передавая туда размер приемника, вы гарантируете, что функция никогда не выйдет за пределы выделенной памяти. Однако помните, что если исходная строка будет скопирована не полностью, нуль-терминатор не появится в результирующей строке. Его придется записать самостоятельно.
ПРЕДУПРЕЖДЕНИЕ
Никогда не забывайте контролировать используемую память!

Здесь стоило бы ИМХО упомянуть StrSafe.h Он хотя и не стандартный, но
1) Microsoft Visual C++ не самый забытый компилятор
2) Для новичков (и тех кто боится переполнения буффера) самое то.
3) Другие не стандартный функции от Microsoft в статье упоминаются


for (i=0;i<strlen(str);i++) {
    // работа со строкой, не изменяющая ее длину
}

Я бы заменил на
for (unsigned int i = 0, len = strlen(str); i < len; i++) {
    // работа со строкой, не изменяющая ее длину
}

Ну и дальше везде, где цикл.


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

Ага Очень не сложно строку вида "1,23456-E37" преобразовать в число. Пустяки собственно.


Эти функции очень похожи на printf и scanf, за исключением того, что они работают не с консолью, а со строковым буфером. Для дополнительной информации об этих функциях см. документацию.

RTFM это конечно хорошо, только вот какую документацию смотреть?







Ну и вопрос не к автору.
КАК ТАКУЮ СЫРУЮ СТАТЬЮ ПРОПУСТИЛИ????
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[2]: Строки в С и С++
От: Павел Кузнецов  
Дата: 02.01.04 12:14
Оценка:
Здравствуйте, adontz, Вы писали:

a>

a> Исторически символ занимает 1 байт, в этом случае он имеет тип char.

a> Известно что sizeof(char) == 1 и sizeof(любой тип) это целое число.
a> То что char это один байт нигде не указано.

Именно байт. В C и C++ (unsigned) байт представляет собой минимально адресуемую
единицу памяти. Вкупе с требованием того, что все биты unsigned char значащие
и sizeof(char) == 1 байт, а также возможностью оперировать с фактически
произвольной памятью как с массивом (unsigned) char, это делает (unsigned) char
типом непосредственно представляющим байт.

Определение байта:

1.7 The fundamental storage unit in the C++ memory model is the byte.
A byte is at least large enough to contain any member of the basic execution
character set and is composed of a contiguous sequence of bits, the number
of which is implementation-defined.


Некоторые данные о (signed, unsigned) char:

3.9.1 Objects declared as characters (char) shall be large enough to store
any member of the implementation’s basic character set. <...> A char, a signed
char, and an unsigned char occupy the same amount of storage and have the same
alignment requirements (3.9); that is, they have the same object representation.
For character types, all bits of the object representation participate in
the value representation. For unsigned character types, all possible bit patterns
of the value representation represent numbers.


В каких единицах выражается sizeof:

5.3.3 The sizeof operator yields the number of bytes in the object
representation of its operand. <...> sizeof(char), sizeof(signed char) and
sizeof(unsigned char) are 1 <...>


a>

a>

a> В С/С++ существует специальный тип для многобайтных символов — wchar_t

a> Просвятите, разве wchar_t стандартизирован?

Да. Это специальный тип, не являющийся typedef.

3.9.1/5 Type wchar_t is a distinct type <...>


a>

a>

a> размер передаваемых в функцию массивов нужно указывать отдельно, получить
a> его в функции нельзя

a> Насколько я знаю массивы никогда не передаются. Даже если задекларировать
a> в качестве параметра массив, всё равно будет передан указатель.

Передать массив можно, т.е. имя массива можно использовать в качестве
аргумента. Принять массив по значению, конечно, нельзя, т.е. параметров типа
массив не бывает (указатели/ссылки на массив — другое дело). Но, по-моему,
именно это и сказано в статье

a>

a>

a>

 a> wchar_t sym;
 a> sym=L'ab';
 a>

a> Это вообще не корретная запись. Вам должна выдатся ошибка
a> или на худой конец предупреждение.

Почему ты так считаешь? Напротив, ошибку выдавать компилятор права не имеет.
От реализации зависит только значение литерала:

2.13.2
1 <...> An ordinary character literal that contains more than one c-char
is a multicharacter literal. A multicharacterliteral has type int and
implementation-defined value.
1 <...> The value of a wide-character literal containing multiple c-chars
is implementation-defined.


a> Ну и вопрос не к автору.

a> КАК ТАКУЮ СЫРУЮ СТАТЬЮ ПРОПУСТИЛИ????

По-моему, ты преувеличиваешь. Явные ляпы я вижу только в твоих замечаниях
Posted via RSDN NNTP Server 1.7 "Bedlam"
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[3]: Строки в С и С++
От: adontz Грузия http://adontz.wordpress.com/
Дата: 02.01.04 12:45
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Именно байт.


the number of which is implementation-defined.

То есть хоть 4, хоть 17, хоть 32. Я имею ввиду где указано что байт в смысле архитектуры процессора == char?

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

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


ПК>Да. Это специальный тип, не являющийся typedef.
Это был вопрос


ПК>Передать массив можно, т.е. имя массива можно использовать в качестве
ПК>аргумента. Принять массив по значению, конечно, нельзя, т.е. параметров типа
ПК>массив не бывает (указатели/ссылки на массив — другое дело). Но, по-моему, именно это и сказано в статье

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

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

  • То есть автор до кучи ещё и запутывает новичка (а статья, скажем сразу, для очень начинающих) о методе передачи массива. Вот от таких статей и берутся такие вопросы
    Автор: Lyvra
    Дата: 24.12.03
    .




    ПК>Почему ты так считаешь? Напротив, ошибку выдавать компилятор права не имеет.
    Я так считаю потому что L'ab' это 4(!) байта. 2 на L'a' и ещё 2 на L'b'.



    ПК>По-моему, ты преувеличиваешь. Явные ляпы я вижу только в твоих замечаниях

    Ладно погрячился, не сырая, а сыроватая. Но что-то явных ляпов в моих замечаниях нет (разве что про байт спорно, а вот многие другие ты пропустил, а молчание знак согласия), а вот статья явно не дописана. Ну не дожали автора, я же знаю как жмут ради дела, а здесь не дожали .
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[4]: Строки в С и С++
    От: Odi$$ey Россия http://malgarr.blogspot.com/
    Дата: 02.01.04 13:00
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>(а статья, скажем сразу, для очень начинающих)


    гы-гы, вот праздники кончатся, подтянутся Андрей Тарасевич и Кодт и как раз обсуждение для начинающих и начнется
    Re[5]: Строки в С и С++
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 02.01.04 13:11
    Оценка:
    Здравствуйте, Odi$$ey, Вы писали:

    OE>гы-гы, вот праздники кончатся, подтянутся Андрей Тарасевич и Кодт и как раз обсуждение для начинающих и начнется


    Спасибо! Я уже один раз посорев
    Автор:
    Дата: 20.03.02
    новался
    Автор: Alex Fedotov
    Дата: 24.03.02
    с меня хватит
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[4]: Строки в С и С++
    От: Павел Кузнецов  
    Дата: 02.01.04 13:23
    Оценка:
    Здравствуйте, adontz, Вы писали:

    ПК>> Именно байт.


    a>

    a> the number of which is implementation-defined.


    a> То есть хоть 4, хоть 17, хоть 32. Я имею ввиду где указано что байт

    a> в смысле архитектуры процессора == char?

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

    a> Может я и ошибаюсь, но речь здесь (судя по кодировкам) именно

    a> о процессорном байте. Хотя ладно пустяки. Забили.

    Кодировки к "процессорным байтам" никакого отношения не имеют.

    ПК>> Да. Это специальный тип, не являющийся typedef.


    a> Это был вопрос


    Хм... Разве я на него не ответил, дав ссылку на стандарт? Если нет,
    сформулируй, пожалуйста, вопрос точнее.

    a> Указатели и массивы идут двумя разными пунктами,

    a> в то время как это уже на уровне языка одно и то же в смысле
    a> способа передачи в функцию.

    Это одно и то же с точки зрения получения в функции, а передача
    происходит по-разному: для массива производится преобразование к указателю,
    которое не делается в случае передачи непосредственно указателей.

    ПК>> Почему ты так считаешь? Напротив, ошибку выдавать компилятор права

    ПК>> не имеет.

    a> Я так считаю потому что L'ab' это 4(!) байта.


    Нет, sizeof(L'ab') == sizeof(wchar_t)

    a> 2 на L'a' и ещё 2 на L'b'.


    Ты неверно понимаешь, как "работают" многосимвольные литералы. Типом L'...'
    вне зависимости от количества символов остается wchar_t, равно как типом
    '...' — char.

    a> Ладно погрячился, не сырая, а сыроватая.


    Статья, как статья Есть и хуже, есть и лучше.

    a> многие другие ты пропустил, а молчание знак согласия


    В данном случае, скорее, лени
    Posted via RSDN NNTP Server 1.7 "Bedlam"
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[5]: Строки в С и С++
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 02.01.04 13:37
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Ты неверно понимаешь, как "работают" многосимвольные литералы. Типом L'...'

    ПК>вне зависимости от количества символов остается wchar_t, равно как типом
    ПК>'...' — char.

    Речь ведь не о том, что это объязательно не скомпилируется, речь о том что это не корректно. Значение L'ab' это уникодный символ 'a'. В то время как 'b' "пролетает".
    Меня например компилятор об этом честно предупредил
    //
    #include <stdlib.h>
    //
    int main(int argc, char * argv[])
    {
        wchar_t sym = L'ab'; 
        return 0;
    }


    test.cpp(6) : warning C4066: characters beyond first in wide-character constant ignored



    a>> Ладно погрячился, не сырая, а сыроватая.

    ПК>Статья, как статья Есть и хуже, есть и лучше.
    Успокоил

    a>> многие другие ты пропустил, а молчание знак согласия

    ПК>В данном случае, скорее, лени

    Ну тогда не буду мешать
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[6]: Строки в С и С++
    От: Павел Кузнецов  
    Дата: 02.01.04 14:58
    Оценка:
    Здравствуйте, adontz, Вы писали:

    ПК>> Ты неверно понимаешь, как "работают" многосимвольные литералы. Типом L'...'

    ПК>> вне зависимости от количества символов остается wchar_t, равно как типом
    ПК>> '...' — char.

    a> Речь ведь не о том, что это объязательно не скомпилируется, речь о том что

    a> это не корректно.

    Это может быть вполне корректным.

    a> Значение L'ab' это уникодный символ 'a'. В то время как 'b' "пролетает".


    Не обязательно. Компилятор может использовать 'b' для формирования сложного
    символа совместно с 'a'.

    a> Меня например компилятор об этом честно предупредил


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

    a>>> многие другие ты пропустил, а молчание знак согласия


    ПК>> В данном случае, скорее, лени


    a> Ну тогда не буду мешать


    Don't worry, be happy С Новым годом!
    Posted via RSDN NNTP Server 1.7 "Bedlam"
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[2]: Строки в С и С++
    От: Vamp Россия  
    Дата: 02.01.04 19:28
    Оценка: +1
    LF>Чегото мельчают статьи — смылс написания данной статьи для меня остается загадкой.
    LF>нет чтобы действительно чтото интересное написать чего нет в литературе или на русском не издавалось
    LF>а про строки в любой книжке по C++ написано
    Просто вопросы в форуме частенько мелькали. Вот я и решил попробовать сделать предмет чуть понятнее для новичков.
    Да здравствует мыло душистое и веревка пушистая.
    Re[2]: Строки в С и С++
    От: Vamp Россия  
    Дата: 02.01.04 19:32
    Оценка:
    ВВ>Очень похоже на главу из какого-то учебника.
    Если только из будущего
    Если все же напишу учебник (давно мечтаю) — вставлю.
    Да здравствует мыло душистое и веревка пушистая.
    Re[2]: Строки в С и С++
    От: Vamp Россия  
    Дата: 02.01.04 19:55
    Оценка:
    Ну, тут Павел по большей части ответил — но я, как автор, должен сам реагировать .
    A>

    A>SetWindowText(hwnd, "Новый заголовок окна");

    A>Зачем в таком платформонезависимом материале такая специфичная для ОС функция, да ещё и из графического режима? Неужели в консоли ничего не нашлось?
    Я хотел продемонстрировать, что С-строки важны, например, при работе с API. В С++ C-строки используются очень мало.

    A>

    A>Исторически символ занимает 1 байт, в этом случае он имеет тип char.

    A>Известно что sizeof(char) == 1 и sizeof(любой тип) это целое число. То что char это один байт нигде не указано.
    Тут целиком присоединяюсь к Павлу.
    A>В Unicode некоторые символы так же представлены последовательностями байт длины отличной от двух. Кажется кстати и японские иероглифы.
    Можно пример со ссылками? Действительно интересно. Я был уверен, что Unicode — всегда два байта.

    A>Просвятите, разве wchar_t стандартизирован?

    Да. См., например, Страуструпа.

    A>Насколько я знаю массивы никогда не передаются. Даже если задекларировать в качестве параметра массив, всё равно будет передан указатель.

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

    A>

    A>Напомню, что c массивом элементов типа char связан указатель на char

    A>Что значит связан? Леночкой Гименея?
    Именно так. Леночкой Гименеевой. Природа связи между массивами и указателями — очень обширная тема, чуть-чуть затронутая в начале.

    A>

    A>

    A>wchar_t sym;
    A>sym=L'ab'; 
    A>

    A>Это вообще не корретная запись. Вам должна выдатся ошибка или на худой конец предупреждение. Надо либо так
    Страуструп, "Язык программирования С++, специальное издание":

    Символьные литералы из расширенного набора записываются в виде L'ab', при этом количество символов между одиночными кавычками и их значение зависят от реализации и соответствуют типу wchar_t.


    A>С каких это пор над указателями запрещена математика?

    Попробуй, например, перемножить два указателя. Подсказка: см. стандарт 1998 г, параграф 5.6, пункт 2.

    A>Здесь стоило бы ИМХО упомянуть StrSafe.h Он хотя и не стандартный, но

    A>1) Microsoft Visual C++ не самый забытый компилятор
    A>2) Для новичков (и тех кто боится переполнения буффера) самое то.
    A>3) Другие не стандартный функции от Microsoft в статье упоминаются
    Я уже отметил, с какой целью я употребил функцию SetWindowText.

    A>
    A>for (unsigned int i = 0, len = strlen(str); i < len; i++) {
    A>    // работа со строкой, не изменяющая ее длину
    A>}  
    A>

    A>Ну и дальше везде, где цикл.
    Считается, что и i, и str определены где-то ранее.

    A>Ага Очень не сложно строку вида "1,23456-E37" преобразовать в число. Пустяки собственно.

    А что, в самом деле трудно?

    A>Эти функции очень похожи на printf и scanf, за исключением того, что они работают не с консолью, а со строковым буфером. Для дополнительной информации об этих функциях см. документацию.

    A>RTFM это конечно хорошо, только вот какую документацию смотреть?
    В справке к своему компилятору, в стандарте, в книгах. Уж больно флагов там много, приводить все описание целиком.

    A>Ну и вопрос не к автору.

    A>КАК ТАКУЮ СЫРУЮ СТАТЬЮ ПРОПУСТИЛИ????
    Вопрос не ко мне — я отвечать не буду.
    Да здравствует мыло душистое и веревка пушистая.
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.