4409
2014-09-26 14:48:06
1
http://www.wishket.com
4408
2014-09-25 21:20:07
0
http://techreport.com/news/25051/blind-test-suggests-gamers-overwhelmingly-prefer-120hz-refresh-rates
실험결과 120Hz로 플레이한 게이머의 승률이 더높았고, 시렞로 88% 이상의 사람이 60Hz와 120Hz를 직관적으로 구분했다고 합니다.
실험결과 120Hz로 플레이한 게이머의 승률이 더높았고, 시렞로 88% 이상의 사람이 60Hz와 120Hz를 직관적으로 구분했다고 합니다.
4407
2014-09-15 21:49:34
54
고환이 크댔지 음경이 크다고는 안했다
4405
2014-09-11 20:04:37
0
CUDA는 데이터를 그래픽 메모리에 올려 놓고 연산하기 때문에 시스템 메모리와 데이터 전송이 많으면 속도에 영향을 많이 받습니다.
PCIe 버스 속도 한계도 있구요.
최대한 연산할 것들을 한번에 그래픽 메모리에 올려버리고, 시스템 메모리와 통신을 줄여야 합니다.
PCIe 버스 속도 한계도 있구요.
최대한 연산할 것들을 한번에 그래픽 메모리에 올려버리고, 시스템 메모리와 통신을 줄여야 합니다.
4404
2014-09-10 01:32:30
1
애플라이브는 키노트를 실시간 생중계 한다는 거고, 이벤트는 키노트라는 행사 자체를 말해요...
event |ivént|
명사{e(바깥으로)＋vent(나오다)}
1.사건; 행사; 이벤트; 중요한 사건, 대사건; （특히） 핵 사고, (원자로 등의) 돌발 사고 cf. EXCURSION 『명사』 7, MELTDOWN 2
a sporting[social] event
스포츠[사교] 행사
a great historical event
역사적인 대사건
current events
시사(時事)
The party was quite an event.
그 파티는 대단한 행사였다
《속담》 Coming events cast their shadows before them.
일이 일어나기 전에 그 조짐이 있게 마련이다, 일엽지추(一葉知秋).
[유의어] 1. event 중대한 사건을 말하며, 특히 앞서 일어난 일의 결과로 생긴 일. 2. episode 일련의 사건 중의 하나 ◇ an episode of his childhood 그의 소년 시절의 일화. 3. incident 비교적 중요하지 않은 사건으로, 한층 중요한 사건에 관련되어 일어나는 사소한 일 ◇ It was just another incident in her career. 그것은 그녀의 생애에서 또 하나의 작은 사건에 지나지 않았다. 4. occurrence 이전의 사건과 특별한 관련이 없는, 독립적인 그저 평범한 일 ◇ daily occurrences 매일 일어나는 일.
event |ivént|
명사{e(바깥으로)＋vent(나오다)}
1.사건; 행사; 이벤트; 중요한 사건, 대사건; （특히） 핵 사고, (원자로 등의) 돌발 사고 cf. EXCURSION 『명사』 7, MELTDOWN 2
a sporting[social] event
스포츠[사교] 행사
a great historical event
역사적인 대사건
current events
시사(時事)
The party was quite an event.
그 파티는 대단한 행사였다
《속담》 Coming events cast their shadows before them.
일이 일어나기 전에 그 조짐이 있게 마련이다, 일엽지추(一葉知秋).
[유의어] 1. event 중대한 사건을 말하며, 특히 앞서 일어난 일의 결과로 생긴 일. 2. episode 일련의 사건 중의 하나 ◇ an episode of his childhood 그의 소년 시절의 일화. 3. incident 비교적 중요하지 않은 사건으로, 한층 중요한 사건에 관련되어 일어나는 사소한 일 ◇ It was just another incident in her career. 그것은 그녀의 생애에서 또 하나의 작은 사건에 지나지 않았다. 4. occurrence 이전의 사건과 특별한 관련이 없는, 독립적인 그저 평범한 일 ◇ daily occurrences 매일 일어나는 일.
4403
2014-09-09 19:17:42
0
자바에서 별도 파일로 만드셨으면 같은 패키지로 묶거나 따로 임포트를 해 주셔야 합니다
4402
2014-09-05 00:56:10
0
5번의 경우에는 운전해야할 때만 하루단위 원데이 보험 드셔도 됩니다.(가입 즉시 당일 효력발생)
하루 보험료는 오천원도 안되는걸로 알고 있어요~
하루 보험료는 오천원도 안되는걸로 알고 있어요~
4400
2014-09-02 20:40:24
2
아, 그러니까 지역적으로 동적 할당을 할 일이 있으면 자동으로 할당/해제가 되는 스택영역을 사용하는 것이 힙 영역을 쓰는것보다 안전하다는 겁니다.
그리고 불가피하게 동적 할당된 값을 다른 곳으로 전달하여야 한다면 포인터를 그대로 쓰기보다는 래핑 클래스를 사용해서 클래스 소멸자에서 자동으로 해제되게 해야 메모리 누수를 사전에 막을 수 있습니다.
또한 같은 함수 내라도 분기 후의 처리가 다르다면 결국 해당 분기부터 서로 다른 문맥이 된것이므로, 후처리가 비슷하다고 하여 함께 처리하는 것이 아니라 문제가 발생한 문맥 내에서 처리 되는게 바람직합니다.
코드 인접성이 높다고 문맥 일관성을 포기하면 다수의 사람들이 같은 코드를 봐야할 경우 가독성을 매우 떨어트리게 됩니다.
또한 핸들러나 함수포인터 같이 포인터 값의 일관성이 유지되야하는 정말 크리티컬한 경우가 아니면 대부분의 데이터는 포인터 없이 값에 의해서만 전달 및 반환이 가능합니다.
아무튼 요지는 가능하면 스택 영역 내에서만 메모리를 사용하는 것이 좋고, 힙 영역을 동적 할당해야할 경우에는 래핑을 통해서 자체적으로 해제가 가능하도록 만들어야 한다는 겁니다.
그리고 불가피하게 동적 할당된 값을 다른 곳으로 전달하여야 한다면 포인터를 그대로 쓰기보다는 래핑 클래스를 사용해서 클래스 소멸자에서 자동으로 해제되게 해야 메모리 누수를 사전에 막을 수 있습니다.
또한 같은 함수 내라도 분기 후의 처리가 다르다면 결국 해당 분기부터 서로 다른 문맥이 된것이므로, 후처리가 비슷하다고 하여 함께 처리하는 것이 아니라 문제가 발생한 문맥 내에서 처리 되는게 바람직합니다.
코드 인접성이 높다고 문맥 일관성을 포기하면 다수의 사람들이 같은 코드를 봐야할 경우 가독성을 매우 떨어트리게 됩니다.
또한 핸들러나 함수포인터 같이 포인터 값의 일관성이 유지되야하는 정말 크리티컬한 경우가 아니면 대부분의 데이터는 포인터 없이 값에 의해서만 전달 및 반환이 가능합니다.
아무튼 요지는 가능하면 스택 영역 내에서만 메모리를 사용하는 것이 좋고, 힙 영역을 동적 할당해야할 경우에는 래핑을 통해서 자체적으로 해제가 가능하도록 만들어야 한다는 겁니다.
4399
2014-09-02 18:45:53
0
#include <stdio.h>
int main(int argc, char* argv[])
{
int a = 10;
printf("%dn", a);
{
int b = a + 1; // 혹은 사용자 입력 사용
printf("%dn", b);
{
int c[b]; // 블럭을 시작하는 시점에서 새로운 크기의 배열을 할당 가능
int i = 0;
for (i = 0; i < b; i++)
{
c[b] = i * i;
}
for (i = 0; i < b; i++)
{
printf("%dn", c[i]);
}
}
}
}
int main(int argc, char* argv[])
{
int a = 10;
printf("%dn", a);
{
int b = a + 1; // 혹은 사용자 입력 사용
printf("%dn", b);
{
int c[b]; // 블럭을 시작하는 시점에서 새로운 크기의 배열을 할당 가능
int i = 0;
for (i = 0; i < b; i++)
{
c[b] = i * i;
}
for (i = 0; i < b; i++)
{
printf("%dn", c[i]);
}
}
}
}
4398
2014-09-02 14:12:02
1
함수의 맨 마지막에서 결과값을 기반으로 return을 해야한다는 건 파스칼이나 베이직에서 리턴은 무조건 함수 끝에서 되는 것을 기반으로 한것이구요, 에러가 발생한 시점에서 바로 return을 해버리는게 문맥적으로도 더 자연스럽고 goto를 사용하지 않을 수 있습니다.
새로이 코드리뷰를 하는 입장에서 특정 문맥을 따라가다가 갑자기 점프를 해버리면 해당 라벨까지 가서 처리를 확인한 후 되돌아와야 하지만, 에러시점에서 에러를 바로 리턴해 버리면 자연스럽게 문맥 전체를 이해할 수 있습니다.
에러 처리를 몰아서 하려고, 혹은 코드 재사용성을 높이기 위해 문맥 가독성을 떨어트리는 거죠.
그리고 지역적으로 변수를 동적 할당하여 사용하는 경우에는 함수내에서 새 익명 블럭을 시작하면서 변수/배열을 선언하는게 좋습니다.
해당 블럭이 끝나면 자연스럽게 해제되어 메모리 누수를 걱정할 필요가 줄어듭니다.
새로이 코드리뷰를 하는 입장에서 특정 문맥을 따라가다가 갑자기 점프를 해버리면 해당 라벨까지 가서 처리를 확인한 후 되돌아와야 하지만, 에러시점에서 에러를 바로 리턴해 버리면 자연스럽게 문맥 전체를 이해할 수 있습니다.
에러 처리를 몰아서 하려고, 혹은 코드 재사용성을 높이기 위해 문맥 가독성을 떨어트리는 거죠.
그리고 지역적으로 변수를 동적 할당하여 사용하는 경우에는 함수내에서 새 익명 블럭을 시작하면서 변수/배열을 선언하는게 좋습니다.
해당 블럭이 끝나면 자연스럽게 해제되어 메모리 누수를 걱정할 필요가 줄어듭니다.
4397
2014-09-01 23:58:34
2
애초에 C++은 멀티패러다임 언어라 심도 있게 배우고, 잘 사용하기가 상당히 어려운 언어입니다.
C++14 버전에서는 제네릭 람다까지 지원하며 함수형 언어에 대해서도 거의 대부분의 패러다임을 지원하게 되었습니다.
(즉, C++OL도 곧 개정판이 곧 다시 나온단 소리...)
리누스 토발즈가 리눅스 커널 코어 개발에 있어서 C++을 배제하고 C만 고집하는 것도 C++과 같이 숙련이 어려운 언어로는 수십만명의 익명의 사용자들이 참여하는 오픈소스에서 코드 퀄리티를 유지 하기 어렵고, 그만큼 유지보수가 더 힘들어진다는 이유가 한 몫했습니다.
많은 패러다임을 흡수한 고급언어이기 때문에 오히려 유지보수성이 떨어진다는 게 아이러니죠.
또한 최근 C++창시자의 인터뷰에서 또한 C++은 장기간의 학습을 걸쳐 숙련된 사용자가 고성능을 필요로 하면서도 다양한 프로그래밍 패러다임을 적용할 필요가 있는 분야에서 활용하는 것을 목표로 하고 있다고 했습니다.
이쯤 되면 C와 C++은 라이브러리 인터페이스와 몇몇 문법만 공유하는 전혀 다른 언어라고 보아도 무방할 수준이 되었습니다.
사실 nanoscond~picosecond 이내에 응답을 보내야 하는 디바이스 드라이버에 대해서는 어차피 어셈블리로 코딩을 해야하는 부분이 생기니 극도의 퍼포먼스가 필요한 분야에서는 어셈블과 섞어쓸 수 있다는게 유일한 장점이고, 생산성 부분에서는 앞서 말했다시키 학습커브가 너무 커서 신규 사용자가 숙련되기 힘들고, 비숙련자가 작성한 코드의 퀄리티가 좋지 못한 점이 문제가 되죠.
사실 요즘은 어플리케이션 서버도 파이썬이나 루비같은 스크립트 언어로 작성하는 경우가 늘어 났고, 이런 언어들의 빠른 생산성을 기반으로 서비스를 빠르게 런칭 한 뒤(즉 적은 인건비로 런칭), 서비스가 성공하여 사용자 처리를 위해 극한의 튜닝이 필요할 경우에나 C++같은 언어를 사용해서 재작성하는 경우가 늘어났기 때문에 C++은 입지가 더 좁아지고 있습니다.
현재 C++의 신규사용처는 대부분 게임 엔진/서버 쪽인데, 게임 서버 또한 coroutine이나 yield등의 문맥양보를 통한 이벤트드리븐 코딩이 가능한 언어로 이동하고 있는 것으로 알고 있습니다.(국내 온라인 게임 개발사들은 C#을 많이 사용한다고 합니다.)
게임 엔진 또한 코어는 C++로 제작되지만 최근에는 대부분 스크립트만으로 게임을 작성할 수 있게 나오는 경우가 많아서, 마찬가지로 극한의 튜닝을 필요한 경우가 아니면 C++을 사용할 일이 적습니다.
결과적으로 C++의 점유율은 아직 높지만, 최근 5년간 추세를 보면 꾸준히 감소하고 있습니다.
사실 개인적으로도 좀더 배우기 쉽고 생산성이 높은 다른 언어들을 통해 다양한 프로그래밍 패러다임을 익히고 코딩 스킬을 충분히 단련한 다음에 C++에 진입하는 것이 좋다고 생각합니다.
마찬가지로 C 또한 운영체제를 만들기 위해 설계된 언어인 만큼 컴퓨터 구조와 시스템프로그래밍에 대한 이해를 어느정도 깔고 있어야만 C언어 자체에 대한 이해를 할 수 있기 때문에 초보자가 배우기에 적합한 언어는 아니라고 생각합니다.
사실 최근엔 어셈블리도 함수와 간단한 반복연산, 분기문 정도는 매크로를 통해 사전 정의되어 있어서 이제와선 몇몇 기능을 제외하면 C와 어셈블의 차이도 많이 좁혀져 버리기도 했구요.
아무튼 대신에 레퍼런스형 변수를 사용하라는 것은 결국 모든 메모리 할당을 Call Stack 내부에서만 사용하고, 해당 블럭이 끝나면 유의미한 데이터만 반환하고 나머지 정보들은 블럭과 함께 자연스럽게 해제되도록 짜야합니다.
Object *objPrt = new Object(); ... ; 보다는 { Object obj(); ...; return obj} 형태로 사용하는 것이 굳이 delete를 신경 쓰는 것보다 훨씬 더 개발이 편하고, 할당과 해제가 같은 블럭에서 되므로 훨씬더 문맥이 자연스러워 집니다.
C언어도 마찬가지로 블럭의 시작 위치가 자유로우므로, 변수가 필요한 시점에서 새로운 블럭을 열고 사용이 끝난 시점에서 블럭을 닫는 편이 포인터를 쓰지 않고도 메모리 할당을 자유롭게 할 수 있습니다.
#include <stdio.h>
int main(int argc, char* argv[])
{
int a = 10;
printf("%dn", a);
{
int b = a + 1;
printf("%dn", b);
{
int c[b];
int i = 0;
for (i = 0; i < b; i++)
{
c[b] = i * i;
}
for (i = 0; i < b; i++)
{
printf("%dn", c[i]);
}
}
}
}
C++14 버전에서는 제네릭 람다까지 지원하며 함수형 언어에 대해서도 거의 대부분의 패러다임을 지원하게 되었습니다.
(즉, C++OL도 곧 개정판이 곧 다시 나온단 소리...)
리누스 토발즈가 리눅스 커널 코어 개발에 있어서 C++을 배제하고 C만 고집하는 것도 C++과 같이 숙련이 어려운 언어로는 수십만명의 익명의 사용자들이 참여하는 오픈소스에서 코드 퀄리티를 유지 하기 어렵고, 그만큼 유지보수가 더 힘들어진다는 이유가 한 몫했습니다.
많은 패러다임을 흡수한 고급언어이기 때문에 오히려 유지보수성이 떨어진다는 게 아이러니죠.
또한 최근 C++창시자의 인터뷰에서 또한 C++은 장기간의 학습을 걸쳐 숙련된 사용자가 고성능을 필요로 하면서도 다양한 프로그래밍 패러다임을 적용할 필요가 있는 분야에서 활용하는 것을 목표로 하고 있다고 했습니다.
이쯤 되면 C와 C++은 라이브러리 인터페이스와 몇몇 문법만 공유하는 전혀 다른 언어라고 보아도 무방할 수준이 되었습니다.
사실 nanoscond~picosecond 이내에 응답을 보내야 하는 디바이스 드라이버에 대해서는 어차피 어셈블리로 코딩을 해야하는 부분이 생기니 극도의 퍼포먼스가 필요한 분야에서는 어셈블과 섞어쓸 수 있다는게 유일한 장점이고, 생산성 부분에서는 앞서 말했다시키 학습커브가 너무 커서 신규 사용자가 숙련되기 힘들고, 비숙련자가 작성한 코드의 퀄리티가 좋지 못한 점이 문제가 되죠.
사실 요즘은 어플리케이션 서버도 파이썬이나 루비같은 스크립트 언어로 작성하는 경우가 늘어 났고, 이런 언어들의 빠른 생산성을 기반으로 서비스를 빠르게 런칭 한 뒤(즉 적은 인건비로 런칭), 서비스가 성공하여 사용자 처리를 위해 극한의 튜닝이 필요할 경우에나 C++같은 언어를 사용해서 재작성하는 경우가 늘어났기 때문에 C++은 입지가 더 좁아지고 있습니다.
현재 C++의 신규사용처는 대부분 게임 엔진/서버 쪽인데, 게임 서버 또한 coroutine이나 yield등의 문맥양보를 통한 이벤트드리븐 코딩이 가능한 언어로 이동하고 있는 것으로 알고 있습니다.(국내 온라인 게임 개발사들은 C#을 많이 사용한다고 합니다.)
게임 엔진 또한 코어는 C++로 제작되지만 최근에는 대부분 스크립트만으로 게임을 작성할 수 있게 나오는 경우가 많아서, 마찬가지로 극한의 튜닝을 필요한 경우가 아니면 C++을 사용할 일이 적습니다.
결과적으로 C++의 점유율은 아직 높지만, 최근 5년간 추세를 보면 꾸준히 감소하고 있습니다.
사실 개인적으로도 좀더 배우기 쉽고 생산성이 높은 다른 언어들을 통해 다양한 프로그래밍 패러다임을 익히고 코딩 스킬을 충분히 단련한 다음에 C++에 진입하는 것이 좋다고 생각합니다.
마찬가지로 C 또한 운영체제를 만들기 위해 설계된 언어인 만큼 컴퓨터 구조와 시스템프로그래밍에 대한 이해를 어느정도 깔고 있어야만 C언어 자체에 대한 이해를 할 수 있기 때문에 초보자가 배우기에 적합한 언어는 아니라고 생각합니다.
사실 최근엔 어셈블리도 함수와 간단한 반복연산, 분기문 정도는 매크로를 통해 사전 정의되어 있어서 이제와선 몇몇 기능을 제외하면 C와 어셈블의 차이도 많이 좁혀져 버리기도 했구요.
아무튼 대신에 레퍼런스형 변수를 사용하라는 것은 결국 모든 메모리 할당을 Call Stack 내부에서만 사용하고, 해당 블럭이 끝나면 유의미한 데이터만 반환하고 나머지 정보들은 블럭과 함께 자연스럽게 해제되도록 짜야합니다.
Object *objPrt = new Object(); ... ; 보다는 { Object obj(); ...; return obj} 형태로 사용하는 것이 굳이 delete를 신경 쓰는 것보다 훨씬 더 개발이 편하고, 할당과 해제가 같은 블럭에서 되므로 훨씬더 문맥이 자연스러워 집니다.
C언어도 마찬가지로 블럭의 시작 위치가 자유로우므로, 변수가 필요한 시점에서 새로운 블럭을 열고 사용이 끝난 시점에서 블럭을 닫는 편이 포인터를 쓰지 않고도 메모리 할당을 자유롭게 할 수 있습니다.
#include <stdio.h>
int main(int argc, char* argv[])
{
int a = 10;
printf("%dn", a);
{
int b = a + 1;
printf("%dn", b);
{
int c[b];
int i = 0;
for (i = 0; i < b; i++)
{
c[b] = i * i;
}
for (i = 0; i < b; i++)
{
printf("%dn", c[i]);
}
}
}
}
4396
2014-09-01 17:11:07
1
한컴 뷰어(무료) + iWork(폰사면 무료로 줌) 정도면 왠만한 문서들은 전부다 다운받아서 바로 열어 볼 수 있지 않나요..?
간단한 워드나 PPT작업은 이걸로 했던 기억이 있는데요..
충전기는 전 충전 케이블만 따로 하나더 들고 다니면서 USB 충전포트 있는데서 꼽아 쓴느데...이거야 케이블 들고다니는게 저만 안불편할수도 있는거니 흠..
아무튼 저는 문서작업이나 급한 업무처리, 게임용도로 아이패드 잘 쓰고 있고 간단한 문서도 아이폰으로 다운받아서 바로 열어 보고 있습니다..
간단한 워드나 PPT작업은 이걸로 했던 기억이 있는데요..
충전기는 전 충전 케이블만 따로 하나더 들고 다니면서 USB 충전포트 있는데서 꼽아 쓴느데...이거야 케이블 들고다니는게 저만 안불편할수도 있는거니 흠..
아무튼 저는 문서작업이나 급한 업무처리, 게임용도로 아이패드 잘 쓰고 있고 간단한 문서도 아이폰으로 다운받아서 바로 열어 보고 있습니다..
4395
2014-08-28 00:56:48
1
시작하실 때는 요구사항 확인하고, 본인의 업무범위 확정 하신 다음에 업무범위를 계약서에 명시해서 작성하시면 됩니다.
계약서는 공정거래위원회에서 배포하는 "소프트웨어사업 표준하도급계약서" 를 참조 하시되, 소프트웨어 관련 표준 계약서가 네종류있으니 하려는 업무에 적절한 것을 사용하시면 됩니다.(http://www.ftc.go.kr/info/bizinfo/stdSubContractList.jsp)
계약서 작성하실 때 가능하면 표준 하도급계약서 쓰시고, 회사에서 계약서를 작성해 준다면 표준 하도급 계약서랑 비교해서 계약 조건을 조정 하시면 됩니다.(결과물에 대한 저작권 귀속 여부, 납기일 초과시 배상금 등)
계약서 작성 이후 진행이나 선금, 중도금, 마무리 방법 등은 대부분 계약서 조항들을 읽어보면 명시되어 있습니다.
업무 완료 후에는 계약서 작성시 명시했던 업무 범위에 대해 검수 확인했다는 내용증명(리스트로 작성해도 되고, 그냥 검수되었음이라고 한줄만 적혀도 되는데 회사측 법인 인장이 찍혀야 합니다) 받고 계약서에 명시된 기간내에 잔금 받으시면 됩니다.
하지만 업무범위나 업무기간은 대부분 계약서 업무범위대로만 되는 일이 적으니 진행하면서 유도리 있게 하셔야 할겁니다.
계약서는 공정거래위원회에서 배포하는 "소프트웨어사업 표준하도급계약서" 를 참조 하시되, 소프트웨어 관련 표준 계약서가 네종류있으니 하려는 업무에 적절한 것을 사용하시면 됩니다.(http://www.ftc.go.kr/info/bizinfo/stdSubContractList.jsp)
계약서 작성하실 때 가능하면 표준 하도급계약서 쓰시고, 회사에서 계약서를 작성해 준다면 표준 하도급 계약서랑 비교해서 계약 조건을 조정 하시면 됩니다.(결과물에 대한 저작권 귀속 여부, 납기일 초과시 배상금 등)
계약서 작성 이후 진행이나 선금, 중도금, 마무리 방법 등은 대부분 계약서 조항들을 읽어보면 명시되어 있습니다.
업무 완료 후에는 계약서 작성시 명시했던 업무 범위에 대해 검수 확인했다는 내용증명(리스트로 작성해도 되고, 그냥 검수되었음이라고 한줄만 적혀도 되는데 회사측 법인 인장이 찍혀야 합니다) 받고 계약서에 명시된 기간내에 잔금 받으시면 됩니다.
하지만 업무범위나 업무기간은 대부분 계약서 업무범위대로만 되는 일이 적으니 진행하면서 유도리 있게 하셔야 할겁니다.