This

[sergey butov]

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

class name{.....


........ void NAME(){
short x[]={2.67.23.56.34.........}
//далее приходица делать следующее
char *a=new char[n];
short c=0;while (c<n){
a[c]=(char)x[c];c++;}
return;}

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

........ int NAME(){
short x[]={2.67.23.56.34.........}
return (int)this;}

чтобы читать массив прямо из тела программы, но я не могу понять на что конкретно указывает указатель? при попытке пролистать код я не могу найти свой массив символов, хотя пробовал возвращать и просто this и (*this). если можете порекомендовать, как правильно делать подобные вещи, очень прошу Вас выложить Ваш совет тут или, если это для Вас затруднительно, то по моему текущему почтовому адрессу:

sergey-butov@yandex.ru

 

[grigsoft]

Думаю, выражу общее мнение, если скажу что ничего не понятно из твоего поста - и кривой язык прекрасно дополняет невнятные name, NAME, x. Какая задача стоит? какие проблемы - ничего не описано.
Предположу что выражение

const char* s = "Моя строка";

тебе может помочь.

 

[sergey butov]

На самом деле помоему я задал вопрос - "...чтобы читать массив прямо из тела программы...", а примеры, которые я привёл, конечно оставляют желать лучшего, но повторюсь - я ещё учусь и для того, чтобы Вы мне не делали зимечания по поводу величины поста, я решил их написать сокращённо. Что конкретно непонятного в этих примерах? Строки, как их пишут по классике и строки, как их пишу я - это разные вещи, но не считаете ли Вы, что мне требуется поместить здесь весь код? Допустим, что я буду писать массив сразу в char, а как тогда быть с графическими символами и например с символами кириллицы?

 

[grigsoft]

Ну так строка в С - такой же массив как и из int. Что мешает так:

const char szText[] = {0x78, 0x79, 0x20, 7, 0};

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

Строки, как их пишут по классике и строки, как их пишу я - это разные вещи

Ну что тут скажешь

 

[sergey butov]

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

да и стати, венгерской нотацией для консоли я не пользовалса.... пока что)))

 

[European]

ох уж мне эти венгры! Накой тебе this вообще? В классе определена строка и ту хочешь получить указатель на нее? Ну так сделай метод, который будет возвращать указатель на строку, если ты считаешь, что такой подход безопасен. Корректно поставь вопрос, в конце концов

да и стати, венгерской нотацией для консоли я не пользовалса.... пока что)))

 

[sergey butov]

Про на кой оно мне нужно скажу только, что в кач эксперимента. Вообще в написании кода я пытаюсь отказываться не только от средств С++ но и использование средств С я тоже пытаюсь свести к минимуму.... например вместо if использовать тернарные операцыи выбора(не говоря уже о switch))). стараюсь уменьшать количество циклов и тд и тп и др... это, как показывает моя, хоть и не большая, но всё же практика, очень влияет на скорость и обьём приложения, а нащот вопроса...попытаюсь обьяснить ищо раз. вот есть массив так? (пока что неважно, какого типа данных). Как мне сделать указатель на него? Только вопрос в том, что указатель должен указывать на его расположение в теле приложения, а не на выделяемую под него статитескую или динамическую память? Я уже говорил, что пытаюсь создать, скажем так, неиспользуемую функцию, которая содержит только статический массив и возвращает указатель на себя, а потом исходя от этого указателя, пытаюсь получить доступ к этому массиву, зашитому в коде приложения, а не к памяти, выделяемой под него..... Надеюсь, что так будет понятно, потому что понятней обьяснить я уже не в силах))))

P.S. Там, стати, в коде, который я пыталса привести я пропустил скобки функций. Это ответ на Ваш вопрос по поводу name и NAME... сорри)))

 

[grigsoft]

Гм. А заглянуть в ассемблер твой опыт позволяет?

if (A)
B;
else
C;

Превратится в

А;
jz M1;
B;
jmp M2;
M1:
C;
M2:

На чем именно по твоему экономит тернарный ?: ?
И даже switch добавит всего лишь дополнительный cmp ax, CONST для каждой ветки. У тебя есть реализация лучше? Хотелось бы взглянуть. При этом оптимизировать-то его конечно можно, но далеко не тернарными операциями, а байт-к-байту ручками в асме.
По теме - как бы ты массив не объявлял, он все равно в данные ляжет. Если тебе неймется положить строку реально в код, то в MSVC это можно сделать так:

static void MyFunc()
{
// mark: 4 bytes
goto LABEL1;
__asm
{
_emit 0xFF
_emit 0xFE
_emit 0xFD
_emit 0xFC
}
LABEL1:
...

Но:
1. Это не стандарт - для других компиляторов будут (если будут) другие инструкции.
2. Не забываем про несколько дополнительных байт заголовка функции, который компилятор всегда добавляет. Впрочем, это, кажется, можно отключить.

 

[sergey butov]

Ну вот уже чтото похожее))))..... На самом деле х86 я не знаю и пока мне нет времени (учоба) для его изучения, поэтому приходица судить по 8мибитному и использовать древние методы))). О тернарных операторах придумал не я, а вроде как препад сказал. Но соприть не буду ( хотя обычным замеров времени есть всё таки разница, правда незначительная но всё же)... чтоже касаеца массива и его чтения из тела программы то..... я же говорю, что хотел поэкспериментировать.... ведь зачем переписывать массив ещо раз если он уже есть в коде? Впрочем можно его оформить отдельным файлом и всё такое, но подгрузка не всегда приемлема да и ведь интересно же ))))) Вдобавок, я сторонник выворачивания своего компьютера наизнанку

