С++ vs Java

[lexar]

Не нравится не пиши И прошу других тоже заметить что никто никого не заставляет.


Расскажи о недостатках ! (достоинства я знаю )

Это о С++? - На раз-два.
1) точка с запятой в конце объявления класса. Убил бы.
2) два синтаксиса доступа к статическим и не статическим членам
(:: и .) , причем, :: еще используется для открытия области видимости.
3) Си-шный двумерный массив, который передавать можно только как одномерный.
4) Задолбенистый способ ограничения видимости через два спецификатора, один в заголовке объявления, другой - внутри.
5) Несколько способов объявления inline.
6) Аппаратно-зхависимая интерпритация размерности основных типов.
(во радость-то, int на разных платформах может быть 16,32,64...)
7) Два способа инициализации членов класса: после двояточия и через
равенстово в конструкторе.
8) Отсутствие инициализации членов при объявлении.
9) Несколько разных синтаксисов объявления inline.
10) Отсутствие в языке нормальных строк.

Да, еще обожаю писать class template в объявлении темплейтов
на каждом углу.

Это так, на вскидку - не задумываясь.

[THRESHE]

точка с запятой в конце объявления класса. Убил бы.

Это большая помеха ?

Аппаратно-зависимая интерпритация размерности основных типов.
(во радость-то, int на разных платформах может быть 16,32,64...)

Для этого есть sizeof ()

Отсутствие в языке нормальных строк.

что это за ненормальные строки ?

Два способа инициализации членов класса: после двояточия и через
равенстово в конструкторе.

Тоже мне недостаток =)

[pal]

1) точка с запятой в конце объявления класса. Убил бы.

#include <iostream>
int f = 1;
void g ( ) {
class C { public: C ( int ) { } } f = 0;
}
int main ( ) {
g();
std :: cout << f << std :: endl;
}
что по вашему должна выводить эта программа ?
врядли необходимость вписывать один символ можно считать проблемой, т.к. компилятор сообщает о пропущенных точках с запятой

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

#include <iostream>
int main ( ) {
class B { public: static void f ( ) { std :: cout << "B\n"; } };
class A { public: void f ( ) { std :: cout << "A\n"; } };
A B;
B.f ( );
}
а эта ?

3) Си-шный двумерный массив, который передавать можно только как одномерный.

с этого момента поподробнее

4) Задолбенистый способ ограничения видимости через два спецификатора, один в заголовке объявления, другой - внутри.

тоже непонятно, о чем речь

5) Несколько способов объявления inline.

это о том, что функции, описанные внутри класса получают inline по умолчанию ? дык, это ж тот самый syntactic shugar, за отсутствие которого ругают с++
не говоря уже о том, что оптимизирующий компилятор сам инлайнит все, что сочтет нужным и не инлайнит все, что не сочтет

6) Аппаратно-зхависимая интерпритация размерности основных типов.
(во радость-то, int на разных платформах может быть 16,32,64...)

int имеет размер натурального машинного слова платформы. и не припомню, чтобы он мог быть 64 бит.
даже в с есть стандартные типы int{8,16,32,64}_t и компания
пользуйтесь на здоровье

7) Два способа инициализации членов класса: после двояточия и через
равенстово в конструкторе.

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

8) Отсутствие инициализации членов при объявлении.

опять непонятно, о чем речь

9) Несколько разных синтаксисов объявления inline.

это вроде уже было

10) Отсутствие в языке нормальных строк.

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

Да, еще обожаю писать class template в объявлении темплейтов
на каждом углу.

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

Это так, на вскидку - не задумываясь.

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

[pal]

И что это ?

судя по названию, список недостатков

[lexar]

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

Неа.
Все гораздо проще:
я просто, может не совсем корректно, перечислил то,
что поправили в более поздних языках.
Извините, не напрягался и более подробно расшифровывать свои пункты не буду (типа и не напрягусь)
Но идея простая:
языки развиваются.
И С++, послуживший основой для Java и C#,
имеет достаточно кривых синтаксических и семантических конструкций,
которые поправили.
Поэтому - недостатки есть, отрицать их бессмысленно.
И вообще, идеальных решений не бывает.
Говорить "не вижу недостатков" в какой-либо области,
это либо лукавить, либо ... действительно не видеть
Но лучше видеть

[pal]

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

поправили так, что теперь вместо
class A { } a;
надо писать
class A { }
A a;
?
или что теперь нельзя объявлять локальные классы внутри функций ?
голову отрубили а насморк остался

[lexar]

поправили так, что теперь вместо
class A { } a;
надо писать
class A { }
A a;
?
или что теперь нельзя объявлять локальные классы внутри функций ?
голову отрубили а насморк остался

А я и не говорил, что насморк не останется.
Просто, языки развиваются.
Для совместимости остается весь старый синтаксис.
Естественно это местами криво.

Есть более серьезные проблемы.
Например, С++ - однопоточный язык.
Все поточные средства - внешние.
Ява и C# - многопоточные,
что уже приятно.

