더 주변 정보가 필요하긴 합니다만, 굳이 왜 이랬는지 생각해보면 set이 필요한 부분이라 bitset으로 구현한 것 아닐까요. 저렇게 표현하는게 흔한 bitset implementation입니다. usb와 speaker, headphone이런게 서로 다른 내용들이라 이것들을 통해 어떤 오브젝트의 성질을 나타내야 하고, 오브젝트가 많이 만들어져서 메모리를 줄여야 하면 쓸 수도 있겠습니다만.. 그게 아니면 premature optimization같네요.
닥터리드
IP 121.♡.141.248
12-14
2021-12-14 14:10:09
·
어떤 경우에는 bit position으로 보는게 쉬우니까 저런식으로 할수도 있을거 같아요
화염법사
IP 211.♡.227.34
12-14
2021-12-14 14:10:48
·
숫자가 커질수록, 가령 16단계를 넘어간다든지 하면 오타를 낼 가능성도 커지고, 그런경우엔 저렇게 하는게 더 보기 쉽다고 생각합니다.
다른 의견에는 안써봐서 모르겠고 라던지 혹은 무응답하시고, 본인 얘기만 계속 하시는건 디스커션의 자세는 아니신듯하네요. 통일된 코딩스타일은 중요합니다. 하지만 각기 개발자마다 의도된 코드구현이 있을테고, 모두가 알아먹기 쉽게 코드를 쓴다기 보다는 그에 대한 주석이나 설명이 더 철저히 달려야 한다고 봅니다.
스타일을 통일한다고 코드가 잘 읽힌다는 명제가 잘못 된 것 아닐까요. 잘 읽히는 것의 기준은 그사람이 아는 범위 안에서 주관적인 것이 되겠죠. 제 생각에는 하드웨어 동작이나 드라이버단 코드까지 곁눈질이라도 하셨으면 왜 저렇게 사용 했는지는 이해가 되지 않으셨을지 싶습니다.
단편적인 부분만 보시고 다른 사람의 코드를 이러쿵저러쿵 하는 것은 그리 보기 좋은 자세 같진 않습니다.
IP 59.♡.42.240
12-14
2021-12-14 16:35:15
·
@sjkoon님 "제 생각엔 글쓴분께서 "누구나"에 끼지 못하셔서 화가 나신거로 이해가 되네요." 라고 쓰신 댓글에 제가 어떤 댓글을 달아야 될까요.
/////////
각 언어마다의 어느정도 코딩스타일이나 표준 같은게 있듯이 (물론 회사마다 다를수 있습니다만, 기본적인 언어에 따른 스타일도 있다고 봅니다) Java 에서는 Java 처럼 짜야되고 이런게 있다고 생각합니다. 객체지향언어에서 C처럼 짜면, 돌아가는거 자체는 문제 없을지는 몰라도, 그게 제대로 된 코드인가에 대해서는 이야기 해볼 수 있겠죠. 또한 스타일 통일은 최소한 회사의 언어 단위에서는 필요하다고 봅니다.
누구는 저렇게 짜고, 누구는 이렇게 짜고, 중괄호 위치부터 시작해서 개개인마다 다 다르게 짜면, 알아보는데 시간이 더 오래 걸리죠.
아니다... 그런가부지
예를들어 비트 마다 상태를 두고 중첩상태를 가능하게 한다든지요
10진수 값으로 바꿔 표시하면 나중에 하나 추가하거나 할때 다시 2진수로 바꿔서 생각해야 되는데 저래 놓으면 +1 해서 쓰면 되거든요.
대신 괄호는 넣어줘야 연산 우선 순위 오류로 부터 안전할텐데...
여기서 추측할수 있는건 C 개발자신듯!?
주로 드라이버 개발이나 칩제어 또는 L2에서 L3수준 레벨의 통신 프로토콜 구현할 때 많이 사용해요
어차피 컴파일과정에서 상수로 대입될테니 성능차이도 없을꺼 같고요.
enum 같은 경우에도 비트연산이 가능하게 만들려고 저런식으로 할당하기도 하잖아요.
올린 분은 잘 모를 수도 있지 않나요
사람마다 저걸 바로 이해할 수도, 좀 나중에 이해할 수도 있다고 생각합니다..
근데 비트연산 마지막으로 해본지가 언젠지 기억도 까마득할 정도로 요즘은 비트연산 할 일이 없네요 ㄷㄷㄷ
오히려 equal 줄 맞춰논게 기특할 정도인데요.
그리고.. 저렇게 비트옵션을 주면 조합옵션기능도 쉽게 만들수 있죠. 예시에선 단순 상수 옵션인거 같긴 한데.. 아무튼 이쁘게 잘 적었다 봅니다.
성능차가 없다는 가정에서 자기 편한데로 하면 되죠..
코딩 스타일 분파가 너무 많아서 전 포기 했습니다.
저걸 상위단에서 보기 좋게 하려면, 중간에 랩핑을 한번 더 해야해서 손이 많이 갈 것 같네요.
오히려 단위가 커질수록 글쓴이님처럼 계산하는건 더 손이 많이 갑니다
원글에 말씀하신 "종종 잘난척하는 코드" 라든지 "난 이렇게까지 복잡하게 쓸 수 있다?" 같은 코드는 아니라는 얘길 다른분들이 하시는거죠.
같은걸 and로 표현하고자 할때 15 보다 1<<3 + 1<<2 + 1<<1 + 1<<0 이 더 직관적이지 않나요?
4비트 말고 16비트,32비트로 가면 갈수록 정수로 쓰는거보다 비트로 쓰는게 더 보기 쉽습니다
소리 출력이요~
출력 디바이스가 1개만 되는지 햐서요...
오 되는군요 감사합니다...
그러면 제 생각으론 비트플래그 모양으로 잡는게 나은것같습니다
통일된 코딩스타일은 중요합니다. 하지만 각기 개발자마다 의도된 코드구현이 있을테고, 모두가 알아먹기 쉽게 코드를 쓴다기 보다는 그에 대한 주석이나 설명이 더 철저히 달려야 한다고 봅니다.
스타일을 통일한다고 코드가 잘 읽힌다는 명제가 잘못 된 것 아닐까요. 잘 읽히는 것의 기준은 그사람이 아는 범위 안에서 주관적인 것이 되겠죠.
제 생각에는 하드웨어 동작이나 드라이버단 코드까지 곁눈질이라도 하셨으면 왜 저렇게 사용 했는지는 이해가 되지 않으셨을지 싶습니다.
단편적인 부분만 보시고 다른 사람의 코드를 이러쿵저러쿵 하는 것은 그리 보기 좋은 자세 같진 않습니다.
/////////
각 언어마다의 어느정도 코딩스타일이나 표준 같은게 있듯이 (물론 회사마다 다를수 있습니다만, 기본적인 언어에 따른 스타일도 있다고 봅니다)
Java 에서는 Java 처럼 짜야되고 이런게 있다고 생각합니다.
객체지향언어에서 C처럼 짜면, 돌아가는거 자체는 문제 없을지는 몰라도, 그게 제대로 된 코드인가에 대해서는 이야기 해볼 수 있겠죠.
또한 스타일 통일은 최소한 회사의 언어 단위에서는 필요하다고 봅니다.
누구는 저렇게 짜고, 누구는 이렇게 짜고, 중괄호 위치부터 시작해서 개개인마다 다 다르게 짜면, 알아보는데 시간이 더 오래 걸리죠.
자바에서 저런 스타일을 썼다면, 특별한 이유가 있을거라고는 생각을 안해보셨는지요. 스타일이 무슨 헌법이 아니고요 필요한 상황에서 혹은 유의해야될 상황에서는 튀어보일 필요도 있습니다.
비트연산을 사용한 이유는 HW Control 상에서 비트연산으로 값을 내리기 때문일테고 결국 획일화를 위해 피치 못하게 사용한 것이라고 저는 이해가 됩니다.
만약 Java에선 Java법 이라고 해서 스타일을 그렇게 엄격하게 따라야한다면,
mismatch로 인한 Hw Control 오류는 Java 재단에서 책임을 져주는지요?
게시판에 이런 스타일은 정말 저급이다 라고 적으시기전에 저 코드 원작자에게 의도를 묻는 것이 의문해결이나 불만 해결에 더 도움이 되실거 같네요.
원작자는 그냥 아랫단 코드 복붙했다는군요.
hidl확인해봐도, 결국은 정수로 변환되서 이용 되더라구요.