вот в таком коде


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

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



Это сообщение отредактировал(а) Lazin - 15.1.2008, 11:57

Статические переменные и функции класса можно рассматривать как обычные переменные и функции в пространстве имён, но имеющие доступ к приватным членам класса.

Пример:

мне оно не нравится потому, как если есть

то я не могу написать


я знаю, что можно std::vector<int> затайпдефить, но все равно это уже не то...
ибо по смыслу мне нужен итератор именно для типа ЭТОЙ ПЕРЕМЕННОЙ а не для ЭТОГО ТИПА

Это сообщение отредактировал(а) Alek86 - 15.1.2008, 12:12

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

а компилятор немного подумает и определит тип переменной i

да вот, ждем-с 

правда, все равно неясно почему написать так (как в вопросе) нельзя...

Это сообщение отредактировал(а) Alek86 - 15.1.2008, 12:48

потому-что у оператора :: другой смысл, это было-бы нелогично

Добавлено через 1 минуту и 20 секунд

в языке D это уже есть

потому что оператор :: левым операндом должен иметь тип, а не переменную

Fazil6, а почему?
(меня как раз именно это и интересует)

Alek86, считай недоработка языка. Идеального ничего не бывает.

ну видимо потому, что есть точка и стрелка для доступа к членам и нафига здесь еще и :: , а выковыривания типа из объекта вроде

это совсем уж другая задача. Ведь в объекте нет описания этого типа (я так думаю). Т.е компиллятору нужно будет определить, что это за тип такой объекта v и уже из него добывать, а тут еще наследование может под ногами путаться, и тем более если позволить добывать таким оператором переменные из объектов, то получается неоднозначность между тем чего мы хотим (тип или переменную, typename вроде тока в шаблонах можно применять)

я больше мнения bsa придерживаюсь (ну, или может исторические причины)

Fazil6, вроде, наследование никак повлиять не может, ибо статические виртуальные функции невозможны, и, поскольку С++ контекстно-зависимый, то и без того неоднозначностей хватает... В шаблонах typename из-за того, что не всегда виден контекст....

Alek86, доступ к статическим функциям возможен через точку или стрелку!

mes
Base::f()

ну, это знаю...
меня больше внуитренние типы расстраивают )

мес, любая невиртуальная функция будет работать, как невиртуальная

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

Fazil6, и что?

Потому, что v - это не scope .

Возможность писать v.static_mem была сделана лишь для шаблонов.

каюсь, не понимаю, что такое scope

ты хочешь сказать, что есть ситуация при которой компилятор не мог бы знать, что ему подставлять заместо v::iterator даже если v - указатель на базовый класс?

как же тогда собираются ключевое слово auto менять?

Scope - это область. Область видимости. Область действия... Как хочешь.
Оператор :: применяется для разрешения(resolving) областей и применяться он должен именно к scope, а не к lvalue/rvalue.



Я подумаю над примером.


auto - был(и есть сейчас) storage specifier. В С++09 он будет иметь совсем др. смысл.
Ну а, то что ты хочешь будет реализовываться другим кл. словом:


Добавлено через 7 минут и 31 секунду
Ну вот простой пример:

наверна я перетрудился, ибо не понял даже, для чего нужно

завтра с утра попробую осилить 

Это два примера использования одного и того же имени для упоминания совершенно разных сущностей:
1. v - тип, определённый in global scope.
2. v - локальная переменная(аргумент типа V, который в свою очередь является ::v).

Выбор сущности в данном случае зависит от способа использования(:: vs <<).

не, все-таки давай завтра сутра 

имхо, тогда мог бы и полегче пример придумать 
к примеру


я же имел в виду, что

(где v- переменная) мог определять единственно возможную сущность (если не в шаблоне)

а я думал это будет называться typeof...

Это так в Boost.TypeOf его обозвали .



Я тебе привёл пример, где мог и не определять .

Это сообщение отредактировал(а) warmonger_ - 15.1.2008, 22:14

archimed7592, warmonger_, я знаю, как это можно "обойти"
можно и бьез шаблонов для каждой переменной тайпдефить свой тип (кстати, слыхал, это рекомендуют), и тогда можно безбоязно писать

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


вопрос был именно в том, почему такая "проблема" не предусмотрена на уровне языка, который считается объектно-ориентированным
на этот вопрос получил только 2 ответа - от bsa и Fazil6 (с последним я не согласен, но то скорее мои проблемы  )

Это сообщение отредактировал(а) Alek86 - 16.1.2008, 11:09

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


Вам это надо?

вопрос и не в этом был

не "почему переменные не могут восприниматься как типы", а "почему внутренние типы классов можно получить только у типов, и нельзя у переменных этого типа". Статики сами собой как-то приклеились...

Alek86
Представь, что можно получит доступ к типу через точку, тогда что будет значить запись:Ты можешь однозначно сказать, это объявление функции или определение переменной? Я - нет. А чтобы это сказать придется перерыть кучу кода, чтобы узнать какому типу принадлежит a, и где этот класс описан. Оно надо?

bsa, логично 

ну и последняя в этом отношении непонятка - почему оператор :: используется только для типов?

для типов и пространств имен

Добавлено через 1 минуту и 6 секунд
по моему это вполне логично, если есть оператор . и -> для переменных, то должен быть соответствующий оператор и для типов

Можно было бы конечно сделать:


а без typename объявление переменно.

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

я понимаю в чем твой вопрос. Ты не совсем понимаешь, что я имею в виду

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

хм... А применительно к объекту он какой возможный функционал может реализовывать, если учесть, что получение встроенного типа из объекта нафиг не нужно и это логично?

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

Скорее проблема в генах (моих) если остальным это так очевидно, потому предлагаю тему закрыть