왜 node.js 의 querystring.escape() 는 javascript 의 escape()와 다르게 동작하는거야? 

https://github.com/sintaxi/node-dbox/issues/9

querystring.escape()는 !'()* 를 인코딩 안해요~

그러니 필요하면 고쳐 쓰세요.

자바스크립트의 escape() 함수가 인코딩하는 방식

http://realmind.tistory.com/191


블로그 이미지

Yardbirds

개발하면서 끄적 끄적~

댓글을 달아 주세요

필자가 rvalue reference 라는 말을 처음 들었을 때, "이게 뭐지?" 라는 생각 밖에 들지 않았다. 설명하는 글을 읽어도 용어에 대한 의미가 명확히 오지 않아 이해가 어려웠다. 그러다가 rvalue 의 의미에 대해서 설명한 글을 봤다. 역시 필자가 이해했던 rvalue 의 의미는 구식이었다. 아니면 알았는데 잊었을 수도 있다.

rvalue 의 의미를 알고 나니 rvalue reference 를 이해하기가 수월했다. 회사에서 rvalue reference 에 대해 발표한 적이 있는데, 이미 rvalue reference 에 대해 알고 있던 동료도 rvalue 에 대해 설명을 들으니 도움이 많이 됐다는 얘기를 했다.

대부분 rvalue 에 대해 정확한 의미를 알고 있겠지만, 필자와 같이 어설픈 지식을 갖고 있는 사람들을 위해서 rvalue 가 어떤 의미를 갖고 있는지, 특징이 무엇인지를 살펴보려고 한다.

C++98/03 에서의 lvalue 와 rvalue


원래 C 에서부터 사용된 이 용어는 표현식에서 왼쪽에 있는 값과 오른쪽에 있는 값을 가리켰다. 하지만 C++ 로 넘어오면서 원래의 의미는 많이 사라졌다. 이제 위치를 가리키는 의미는 정확하지 않다. L 과 R 이 아무 의미 없는 말이라고 생각하는 것이 좋다.

lvalue 는 해당 표현식이 넘어가더라도 값을 유지하는 객체를 가리킨다. 예를 들어 다음과 같은 것들은 모든 lvalue 이다.

obj, *ptr, ptr[index], ++x


rvalue 는 전체 표현식의 끝에서 사라지는 임시값을 가리킨다.

1729, x + y, std::string("meow"), x++


어떤 값이 lvalue 인지 rvalue 인지 직관적으로 알아내는 방법이 있다. "그 값의 주소를 얻을 수 있는가" 를 확인해 보면 구분할 수 있다. lvalue 는 주소값을 얻을 수 있는 반면, rvalue 는 그럴 수 없다. 예를 들어 다음과 같은 표현식은 옳다.

&obj, &*ptr, &ptr[index], &++x


하지만 다음과 같은 표현식은 옳지 않다.

&1729, &x + y, &std::string("meow"), &x++


왜 그럴까? 주소값을 얻어오는 '&' 연산자의 피연산자는 lvalue 만 가능하도록 C++03 5.3.1/2 에서 정의 했기 때문이다. 만약 휘발성이 있는 rvalue 에서 얻어지는 주소값을 사용한다면 매우 위험할 것이다.

함수 호출

함수 호출을 lvalue 와 rvalue 로 구분할 수 있다. 함수 호출도 앞에서 설명한 lvalue 와 rvalue 의 규칙을 따른다. 여기에서 유념해야 할 점은 함수의 리턴값을 보고 lvalue 인지 rvalue 인지 구분한다는 것이다. "함수" 라고 하지 않고 "함수 호출" 이라고 말한 이유가 여기에 있다.

리턴 값이 유지될 수 있는 값이라면 함수 호출이 lvalue 가 된다. 반대로 리턴 값이 임시 값이라면 함수 호출이 rvalue 가 된다. 이것을 간단히 정리하면 다음과 같다

함수가 참조값을 리턴할 경우 함수 호출은 lvalue 가 된다.
반대로 그냥 값을 리턴하면 함수 호출은 rvalue 가 된다.

vector<int> v(10, 1729);

// operator[]() 가 int& 를 리턴하므로 lvalue 이다.
// &v[0] 라는 표현식도 옳다
v[0];

string s("foo");
string t("bar");

// operator+() 가 string 을 리턴하므로 rvalue 이다.
// &(s + t) 라는 표현식은 옳지 않다
s + t;

바인딩

lvalue 와 마찬가지로 rvalue 에도 상수성이 존재한다. 즉, const rvalue 도 있다는 얘기다. 그리고 이에 따른 바인딩 규칙이 존재한다. 아래 코드를 보면 각 타입이 어떻게 바인딩이 되는지 알 수 있다.