[lexar]

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

Повеселили.
Ваше утверждение противоречить принципу раздельной компиляции.
Компилятор не может инлайнить все что сочтет нужным -
потому как не знает, кто рвется к вашей функции из другого объектного модуля.
Он может пытаться инлайнить только явный инлайн!
Если получится

[pal]

С++ - однопоточный язык.
Все поточные средства - внешние.
Ява и C# - многопоточные,
что уже приятно.

пока что ни один язык с родной поддержкой потоков не делал этого полноценно. примерно как с вводом/выводом

Повеселили.
Ваше утверждение противоречить принципу раздельной компиляции.
Компилятор не может инлайнить все что сочтет нужным -
потому как не знает, кто рвется к вашей функции из другого объектного модуля.
Он может пытаться инлайнить только явный инлайн!
Если получится

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

[THRESHE]

судя по названию, список недостатков

Не похоже Или недостатков на несколько десятков страниц

[lexar]

пока что ни один язык с родной поддержкой потоков не делал этого полноценно. примерно как с вводом/выводом

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

Господин хороший, вы говорили не о явном объявлении,
а об "умном компиляторе", который сам решает.

Что будет если я построю библиотеку,
в которой компилятор по своему усмотрению
решил реализовать какую-то функцию, как инлайн?

Ее просто не будет!
К ней не прилинкуешься.

Так что инлайн реализуется по возможности при явном
объявлении функции в качестве inline.
И то только по возможности.
Это рекомендательное объявление.

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

[pal]

Господин хороший, вы говорили не о явном объявлении,
а об "умном компиляторе", который сам решает.

Что будет если я построю библиотеку,
в которой компилятор по своему усмотрению
решил реализовать какую-то функцию, как инлайн?

Ее просто не будет!
К ней не прилинкуешься.

Так что инлайн реализуется по возможности при явном
объявлении функции в качестве inline.
И то только по возможности.
Это рекомендательное объявление.

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

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

[pal]

Не похоже Или недостатков на несколько десятков страниц

ну, на список достоинств тоже не похоже

[THRESHE]

ну, на список достоинств тоже не похоже

Помоему это просто изложение стандарта С++

[pal]

Помоему это просто изложение стандарта С++

нет, active issues - это неразрешенные разногласия
в стандарт могут попасть только их разрешения

[lexar]

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

Вы утверждаете что это определено стандартом языка?
Что это справедливо для всех компиляторов?

[lexar]

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

Что бы не быть голословным.
Только что. Мелкомягкая студия 2005
Консольное приложение на с++

Файл 1:
#include "stdafx.h"
#include <iostream>

using namespace std;

void f();
void z();

int _tmain(int argc, _TCHAR* argv[])
{
z();
return 0;
}

inline void f() {cout << "aaa"<<endl;}

Файл 2:
#include "stdafx.h"
void f();
void z()
{
f();
}

КАК И СЛЕДОВАЛО ОЖИДАТЬ
ЕСЛИ УБРАТЬ INLINE - ВСЕ РАБОТАЕТ
C INLINE - ОШИБКА ЛИНКОВКИ.
Error 1 error LNK2019: unresolved external symbol "void __cdecl f(void)" (?f@@YAXXZ) referenced in function "void __cdecl z(void)" (?z@@YAXXZ) z.obj

БОЛЕЕ ТОГО: ТАК ОНО И ДОЛЖНО БЫТЬ.
КОМПИЛЯТОР НЕ ОБЯЗАН ЛЕПИТЬ ГОРБАТОГО,
ТАМ ГДЕ ЕМУ ЭТОГО НЕ УКАЗЫВАЛИ.

[pal]

Вы утверждаете что это определено стандартом языка?
Что это справедливо для всех компиляторов?

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

[lexar]

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

Да доступна она,
доступна.
Только через #include.
Потому их всегда и объявляют в h файлах,
хотя стандартом это не определено.

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

[pal]

КАК И СЛЕДОВАЛО ОЖИДАТЬ
ЕСЛИ УБРАТЬ INLINE - ВСЕ РАБОТАЕТ
C INLINE - ОШИБКА ЛИНКОВКИ.

попробуйте вызвать функцию в том файле, где она определена. примерно так
[pal@underdark tmp]$ cat a.cpp
void g ( );
inline void f ( ) { }
int main ( ) {
f ( );
g ( );
}
[pal@underdark tmp]$ cat b.cpp
void f ( );
void g ( ) {
f ( );
}
[pal@underdark tmp]$ g++ -Wall -Wextra -o a a.cpp b.cpp
[pal@underdark tmp]$ ./a
это несколько надуманный пример, реальный пример будет с использованием #pragma interface/implementation и там будет все в порядке.
однако, мы отклонились от темы.
началось с того, что вы утверждали, что компилятор не может встраивать функции по собственному желанию,
а пример несколько о другом!