Разыскивается конвертер Java2С++

или можно такую штуку накидать по-быстрому на java2xml + JavaML + clojure/abcl

но да, мне всё ещё интересен твой подход, анонимус

У ServerSocket есть своя реализация. Некоторое количество native методов надо будет написать самому или просто вытащить из JVM, ничего невозможного.

Это не важно. В стандарте языка С++ про это ничего нет.

ЕСТЬ. 12.8.31. Ты бы тот стандарт сначала прочитал.

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

Т.е. моя позиция: Автоматическая ковертация java2c++? Нет пути!

написать самому

Но вопрос же стоял об автоматическом конверторе как я понял.

Кроме того йава она ведь не только уборщиком сильна, у неё ведь стандартная библиотека - огого.

Плюсую, чего только работа со строками стоит. На плюсах с этим траблы из коробки. Обычное для JAVA погромистов toUpperCase() превращается в пытки на C++ при работе с UTF-8 :)

Это руками видимо.

Это не важно. В стандарте языка С++ про это ничего нет

а какая разница, мы ж про оптимизацию не думаем ;) просто пишем самый простой вариант

Демокод должен быть демокодом. Простым. Понятным. Корректным.

в данном случае у него все так и есть, кроме одного - как раз нужное поведение он не реализовал

Потому что используются коннотации в человеском сознании;)

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

Даже думать о всяких там RVO и r-value references не нужно.

о них везде можно не думать, вообще думать не всегда нужно, а иногда даже вредно

ну и наххрен не нужен тогда такой конвертер

Спасибо. Мои сведения устарели. Но в данном случае приходится делать допущения о структуре класса. Некрасиво.

Но вопрос же стоял об автоматическом конверторе как я понял.

Ну, очевидно, автоматический конвертор подразумевает наличие определенного рантайма.

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

Я и говорю. Замените string на MyClass, оператор на MyMethod и получите, что код не очень красивый. Точнее, для продакшна вполне годный, но как абстрактная демонстрация для обсуждаемого вопроса - не очень.

Тогда С++11-way:

Circle&& newStandardCircle()
{
	return std::move(Circle(10));
}

Ты уверен что там нет какого нибудь JAXB или Executor Services?

Я просто писал на Glibmm и все, использовал гномовские строки и т.д. Но это ясное дело для наколенных поделок для себя

passes a quick ocular inspection

лол

Тоесть циклические ссылки разруливать не обязательно?

Я так понимаю, что никто не додумался спросить ТСа зачем это ему? И плюс, готов ли он почти гарантированно получить глюкодром с сегфолтом через минуту?

Region analysis вместе со смартпоинтерами во многих случаях спасут.

А если не спасут?

Красота! Все-таки С рулит.

По спецификации — нет, деталь реализации. Но естественно, абсолютное большинство реального кода требует нормальную сборку. А оставшаяся часть — не требует никакой сборки вообще.

ЕСТЬ

таки там просто разрешается, компилятор может и не уметь данную оптимизацию

Красота! Все-таки С рулит.

~$ cat 1.c
#include <stdio.h>

struct buf
{
	char data_[ 1000000 ];
};

struct buf newBuffer()
{
	struct buf b;
	return b;
}

int main() {
	int s = 0;

    for( size_t i = 0 ; i < 10000 ; ++i )
		s += newBuffer().data_[ i ];

	printf( "%d\n", s );
}

~$ gcc -Ofast -std=c99 ./1.c && time ./a.out 
0

real	0m0.347s
user	0m0.348s
sys	0m0.000s

~$ cat 1.cpp
#include <stdio.h>

struct buf
{
	char data_[ 1000000 ];
};

buf newBuffer()
{
	return buf();
}

int main() {
	int s = 0;

    for( size_t i = 0 ; i < 10000 ; ++i )
		s += newBuffer().data_[ i ];

	printf( "%d\n", s );
}

~$ g++ -Ofast ./1.cpp && time ./a.out 
0

real	0m0.000s
user	0m0.000s
sys	0m0.004s

ага, он заставляет тебя использовать malloc/free и постоянно следить за памятью ;)

Зато сразу все прозрачненько!;)

std::move() это тоже прозрачнее некуда. И гарантирует.

Circle&& newStandardCircle()
{
	return std::move(Circle(10));
}

кстати, fail, возвращается ссылка на «мусор»:

~$ cat 1.cpp
#include <cstdio>
#include <cstdlib>
#include <utility>

struct Circle
{
	Circle( int r ) : r_( r ) {}
	int r_;
};

Circle&& newStandardCircle()
{
	return std::move(Circle(rand()+1));
}

int main() 
{
	int r = newStandardCircle().r_;
	printf( "%d\n", r );
}
~$ g++ -Ofast -std=c++11 ./1.cpp && ./a.out 
0

и кстати clang об этом сообщает, а gcc молчит, за что ему жирный минус

Точно, это reference to temporary и rvalue references тут не исключение. Видимо все полагаются на RVO.

И что же именно запущено?

~$ gcc -Ofast -std=c99 ./1.c && time ./a.out
0

real 0m0.347s
user 0m0.348s
sys 0m0.000s

~$ g++ -Ofast ./1.cpp && time ./a.out
0

real 0m0.000s
user 0m0.000s
sys 0m0.004s

Возможно я кэп, но проблема в этом примере не с языком, а с его оптимизатором в gcc.

$ gcc -O -std=c99 ./1.c && time ./a.out
0

real	0m0.001s
user	0m0.000s
sys	0m0.000s
$ gcc -O ./1.cpp && time ./a.out
0

real	0m0.001s
user	0m0.000s
sys	0m0.000s

Хотя нет. Разница в оптимизаторах скорее всего следствие типонебезопасности Си и тогда дело всё таки в языке. Но в любом случае пример wota не говорит ничего о производительностях языков Си и Си++ по отношению друг к другу.