일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- relay
- 암호학
- MyVoca
- Gradle
- Compose
- MiTweet
- boj
- 프로그래머스
- 코루틴
- ProGuard
- Coroutines
- Kotlin
- textfield
- Rxjava
- android
- 쿠링
- Hilt
- AWS
- Python
- architecture
- Coroutine
- Codeforces
- NGINX
- GitHub
- 백준
- androidStudio
- pandas
- livedata
- TEST
- 코드포스
- Today
- Total
목록Primary/Kotlin (36)
이동식 저장소
Kotlin에서, variance라는 개념은 타입이 같으면서 타입 매개변수는 서로 다른 타입이 어떻게 연관되어 있는지 설명한다. 예를 들어 ``List``와 ``List`` 등이 해당한다. Variance를 이해하면 타입 안정성을 해치지 않으면서 사용하기 편리한 제네릭 함수를 작성할 수 있다. Variance? 다음과 같은 함수가 있다. fun printContents(list: List) { println(list.joinToString(", ") } ``list``에 ``List``을 전달할 수 있을까? 당연히 있다. ``List``도 전달할 수 있다. 여기까지는 아무른 문제가 없다. 이제 다음의 함수를 보자. 이 함수는 리스트의 맨 뒤에 정수 ``42``를 추가한다. fun addNumber(lis..
제네릭 타입은 JVM에서 실행될 때 지워진다. 런타임에 제네릭 클래스의 타입을 알 수 없다는 말이다. 이번 글에서는 Kotlin 런타임에서 타입이 실제로 어떻게 지워지는지 살펴보고, ``inline`` 함수를 선언하여 타입을 보존할 수 있는 방법을 알아본다. 런타임에서 제네릭의 동작 Java와 마찬가지로 Kotlin의 제네릭은 런타임에 지워진다. 제네릭 클래스가 어떤 타입을 담는지 런타임에 알 수 없다는 뜻이다. 예를 들어 ``List`` 변수를 선언해도 런타임에서는 ``List``로 취급된다. 리스트에 담긴 개별 요소의 타입을 검사할 수는 있지만, 리스트에 ``String``만 있다고 해서 그 리스트가 ``List``이라는 보장은 없다. 물론 일반적으로는 그렇게 추정할 수 있지만, 확신할 수는 없다. ..
상한 (Upper bound) 다음과 같이 ``List``의 확장 함수를 선언했다. fun List.sum() = ... 이때 ``T``는 모든 타입이 될 수 있다. 그러나 ``List.sum``은 수를 저장한 리스트에 대해서만 실행되어야 한다. 그러니까 ``T``의 타입을 제한해야 한다는 말이다. Kotlin에는 모든 수(number) 타입의 부모 클래스 ``Number``가 존재한다.따라서 ``Number`` 또는 그 하위 클래스를 담은 리스트만 sum 함수를 실행할 수 있게 해야 한다. 다음과 같이 선언하면 된다. fun List.sum() = ... 이렇게 하면 ``Number`` 또는 ``Number``의 하위 타입만 ``T``가 될 수 있다. 이처럼 Kotlin에서는 제네릭 타입의 상한(upp..
Boolean AND 연산을 &&로 하는 사람이 대부분이겠지만, 간혹 ``and`` 함수를 사용하는 사람도 있다. 예를 들어 다음 두 코드의 출력값은 같다. println(true and false) println(true && false) 그렇다면 &&와 ``and`` 중 무엇이 올바른 표현인가? &&가 맞다 사실 ``and`` 함수는 Boolean 값을 비교하는 연산자가 아니다. ``and`` 함수는 비트 연산 AND를 구현하는 함수이다. 그래서 ``and`` 함수로 3개 이상의 Boolean 값을 연산할 수 없다. 2개의 Boolean을 연산할 때는 &&와 같은 결과값을 반환하지만, 코드의 의미를 혼란스럽게 할 수 있으므로 웬만하면 &&를 사용하자. 참고: Kotlinlang - Bitwise op..
일반적인 for문과 ``Collections.forEach()`` 중 뭘 써야 하나요? JetBrains의 Kotlin 개발자들이 쓴 Kotlin in Action에 이런 구절이 있다. The forEach function is somewhat more concise than a regular for loop, but it doesn’t have many other advantages, so you needn’t rush to convert all your loops to lambdas. 요약하면 ``forEach``가 읽기 쉬운 건 맞지만, for문을 모두 바꿔야 할 만큼 명확한 이점이 있는 것은 아니라고 한다. 각자 편한 걸 쓰는 걸로.