string one("cute");
const string two("fluffy");
string three() { return "kittens"; }
const string four() { return "four"; } 

one;     // modifiable lvalue
two;     // const lvalue
three(); // modifiable rvalue
four();  // const rvalue

void foo(string& str) {}
void bar(const string& str) {}

foo(one);
//foo(two); // 에러발생
foo(three()); // 원래 C++은 이것을 허용하지 않지만 VC 는 이것을 허용한다.
//foo(four()); // 에러발생

bar(one);
bar(two);
bar(three());
bar(four());
Type&(lvalue reference)은 modifiable lvalue 에만 바인딩된다. const lvalue, modifiable rvalue, const rvalue 에는 바인딩 되지 않는다. const 타입의 경우 'const correctness' 규칙에 위반되기 때문이다. 그리고 modifiable rvalue 일 경우에는 임시변수를 참조함으로써 미묘한 버그를 발생시킬 수 있기 때문이다. (하지만 VC 는 modifiable rvalue 로의 바인딩도 허용한다. 하지만 경고 레벨을 4로 지정해서 경고를 발생시키게 할 수도 있다.)

반면 const Type& 은 모든 경우에 바인딩이 된다.

다시 한 번

rvalue는 표현식의 끝에서 사라지는 값이라고 했다. 즉, 표현식 이후에는 그 값을 아무도 참조할 수 없다는 얘기다. 그렇다면 그 표현식 내에서 내맘대로 값을 바꿔도 그리 문제되지 않을 것이다. 이 속성은 다음에 얘기할 rvalue reference로 move semantics가 가능하게 하는 rvalue의 중요한 특성이다.

  발표자료
블로그 이미지

Yardbirds

개발하면서 끄적 끄적~

댓글을 달아 주세요

북팟이라는 책 스캔 업체가 있다. 얼마 전 이 업체에 기술 서적 몇 권을 맡겼다. 품질에 만족을 못했기 때문에 몇 번의 문의가 오가긴 했지만 빠르고 친절한 대응이 만족스러웠다.

문의가 오가는 중에 북팟에서 옵션별 샘플을 보내줬다. 업체마다 장비나 소프트웨어에 차이가 있어 약간씩 다를 것 같긴 하지만 스캔을 하기 전에 선택할 수 있는 옵션을 미리 안다면 도움이 될 것이다. 북팟 사이트에 이런 옵션에 대한 사항을 설명하지 못한 것은 아쉬운 부분이다. 뿐만 아니라 여기에서 설명하려는 옵션은 구매할 때 선택할 수 없고 따로 문의해야 한다.

스캔을 요청할 때 OCR (Optical Character Recognition) 옵션을 추가할 수 있다. 이미지를 문자화 해서 검색할 수 있도록 해 주는 서비스다. 물론 추가 비용이 들긴 하지만 기술 서적을 스캔할 땐 필요한 부분이다.

OCR 옵션을 선택하면 세 가지 보정타입(?) 옵션이 있는데 사이트에서는 이 옵션을 선택할 수 없다. 따로 문의하지 않으면 클리어 타입으로 보정한다. 그 외에 압축과 비압축 옵션이 있다. 필자는 클리어 타입 옵션이 마음에 들지 않아 비압축으로 재스캔을 요청했다.

아래 이미지는 OCR 옵션을 사용하지 않은 파일의 일부분이다. 개인마다 차이는 있겠지만 아이패드에서 읽는데는 큰 불편이 없었다.



아래 이미지는 OCR-비압축 옵션을 사용한 파일의 일부분이다. 둔한 필자의 눈으로는 OCR 을 사용하지 않은 파일과 별다른게 없어 보인다. OCR 옵션을 사용하면 PDF 리더에서 글자를 선택할 수 있다.


아래의 이미지는 OCR-압축 옵션을 사용한 파일의 일부분이다. 앞의 두 파일과 큰 차이가 없다. 압축이라고 해서 파일의 크기가 많이 줄지는 않는다.


아래의 두 이미지는 OCR-클리어 옵션을 사용한 파일의 일부분이다. 이탤릭체의 경우 글자가 많이 끊어지고 심지어는 글자가 사라지기도 한다. (두 번째 이미지의 네 번째 줄에서 '하  않을'은 원래 '하지 않을' 이었다)



아래는 위에서 두 번째 이미지와 같은 부분의 OCR-압축 옵션 파일의 이미지이다.


블로그 이미지

Yardbirds

개발하면서 끄적 끄적~

댓글을 달아 주세요