ЗЫ: Посибо)

ЗЗЫ: MSVC rulezzz!!!

 

[grigsoft]

Разница будет только в простейшем случае:

a = (i>0) ? i : 0;

будет быстрее чем

if (i>0)
a = i;
else
a = 0;

Но это и все.

Так копировать массив как раз ты собираешься - все остальные спокойно используют строку как есть - без лишних копирований.

 

[sergey butov]

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

 

[grigsoft]

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

 

[sergey butov]

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

 

[sergey butov]

Для: grigsoft

Стати, сансэй , а раз уж Вы шарите в х86, то можыт дадите ссылочку на таблицу работы команд по тактам, и воопще, порекомендуете литературку качнуть для начинающих? Оч хотелось бы...

 

[grigsoft]

Не, в асме я почти не шарю - хотя 10 лет назад в универе и учил, на практике опыт есть только в отладке без исходного кода. Таблицу тактов, уверен, можно найти в сети, а книжки - в мое время классикой был Абель, но тогда мало что читать было. Для обычного программиста любой книжки будет достаточно чтобы научиться читать код без особых проблем.

 

[European]

Для: sergey butov
Очередное изобретение велосипеда, причем неясно какого. Вам, видимо, слова совместимость, переносимость и сопровождение кажутся пустым звуком. Хотя для троянов и вирей сопровождение до одного места

 

[sergey butov]

На самом деле что касаеца книг по асемблеру то описание команд я нашол, есть и книга, но не бесплатно и очень похоже на лохотрон ( нужно отослать смс за 0.5 доллара). А вот таблицы тактов чота я не нашол. По поводу совместимости и тд., ну чтож, я ещо не работал в команде и только начал учица, но всё ищо впереди.

ЗЫ: С ПРАЗДНИКОМ!!!

 

[European]

<!--QuoteBegin-sergey butov+23:02:2007, 14:43 -->
<span class="vbquote">(sergey butov @ 23:02:2007, 14:43 )</span><!--QuoteEBegin-->я ещо не работал в команде и только начал учица, но всё ищо впереди.

[snapback]57048" rel="nofollow" target="_blank[/snapback]​

[/quote]
Да дело даже не в команде, а в страстном желании придумать очередной велосипед, ну да ладно - это твое личное дело. На счет таблицы тактов - все это на сайте Интел. Вот только порытся там придется долго. И что ты подразумеваешь под таблицей тактов? Вероятно ты хочешь узнать размер каждой команды

 

[grigsoft]

Ссылка скрыта от гостей

 

[European]

<!--QuoteBegin-grigsoft+23:02:2007, 15:16 -->
<span class="vbquote">(grigsoft @ 23:02:2007, 15:16 )</span><!--QuoteEBegin-->[snapback]57051" rel="nofollow" target="_blank[/snapback]</div>[/quote]

Такты:
Цифры указывают минимальные значения. Промахи кеша, рассогласование и
исключения могут увеличить количество тактов.

Толку от количества тактов каждой команды в голом виде практически нет

Выдержки из книги С.В.Зубкова по Assembler-у (Глава 9, посвященная оптимизации):

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

Проблему оптимизации принято делить на три основных уровня:

Выбор наиболее оптимального алгоритма — «высокоуровневая оптимизация».
Наиболее оптимальная реализация алгоритма — «оптимизация среднего уровня».
Подсчет тактов, тратящихся на выполнение каждой команды, и оптимизация их порядка для конкретного процессора — «низкоуровневая оптимизация».

9.1. Высокоуровневая оптимизация
Выбор оптимального алгоритма для решения задачи всегда приводит к лучшим результатам, чем любой другой вид оптимизации. Действительно, при замене пузырьковой сортировки, время выполнения которой пропорционально N2, на быструю сортировку, выполняющуюся как N * log(N), всегда найдется такое число сортируемых элементов N, что вторая программа будет выполняться быстрее, как бы она ни была реализована. Поиск лучшего алгоритма — универсальная стадия, и она относится не только к ассемблеру, но и к любому языку программирования, поэтому будем считать, что оптимальный алгоритм уже выбран.

9.2. Оптимизация на среднем уровне
Реализация алгоритма на данном конкретном языке программирования — самая ответственная стадия оптимизации. Именно здесь можно получить выигрыш в скорости в десятки раз или сделать программу в десятки раз медленнее, при серьезных ошибках в реализации. Многие элементы, из которых складывается оптимизация, уже упоминались — хранение переменных, с которыми выполняется активная работа, в регистрах, использование таблиц переходов вместо длинных последовательностей проверок и условных переходов и т.п. Тем не менее даже плохо реализованные операции не вносят заметных замедлений в программу, если они не повторяются в цикле. Практически можно говорить, что все проблемы оптимизации на среднем уровне так или иначе связаны с циклами, и именно поэтому мы рассмотрим основные правила, которые стоит иметь в виду при реализации любого алгоритма, содержащего циклы.

9.3. Низкоуровневая оптимизация
9.3.1. Общие принципы низкоуровневой оптимизации
Так как процессоры Intel используют весьма сложный набор команд, большинство операций можно выполнить на низком уровне очень многими способами. При этом иногда оказывается, что наиболее очевидный способ — не самый быстрый или короткий. Часто простыми перестановками команд, зная механизм выполнения команд на современных процессорах, реально заставить ту же процедуру выполняться на 50 – 200% быстрее. Разумеется, переходить к этому уровню оптимизации можно только после того, как текст программы окончательно написан и максимально оптимизирован на среднем уровне.

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