После года разработки опубликован релиз свободного набора компиляторов GCC 11.1, первый значительный выпуск в новой ветке GCC 11.x. В соответствии с новой схемой нумерации выпусков, версия 11.0 использовалась в процессе разработки, а незадолго до выхода GCC 11.1 уже ответвилась ветка GCC 12.0, на базе которой будет сформирован следующий значительный релиз GCC 12.1...Подробнее: https://www.opennet.me/opennews/art.shtml?num=55035
"Ждём ебилдов" :D.
Так-то в репе уже на 12 есть ;)
Как это? Ты арче-школьник?
еще вчера приехали https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc/...
> еще вчера приехали https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc/...Пару недель не синкался, вот под праздники походу заведу апгрейд :).
Я так понимаю использование>режима статического анализа "-fanalyzer"
переводит Rust в статус deprecated.
:)
> Я так понимаю использование
>> режима статического анализа "-fanalyzer"
> переводит Rust в статус deprecated.Я так понимаю, очередной опеннетный комментатор с познаниями уровня "слышал звон"?
https://www.opennet.me/opennews/art.shtml?num=53208
> Релиз статического анализатора cppcheck 2.1https://clang-analyzer.llvm.org/
> The Clang Static Analyzer is a source code analysis tool that finds bugs in C, C++, and Objective-C programs.https://www.frama-c.com/
https://coccinelle.gitlabpages.inria.fr/website/
...
Посмотрите, какая богатая коллекция ссылок у этого эксперта! Все срочно проходим по ним, потому что вплоть до этого момента никто кроме этого эксперта ничего и не знал про стат. анализаторы для сишки.
> Посмотрите, какая богатая коллекция ссылок у этого эксперта! Все срочно проходим по ним, потому что вплоть до этого момента никто кроме этого
> эксперта ничего и не знал про стат. анализаторы для сишки.Посмотрите, как очередного (или того же, но "замаскированного") впопеннетного Ыксперта бобмит минусиками - но по существу ему возразить нечего.
Впрочем, он так и не понял, о чем вообще речь.
Разъясняю для Ыкспердов: cppcheck стат. анализатор для сишки 2007 года, шланг-анализаторы тоже уже не первый год. Так что с "статус deprecated" малость опоздал. Не говоря уже о том, что анализ анализу рознь.
Это статические анализаторы, которые смотрят ошибки по тексту кода. А "-fanalyzer" компилирует код и по ходу выполнения смотрит ошибки, что, как я понима делает и компилятор Rust. В это смысле достугается паритет. Достугнут он лили нет - вряд ли - не берусь судить.
Компилятор Rust так не делает.
> так не делает.делает всё не так :)
> Это статические анализаторы, которые смотрят ошибки по тексту кода. А "-fanalyzer" компилирует код и по ходу выполнения смотрит ошибки, что, как я понима делает и компилятор Rust.
>> Clang Static Analyzer
>> It implements path-sensitive, inter-procedural analysis based on symbolic execution technique.Как я и подозревал - анализ уровня "слышал звон". И даже по ссылкам не ходил.
> В это смысле достугается паритет.
Там нужно конкретно так смотреть на объем и качество анализа, иначе "ни о чем".
>> It implements path-sensitive, inter-procedural analysis based on symbolic execution technique.
>Как я и подозревал - анализ уровня "слышал звон". И даже по ссылкам не ходил.Мда, как то эта информация прошла мимо :( Буду знать какой оказывается Clang Static Analyzer
Беда в том, что рантайм проверки очень дорогие для приложения. Если придумать некий специальный рантайм для плюсов, проблемы с производительностью у него будут ровно те же, что и у раста. В целом же, раст стоит расценивать исключительно как площадку для экспериментов по улучшению плюсов, а не как замену чему бы то ни было, поэтому выкидывать в ближайшее время ничего не будут.
Ну так опция -fanalyzer включается только в dev окружении и выключается в релизе.
У Rust как раз-таки большинство проверок на этапе компиляции.
Какие рантайм проверки? Вы хоть читайте. Это статический, компайл-тайм анализ кода на перечеслинные дефекты. Именно о чем кричат растофилы. Только для такого контроля не надо пердолиться с явным обозначением лайфтайма объектов в языке, изобретать ансейф-код для создания двух и более модифицирующих ссылок, даже в сингл-треде. Анализ кода во-время компиляции основывается на вычислениях во время компиляции и анализе путей исполнения кода. И у компилятора гораздо больше информации о путях исполнения кода чем у внешнего анализатора, которому по сути нужно проделять ту же самую работу чтобы получить её.
Компайл тайм раста по сути бесполезен и является сахаром ради сахара -- сегодняшние анализаторы ничем не хуже. Весь профит в рантайм проверках.
Компайл тайм раста, в отличие от обычных анализаторов, дает гарантии
> Компайл тайм раста, в отличие от обычных анализаторов, дает гарантииТолько на той неделе UB в safe исправляли -- так себе гарантии/
C ++ появился в 1983. И базируется он на Си, который появился вообще в 1972. Rust появился в 2010 и сейчас активно развивается. Ничего удивительного что в нем находят огрехи.
Вы лучше ответьте на вопрос, раз С++ так крут, как в нем решена проблема копирования перекрывающихся областей памяти в куче? Я вам сразу скажу - никак. В языке вся работа с памятью на указателях, и у компилятора нет гарантий, что копируемые участки гарантированно не пересекаются. А значит он не может провести часть оптимизаций и предрасчётов во время компиляции, не может векторизовать цикл копирования, и не может распараллелить его. В Rust эта и многие дугие проблемы изначально отсутствуют.
Найс сравнение, ты ещё науку 5000 лет назад сравни с нынешней.
> Вы лучше ответьте на вопрос, раз С++ так крут, как в нем
> решена проблема копирования перекрывающихся областей памяти в куче?Проиллюстрируйте проблему примером кода, что бы было понятно, о чём речь.
> как в нем решена проблема копирования перекрывающихся областей памяти в куче?В плюсах никак, потому-что это было решено еще в C (memmove).
memmove и __restrict тебе помогут
> Вы лучше ответьте на вопрос, раз С++ так крут, как в нем
> решена проблема копирования перекрывающихся областей памяти в куче? Я вам
> сразу скажу - никак. В языке вся работа с памятью на
> указателях, и у компилятора нет гарантий, что копируемые участки гарантированно не
> пересекаются. А значит он не может провести часть оптимизаций и предрасчётов
> во время компиляции, не может векторизовать цикл копирования, и не может
> распараллелить его.:-)
memcpy гарантирует неперекрываемость... И очередное UB в случае перекрытия. В своё время любовники Flash плюгина скандалили...
>А значит он не может провести часть оптимизаций и предрасчётов во время компиляции, не может векторизовать цикл копирования, и не может распараллелить егоrestrict
RTFM
> Вы лучше ответьте на вопрос, раз С++ так крут, как в нем
> решена проблема копирования перекрывающихся областей памяти в куче?Не понимаю проблему. Я даже примитивный memmove() накодил под baremetal. Для растаманов это, типа, слишком сложно? И ему похрен, куча или нет. Ему дают адреса откуда, куда, и количество. Реализация обязана корректно работать с перекрывающимися адресами.
>> у компилятора нет гарантий, что копируемые участки гарантированно не пересекаются. А значит он не может провести часть оптимизаций и предрасчётов во время компиляции, не может векторизовать цикл копирования, и не может распараллелить его. В Rust эта и многие дугие проблемы изначально отсутствуют.
> Не понимаю проблему.
> Я даже примитивный memmove() накодил под baremetal. Для растаманов
> это, типа, слишком сложно? И ему похрен, куча или нет. Ему
> дают адреса откуда, куда, и количество. Реализация обязана корректно работать с перекрывающимися адресами.Ничего удивительного - ты даже прочитать текст целиком не можешь, куда уж тут "проблему понимать" ...
Единственные гарантии которые может дать rust это боль пониже спины у анонимных экспертов
Я уверен, что ни один уважающий себя с-программист не будет использовать этот режим, иначе он испытает такое унижение, что никогда не будет больше программировать!
Маловероятно, в этом режиме ничто сложнее студенческих поделок не скомпилируется, си-ппограммисты настолько малоквалифицированны, в настоящее время, что не понимают, что весь объем легаси - это сплошные некорректные трюки (те-же трюки с кучей), а то, что еще может пройти проверку - безбожно тормозящее... и суть появления ржавчины - избавление от трюкачеств в легаси, да, эта проверка этому поможет, но "си-кодеры" не способны осознать, что проще - воспользоваться адекватным инструментом: ржавчиной или плюсами, чем приводить допотопный код на допотопном языке для допотопных контролеров в компилируемое состояние...
Есть примеры и код чтобы подтвердить или просто попердываешь?
Очередной ыксперт, сколько же вас развелось то.
Никто бы не стал включать этот режим в gcc, если бы он годился только для просты семплов. Практика показывает, что если код работает корректно на хотя бы 2х различных платформах(а большинство системных С программ работает на хотя бы x86, x86_64, arm и mips), то неведомого трюкачества в коде очень мало и он вполне себе проходит статический анализ. Да, там могут быть косяки, но их крайне мало. А вы, уважаемый ыксперт, просто не знаете насколько много трюков и проблем приходится выпиливать из кода, когда он приколочен к одной ОС и к одной аппаратной платформе. Если же он не приколочен, то и трюков так сильно меньше, потому что та же арифметика указателей без понимания как она работает, хрена с два заработает без багов на разных платформах.
> воспользоваться адекватным инструментом: ржавчиной или плюсами, чем приводить допотопный код на допотопном языке для допотопных контролеров в компилируемое состояние...Так они и ЯП Modula-3, на котором эти проблемы давно решили, не хотят знать. Куда им ржавчину вписывать?
Статический анализатор конечно хорошо, но у раста он ещё и с гарантиями:)
Ценность Rust сильно опустит поддержка GCC опции -D_FORTIFY_SOURCE=3 пока есть только 2.
>улучшениями, связанными с будущим стандартом языка Си (C2x), новыми оптимизациями производительности.Последний стандарт 18 года, полностью поддерживается? На подходе С2x
Чистый Си рулит!
Там нет особо изменений https://en.wikipedia.org/wiki/C2x
Сишечка настолько идеальна, что туда нечего добавить.
Да и убирать оттуда, тоже ничего не надо.
Как насчёт убрать оттуда отвратительную работу со строками из 70-х годов, из-за которых каждая программа на Си кишит дырами и багами?
Да и с макросами что-то делать нужно. Негоже это, когда они чем-то сторонним обрабатываюся. Надо бы, чтобы самим компилятором, чтобы получать адекватные сообщения о проблемах.
Легче новый язык создать.
Макросы это макросы, они в принципе не разрабатывались так, чтобы их нужно было анализировать. Если захочется их анализировать, то возникнет вопрос что это должны быть за макросы, какими возможностями они будут обладать и возможно тогда наворотят такие макросы, что лучше всё же жить с макросами из прошлого века.Каждое решение имеет свои плюсы и свои минусы. Плюсов у С макросов достаточно, даже самый накаченный макросами код, компилируется очень быстро. Они просты, там просто нет ничего, но при этом выразительны.
Омномномнимов послушать, там ассемблер вообще язык дыр!
Без разницы, нигде больше не используется.
> Без разницы, нигде больше не используется.Только программистам не рассказывай, а то зачмырят.
Зачем убирать? Что за привычка убирать что-то, из-за чего куча кода поломается. Ну давайте завтра давление в трубах поднимем до 10 атм или опустим до одной. Как там ваши смесители и бачки сливные у унитазов, будут работать? А ведь поднять до 10 и будет стабильнее водоснабжение на высоких этажах. И будете сами себе регуляторы давления ставить, чтобы смеситель не взорвало.Так вот, куча есть реализаций строк под различные требования. Берите и пользуйтесь. На кой чёрт тащить в стандарт это. Поймите, если вам нужна хорошая реализация строк, с хранением длины и прочего для юникода, то значительному количеству С кода из эмбеда нужны различные компактные реализации строк и они также вправе требовать их в стандарт. Ну и что получится, 20 реализаций и все в стандарт?
переписыай под новые стандарты и не ной, показывая своё рукожопство.
> Как насчёт убрать оттуда отвратительную работу со строками из 70-х годов, из-за
> которых каждая программа на Си кишит дырами и багами?Расскажите в подробностях, кто и как заставляют Вас писать #include <string.h>
Подумаем, что в такой ситуации делать.
strncpy
strncat
strxfrm
И что со строками не так?
char abc[3]; strncpy(abc, "abc", 3); Эти функции изначально предназначались не для строк, а для "записей" (record), поэтому не просто копируют строки, но еще и добивают результат нулями до ширины поля. Или не добивают.
> char abc[3]; strncpy(abc, "abc", 3); Эти функции изначально предназначались не для строк,
> а для "записей" (record), поэтому не просто копируют строки, но еще
> и добивают результат нулями до ширины поля. Или не добивают.Что не так (если не считать отсутствия в языке "рекордов")?
Вам не нравится, что char abc[3]; strncpy(abc, "a", 3); обнулит остаток массива?
> Что не так (если не считать отсутствия в языке "рекордов")?Записи не про язык, они больше про файлы. В сишке представляются сишными структурами. Кроме строковых функций записи еще протекли во всякие calloc и fread, именно поэтому там по два аргумента с размером. Но там это не приводит к проблемам.
Как я уже сказал, strncpy не имеет отношения к сишным строкам, поэтому не завершает буфер нулем, а именно дополняет. Если места в буфере после строки не осталось, как в примере выше, то никакого нуля в буфер не запишется. Не раз видел, что слышавшие о проблеме, но неспособные ее понять, пытаются фиксить это так: char abc[3]; strncpy(abc, "abc", sizeof(abc) - 1). Но результат не меняется. А не нравится мне, что даже люди, которые совсем не пару месяцев на си пишут, все равно изредка продолжают об это спотыкаться. К счастью, санитайзеры все это ловят. К несчастью, в релизе санитайзера нет.
>> Что не так (если не считать отсутствия в языке "рекордов")?
> Записи не про язык, они больше про файлы. В сишке представляются сишными
> структурами. Кроме строковых функций записи еще протекли во всякие calloc и
> fread, именно поэтому там по два аргумента с размером. Но там
> это не приводит к проблемам.Тут не экзамен, не надо выдавать почерпнутое из безусловно полезной книжки Вирта за язык Си.
> Как я уже сказал, strncpy не имеет отношения к сишным строкам, поэтому
> не завершает буфер нулем, а именно дополняет.Вы можете говорить что угодно, но язык Си регламентирован стандартом ISO/IEC 9899, где про strncpy() сказано "присоединяет копию строки... к массиву..."
> Если места в буфере
> после строки не осталось, как в примере выше, то никакого нуля
> в буфер не запишется.Функция ничего не знает про "буфер", а гарантирует, что в массиве будет размещено n символов.
> Не раз видел, что слышавшие о проблеме,
> но неспособные ее понять, пытаются фиксить это так: char abc[3]; strncpy(abc,
> "abc", sizeof(abc) - 1). Но результат не меняется. А не нравится
> мне, что даже люди, которые совсем не пару месяцев на си
> пишут, все равно изредка продолжают об это спотыкаться. К счастью, санитайзеры
> все это ловят. К несчастью, в релизе санитайзера нет.Так надо понять и указать количество ненулевых символов источника + 1. Тогда добавит '\0'. Естественно, надо понимать, как это отразится на массиве-приёмнике. Ну и хорошо бы ещё понять (мне) кто и зачем таким образом инициализирует массив.
>> Не раз видел, что слышавшие о проблеме,
>> но неспособные ее понять, пытаютсяВ общем, вот это и есть проблема. Низкоквалифицированные высокомотивированные люди. Беда не в языке. Беда в людях не на своём месте. Когда вот этот разработчик операционных систем https://www.opennet.me/~mikhailnov считает, что #define определяет переменную, а через год заявляет, что типизация в языке строгая, проблему не решить, дав обезьяне в руки новый инструмент с модной блестящей кнопкой.
> почерпнутое из безусловно полезной книжки ВиртаНе читал, осуждаю.
> где про strncpy() сказано
На заборе тоже... сказано.
> Функция ничего не знает про "буфер", а гарантирует, что в массиве будет размещено n символов.Наконец-то! Именно об этом мы и говорим. На входе валидная строка, на выходе не строка. Тут-то мы и возвращаемся к тому, что нормальных функций работы со строками в стандартной библиотеке нет, и более-менее можно вменяемо использовать лишь snprintf и Annex K, но snprintf надо уметь готовить, а Annex K, решая одни проблемы, создает новые.
> надо понять и указать количество ненулевых символов источника + 1
Если мне заранее известна длина строки, я сделаю memcpy(). Мы говорим о случае, когда я не знаю, влезет ли строка в буфер и хочу получить две вещи: 1) обрезанную или нет, но валидную (то есть, нуль-терминированную) сишную строку в буфере; 2) информацию о том, обрезалась ли строка. Функция strncpy() не справляется ни с тем, ни с другим.
> Ну и хорошо бы ещё понять (мне) кто и зачем таким образом инициализирует массив.
Таким - говнокодеры. В любом серьезном проекте на си первым делом пишется своя, не сломанная реализация strcpy(), и всего остального семейства заодно.
>> где про strncpy() сказано
> На заборе тоже... сказано.Это стандарт, а не забор. Дальнейший твой текст читать не имеет смысла.
>>> где про strncpy() сказано
>> На заборе тоже... сказано.
> Это стандарт, а не забор. Дальнейший твой текст читать не имеет смысла.Ви два дэбила. В С ващэ нет функций!!! Нет ля, строк!!! ВААЩЕ, ТО ЕСТЬ САВСЕМ!!
В Ц один (три) тип(а) - целое, указатель (тоже щелое) и плавающие (два целых)Ваша стрнцпуй() это всего лищь: присваивание указателей count раз.
стрцпуй() тоже самое только до нуля, ноль запихнуть или проверить его наличие - это ваша задача
char *tmp = to;while (count) {
if ((*tmp = *from) != 0)
src++;
tmp++;
count--;
}Как видите, в to валяются указатели от 0 до count. ФСЁ!!!
Дэбилы пехапешные,... рекорды какие-то, массивы, ISO, Вирт ваще Паскаль придумал.
В Цэ (асм пропустим) вы думаете за компьютер, а не он за вас!!!
Иди проспись, а потом подумай над своим поведением.
> Иди проспись, а потом подумай над своим поведением.Мнение одминчега локалхоста важно! Ти кто, пля, такой? :D
>> Иди проспись, а потом подумай над своим поведением.
> Мнение одминчега локалхоста важно! Ти кто, пля, такой? :DЯ здесь малость инкогнито, но кое-что обо мне не составляет труда найти (если не похмеляться с утра, конечно же).
И тут самое время выяснить, а что за гуру "в Си нет функций" загибает пальцы.
Если не ошибаюсь, Михаил Шигорин как-то писал, что нашёл здесь жемчужину в виде некоего pavlinux-а. Это правда?
.
Так и не проспался? Похоже, я тебя с другим человеком перепутал, получился поклёп на Альт. Виноват.А ты, случаем, не сынок директриссы шарлатанов из ООО "НТЦ ИТ РОСА" Васильевой? У них там #define объявляет переменную. f() в таком случае наверняка макрос.
>К счастью, в релизе санитайзера нет.Исправил.
Там починили локализацию в многопотоке?
Что-то кроме ворнингов ничего полезного, разве что улучшена поддержка армов. Все прошлые обновления добавляли интересных оптимизаций или хотя бы защит.
ты точно прочел новость?
Я что-то пропустил?
Да.
> Да.Исчерпывающий ответ и грамотная аргументированная позиция, аплодирую стоя. Я, в свою очередь, могу пояснить свою позицию: никаких видимых улучшений не добавили. У 10 были осязаемые улучшения PGO и lto (скажем, поддержка zstd), дополнительная заметная логика у ipa. В 9 добавили значительные усовершенствования для PGO и LTO (наверное, самые ощутимые за всё время gcc) В 8 добавили stack-clash-protection и cf-protection. В 7 и 6, ну, подсказки к ошибкам, например. В 5 no-semantic-interposition.
Вливайся в стан разработчиков. Пора братан пора.
>для для сборки GCC 11 теперь требуется как минимум GCC 4.8.Враньё, не собирается.
минимум GCC 4.8 <- судьба жадных компании которые знали у кого была лучшая вариация
>судьба жадных компании которые знали у кого была лучшая вариацияМой мозг не уловил в этом сообщении логический смысл.
Значит ты еще безработный
ура опеннетные боты подъехали
Отличный набор изменений.
Это вам не сопли от команды Rust
ебилды уже подвезли)
в принципе, сам себя откомпилировал.
10 версия у меня пару пакетов собрать не могла. Посмотрим что с 11
Какие, если не секрет, 10-я не смогла?
ура пересборка мира?
Это последний выпуск? Потом все на LLVM переходят?
>Это последний выпуск? Потом все на LLVM переходят?Пермиссивный LLVM пилится на деньги корпорастов. Нет! LLVM не нужен, "GNU Compiler Collection" - наше всё!
Да здравствует великий Столлман!
Уж который год это от любителей проприетарщинки слышно.
настолько жырные не проходят даже в /dev/null
А че никто не пишет про компилирование Go через GCC?
Обожаю читать комментарии к таким новостям. Радостно, что столько профессионалов тут. Вот бы собрать всех в одной команде, это же дрим тим.
Модули из "стандарта" С++20 хоть куда-нибудь завезли?
И ренджи тоже
Да, в gcc 11 и в Visual Studio 2019.А clang всё шлангует...
Про модули обычно пишет Паскальщик. Ты скрытый паскальщик?
И ренджи тоже в Visual Studio 2019 и gcc есть.
>Visual Studio 2019ничтожество зашкварилось.
А кто нибудь в курсе, почему в gcc не реализовано расширение "свойства", которое есть в msvc и clang?
вот это?
__declspec( property( get=get_func_name, put=put_func_name ) )
штука весьма полезная и не перекрывается существующими возможностями (в частности перегрузкой операторов и т.п.)
вполне перекрывается если знать С++...
Не особо понятно, зачем вообще нужны "свойства", если они тривиальные. В C# эта фигня изрядно бесила, обычные мутаторы-инспекторы из С++ очевиднее и нагляднее. Имхо, properties - бесполезный сахар.
Тривиальные и не нужны. А вот зачем нужны: есть огромный проект. Нужно его изучить. Если некоторое поле некоторой структуры/класса сделать свойством, и например в геттер и сеттер ставить точки останова, или вывод логов, то можно понять где и как это поле используется. Заодно компилятор отловит все места где есть попытки получить адрес этого поля. Т.е. помимо синтаксического сахара, еще и рефакторинг/отладка/анализ кода.
Самое главное что нужно знать:
> Компилятор теперь должен поддерживать стандарт C++11 (ранее требовался C++98), т.е. если для сборки GCC 10 достаточно было наличия GCC 3.4, то для сборки GCC 11 теперь требуется как минимум GCC 4.8.Поясняю - разработчики сами пишут на старом стандарте языка, и всё у них прекрасно получается. Но вам навязывают новые стандарты. Ну что бы жиСь скучной не казалась.
При этом браузер месячной давности уже протухает и не открывает свежайшие сайты.
Ну так браузер мы как нада пишем - не только на наираспоследних версиях компилятора, но еще и придумали отдельный нескучный язычок, который вообще каждый день новый.
Капец, прочитал предложение, перевернул смысл с ног на голову.
Пиши хоть на C++98, тебе как пользователю компилятора никто не запрещает. Сам компилятор теперь для своей сборки требует C++11, а не для кода, который ты быдлокодишь.
> Добавлена экспериментальная поддержка типов для параллельной обработки данных (SIMD, Data-Parallel Types).Ну вот совершенно эталонное деръмо.
Все эти SIMD очевино зависят от процессора, платформы и т. д. То есть фактически имеют уровень Ассемблера. Нет конечно ничего плохого в том чтобы компилятор производил оптимизацию с использованием этих инструкций (SIMD и тп) и даже очень приветствовалось бы, но вынос этого на уровень языка и соответственно забот программиста фактически вынуждает писать код уровня Ассемблера. Программиста вынуждает. Вместо компилятора. Опять же нет ничего особенно плохого в Ассемблере и его применении, но... Ассемблер и так доступен тем кому необходим. Здесь же разработчики компилятора по-видимому вынуждают программистов на C писать код фактически на Ассемблере, видимо потому что компилятор у них не способен, но этот фактически ассемблерный код ещё и предлагается оформлять не свойственным Ассемблеру образом. Очевидные проблемы скажем при переходе на другую платформу в итоге очевидно переходят в код на C (без всяких особых преимуществ взамен).
> Номера столбцов в диагностических сообщениях теперь отражают не счётчик байт от начала строкиЕщё немного деръмеца в подливку...
Шо, нравится байтики считать? Ну это пока в диагностический выхлоп Юникод не попадает, в особенности UTF-8, с его кодированием переменной длины.