class between
{
public:
int pre;
int post;
public:
// 전위 연산자 정의
between& operator int(int n)
{
pre = n;
return *this;
}
// 후위 연산자 정의
between& operator (int n)
{
post = n;
return *this;
}
};
class and
{
private;
int start;
int n;
public:
//전위 연산자 정의
and& operator between(beetween b)
{
n = b.pre;
start = b.post;
return *this;
}
bool operator (int end)
{
return start <= n && end >= n;
}
};
bool b = 5 between 0 and 9;
이런 식으로 쓸 수 있다면 좋을듯 ㅋㄷㅋㄷ
ps
예제에서 다른 연산자 오버로딩과 겹치는 부분이 좀 있을수있는데 그런건 좀 배제하고 봅시다.^^
내가 고려하는 문제엔 컴파일속도도 포함돼. c++ 도 좀 심각함.
난 program.님이 그래도 생각이 좀 있을줄 알았는데 이정도로 멍청할지는 생각도 못했네... between은 그냥 예를 든거지 저거 쓸려고 공백 연산자를 만들어내려는게 아니자나?
와 진짜 멍청함이 극에 달했네...
니 예가 멍청한거지. 그리고 연산자 오버(라이딩) 으로 기능 확장하는 부분에 대해 생각 안해본 애들도 있겠지만 난 아님.
답답한 구석들이 있지. 하지만 더 답답한 구석은 컴파일 속도라는거.
공백을 건드린다는 자체가 뜨악 한 상황이란건 니가 좀 더 생각해보면 알게 될꺼다.
공백을 건드려서 오버헤드가 발생할거라는건 이미 예상한바다. 하지만 그 오버헤드를 줄이는 여러가지 방법이 있다. 라인 단위 문법오류가 발생하는 부분에서만 공백연산자 참여 객체가 있는지만 검사하면된다.
내가 그정도도 생각 안했을거라 생각지마라
몇수위에서 생각하라 했지?
몇 수 위라니 ㅋㅋ ㅉㅉ 코딩 코짜도 모르는게.
그래서 개발자들이 공백 나올때마다 이게 어느 클래스랑 연결되는 공백인지 고려해야된단 말이냐?
그게 직관적인 코드란 말이냐? 언어를 너만 쓰겠단 말이냐?
그걸 개발자가 왜 고려해? 와 어쩌면 이렇게 핵멍청할수가 있지? 그걸 컴파일러가 검사해야지?
멍청하기가 극에 달하면 이렇게 되는건가?
이 봐라. ㅉㅉ 소스코드를 컴파일러가 짜니? ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
사람 눈으로 보고 한방에 이해안되는 코드를 짤거면 뭐하러 문법을 고려함?
컴파일시 오버해드 얘기하다가 왜 딴데로 빠지니? 멍청한거 들통나서 말돌리니?
아니지, 멍청한 새끼야. 니가 추구한걸 첫째 사람 눈으로 보기 좋고 코딩하기 좋은 c++ 기반 스타일을 재정의해보자. 라는 취지로 이 글을 읽어나간거고
니가 너 스스로 공백에 함정을 파서 파묻히는 꼴을 보며 비웃어주고 있는거지.
너 말고 다른 사람들이 다양한 자료형들에 대해 공백을 재정의할것이고, 그런 소스코드를 니가 받아서 수정해야 된다는 상황을 가정하란거야.
5 between 0 and 9; <= 이 얼마나 보기가 좋냐? 이런식으로 보기 좋은 코딩을하는건 프로그래머의 몫이지
between 앞 뒤의 공백이 연산자인지 공백인지 구분해야 한다는게 얼마나 오버헤드인지 전혀 생각을 안하네. ㅋㅋ
멍청한놈이 멍청하게 코딩하는건 어쩔수없는거고 똑똑한놈이 저렇게 이쁘게 코딩해서 주면 얼마나 가독성이 좋아질까 생각해보려무나
병신이 드리블하네 생각 좀 더 해보렴 그 알량한 몇 수 위에서.
공백 다음에 연산자 없이 다른 객체가 튀어 나왔는데 당연히 공백 연산자로 생각하지. 그걸 생각하는데 너는 뭐 1초라도 걸리냐? 0.1초도 안걸리겠다.
니 뇌는 486급이라 저거 생각하는데 그리 오래 걸리나보다? 그렇다면 인정해줄게
공백의 기능이 n 개라고 등신아.
그 여러가지 가능성 다 생각해보고 말하는거니까 몇수 더 생각해보거라
야 메모리를 더잡아먹잖아 코세는 그런것까지 다 고려해서하는거라고 이허접한프로그래머야
그냥 니가 새롭게 functional language 를 만들어. 뭣하면 c++ AST 하나 긁어서 니가 커스터마이즈 해 보든지.
전화기미만잡이라는게 너같은새끼들때문에 나오는거야
그래서 사람들한테 보여봐. 얼마나 좋아할지. 니가 옳으면 쓰겠지.
전화기미만잡이 여기서 왜 나와? 난 전자 컴공 전공 두갠데.
전자를 배웠다면 저런소리가안나올걸
누가봐도 저건 나중에 치명적인 오류가나올수있는코드여
아 내 이야기가 아니구나.
ㅇㅇ 유동닉들 하여튼 ㅡ,.ㅡ 나도 ㅇㅇ 로 시작했지만 네임스페이스 문제 심각.
저런공백 백개쓴다고생각해봐 엄청나게 심각해질껄
type1 name1; /*공백*/ name1 name2;/* 공백연산자 */ (const) name1 /* 공백연산자 */ name1, name2;/*공백*/
뭐 백개 정도로 컴파일 속도가 무진장 늘어나진 않겠지 당연히. 수백만 라인이 빌드되는 코드가 기본이잖아. 특히 제네릭 환경에서 말야. boost 같은. 그 수백만 라인 안에 공백이 몇 개겠어. 가뜩이나 느려 터졌는데.
문장이 길어질 경우 문제가 될 가능성도 있겠지
그니까 넌 니가 별무리 없이 돌아간다고 가정한 코드 안에서 별문제없이 돌아가는거지.
근데 뭐 한라인에 공백 수백개 쓸일이 그렇게 많냐?
차라리 저거할시간에 c++에 공백 연산기능 하나추가해달라는게 더낫겟다
수백 라인 안에 공백 수개를 이야기 하는거야.
수백만 라인 안에 공백 수개씩.
헷갈리거나 문제가 될거 같으면 그룹화 연산자로 묶으면 된다.
기존에 헤더파일 단위로 만들어진 c++ 제네릭 코드들 모조리 빌드할때마다 피를 뿜을꺼다.
수백라인에 공백 수백개는 아무 문제없다고!
제발 정신좀 차리자
active 하게 스페이스를 사용하는게 아니라 passive 하게 사용한다는걸 기억해. 이미 쓰고 있어. 수없이 많이.
수백만 라인 안에 수개의 공백을 이야기 한다니까 뭔소리.
n * 수백만의 공백을 이야기하는거잖아 등신아.
기존 코드들은 저렇게 짜여 있지 않아 기존 코드들은 무제 될게 전혀 없어. 기존 코드가 저렇식으로 짜여진게 있다면 문법 오류지
제네릭 코드나 헤더파일 라이브러리를 좀 생각해. 모르면 보고와.
혹시나 연속된 공백을 말하는거라면 정말 실망니다. 아니라고 말해줘.
아이고... 모르면 보고와.
저건 레지스터에서 카운트할때도 문제가발생한다
못믿겠으면 직접 연구해서 확률을 적어서내놓길 ^^
넌 고작 표현의 장점 조그마한것 때문에 수없이 많은 코드베이스를 사용불능 수준으로 오버헤드를 만들고 있어.
레지스터 카운터 같은 소리하고 있네 헛소리 말고 사라져
너의 프로그래밍은 학부수준이고 나의관찰력은 박사급
사용 불능 코드 예제점 가져와 보시길;; 생각해둔게 있다면 금방짤거 같은데 가져오면 인정해줄게
당장 boost 라이브러리 좀 쓰면 2초 컴파일 하던게 20초 컴파일로 늘어나는데 니 생각이 참 하찮다.
헤더파일 라이브러리라는게, 제네틱하다라는게 장점과 단점이 있는데 니가 그 단점을 극대화 시키는 오버라이딩을 좋은 아이디어라고 뿌듯해하고 있다는거지. 이익과 손실을 따져보라고.
제네틱이 아니라 제네릭.
2초 하던거 2.1초도 안늘어 날거 같은데? 내가 이미 말했지 기존 대로 컴파일하다가 컴파일 오류만나면 공백연산자 참여 객체의 존재 여부만 검사하면된다고
불과 몇십분전에 말한거다
붕어대가리도 아니고
야이 바보야. 제네릭 헤더 라이브러리 쓰면 두줄짜리 코드도 몇 십초로 늘어날 수 있다니깐?
지금니가 진실을얘기하잖아 존재여부를 검사한다 그것만으로도 시간이늘어나
실제로 수백만 라인으로 익스펜딩되니까 말야.
똑같은 얘기하게 할래? 제네릭 헤더도 마찬가지라고 기존 문법에 맞지 않고 오류가 발생하는 라인만 검사하면 된다고
그 검사가 수천만번으로 늘어난다니까 정신을 못차리네.
그러니까 왜 검사를하게만드냐고 그냥 없이도 할수있게 시스템언어를 하나 니가 개발해
그것도 단 한번의 조건비교냐? 타잎에 따라 재정의한 횟수 만큼 늘어나지?
그래서 니가 얻는 이익이 고작 저거냐고 비웃는거잖아.
너는 일을어렵게하는거야 고문관이냐?
그게 수천 수만번으로 늘어나려면 그 기존 소스가 다 새로운 문법으로 구현 되었을때만 그렇게 된다고 멍충아
니 생각대로 언어 하나 새롭게 만들면 돼. 그럼 됨. c++15 c++16 따위로 적용될 수 있는게 아니란 소릴 하는거야.
제네릭 헤더 라이브러리란 말은, 새 프로젝트 소스코드에 맞춰 새롭게 빌드되는걸 의미한다는거야. 바이너리로 만들어져 있는게 아니라. 등신아.
왜 사람들이 스페이스를 함부로 건드리지 않는지 니 혼자 잘나서 그런게 아니라고 ㅡ,.ㅡ
이미 알아 멍충아 알고 하는소리다.
이새끼 대통령 되면 숨쉬는데도 세금 걷을듯.
공백자체에 어떤 매커니즘이 있다는생각은못해봤니?
스페이스를 함부로 안건드리는건 구현의 할때의 어려움 때문이지 실사용은 문제 없어
168아 그 메카니즘을 효용있게 써보자는게 10 이의 생각이야. 다만, 무리하단 이야길 하는거지 c++ 베이스로 하기엔 특히.
생각은 기발하네
한번쯤은 고민해보는 문제 아님?
손실에 비해 이익이 적어서 보통 포기하지.
흥하네 ㅋㅋ
난 오히려 c++ 의 안쓰는 기능을 줄여서 컴파일 속도를 높이는게 더 실용적이라 생각함 ㅡ,.ㅡ
구현해놓고 나면 왜 진작 안만들었나 싶을거다. 언어 자체가 거의 네이티브 랭귀지 수준으로 변할테니까
c++은안쓰는기능을줄이기에는이미돌아올수ㅇ벗는방향으로스트롭스트롭영감님이가버렸음
egale이그렇타고조탄말은아니고
응 그걸 알기에 내부 개발툴이나 커스터마이즈 할까 생각중.
표준화는 손댈수 없는 수준인게 맞음.
10이가 하나 만들어서 올리면 되겠네. 애써라.
c++은 산으로간지 오래..
c++ 도 소프트웨어다 보니 소프트웨어의 위기, 버전관리 및 수명의 문제를 고스란히 겪고 있는거지.
생각해보는건 좋다만 ㅉㅉ. 아직 개념이 없구나.
생각해 보는건 좋다면서 개념이 없다는건 뭐지? 뭐가 개념이 없다는겨 헛소리 늘어놓고 있네 ㅋㅋ 어떤점에서 개념없다는건지 말을 해보던가
bool 타잎이 뭔지 생각해봐
b 랑 between 이 어케 결합되는지
beetween이 b가 되는게 아니고 and가 b가 되는거다
아이코 잘못봤음. 5 랑 beetween 이랑 먼저 결합되는게 맞잖아?
공백연산자 개념이 추가되는것이므로 기존 C++의 개념을 확장해야지 그대로 생각하면안되
between beetween 소스코드에 웃기게 적어놨네 여튼.
늙은이들 기존 관념에 틀어박혀서 머리가 굳었나 ㅉㅉ
공백을 넣는다는 자체가 공백이 기존에 수행하던 seperator 의 역할을 모호하게 한다는 생각은 안하니?
컴파일러 구조까진 필요없고 토큰 분리만이라도 개념을 갖고 이야기하자.
즉 c++ like 한 언어를 생각한거라면 첫째 넌 5 를 객체화 해야함.
5를 꼭 객체화 해야한다는건 니생각이고 5다음에 공백연산자가 오고 그다음 객체에 공백연산자가 포함되있나만 검사하면되
잼은있네요
그 생각을 안해봤을줄 아냐? 지적질할려면 몇수 위에서 더 생각해 보고 하자
아주 많은 문법적 이탈을 기본전제로 깐다면, 걍 functional 쓰지 primitives 로 c++ 을 건드릴 필요가 없지 않겠음?
그렇게 해서 니가 얻은 이익이 bool b = 5 >= 0 && 5 <= 9; 랑 같다는게 한심한 수준.
C++ 연산자 오버로딩을 활용하면 프로그래머가 다른 기능을 더 많이 만들수있잖아 ? 꼭 between만 쓰려고 저걸 만드는게 아니고 생각좀 하고 살자 좀 제발.
생각이 좁아도 아주 좁구나 그런 머리로 잘도 프로그래머하면서 먹고 사네 ㅎㅎ
#define between(var, from, end) 로 선언해 bool b = between(5, 0, 9); 한거에 비해 무슨 득이 있냐? 어순만 바꾸고 괄호나 풀었지.