template <typename _M> class var { typedef _M Object; ... }; typedef var<map<std::string, var::Object>> var1; typedef var<unordered_map<std::string, var::Object>> var2; |
이거 컴파일 됩니까? 아니면 제가 삼촌님 답변을 제대로 이해를 못했나요?
컴파일 가능한 형태를 한번 보여주시죠?
template <typename _C, typename _T = _C::value_type>>
도대체 _C::value_type은 어떻게 추정을 하나요?
이상한 풀소스 링크 올리지말고요.
샘플 코드 한번 줘보세요.
뭐 좋습니다. 한번 테스트 해보도록 하죠.
아 이거 완전 노답이네요. 이경우는 템플릿 재귀가 자기 자신인 경우잖아요. 이건 이미 알고 있는 방법이라구요.
제발 좀 부탁합니다. 2가지 타입의 자료형이 서로 재귀 되야 합니다. 문제를 좀 제대로 봐주세요.
저랑 지금 장난하자는 겁니까?
이전 글 보고 오세요.
"C++ 템플릿 잘아는 사람 도와줘잉~" 솔직히 이글 보셨잖아요? 안보셨다고 하실건가요?
안보셨다고 하면 제 잘못이네요. 진즉에 보고 오시라고 할것을 허허허;
자기자신의 재귀라면 이런 글 올렸겠나요? 생각을 좀 해보세요.
유추 가능하다고 생각됩니다만?
그정도도 유추를 못하면 좀 그렇네요.
적어도 이런 문제에 대해 생각해 본적이 있는사람이라면
그리고 템플릿 잘 아는 사람 도와달라고 제목에 써놨잖아요?
이제야 아셨군요. 네 그렇게 무한 뎁스여야 합니다.
불가능하다는거 이미 안다니까요? 뻔한 말은 삼가해주세요.
최소의 노력으로 트릭을 구현한 분이 혹시 있는지 찾는거 뿐입니다.
그런거 아닙니다.
추상 클래스 아니라니까요. 맘대로 확정짓지 말아주세요?네?
엔티티는 맞고요. 이제는 또 엉뚱한곳에서 딴지시네요?
넵
경험이 많으실거 같은데도 의외로 추론이 늦으시는거 같네요?
네 맞습니다. 맵계열에는 Object형태만 들어갑니다.
속도 때문의 그럽니다. 이미 아실거 같은데요.
map(입력순서무시,정렬), unordered_map(비정렬), LinkedHashMap(입력순서유지,정렬)
데이터는 다르지 않습니다. 오직 속도때문에 그럽니다.
정렬및 입력순서 유지가 필요없는곳에서는 속도 위주로 쓰려고요
넵
vector랑은 아무 상관도 없습니다.
vector얘기는 갑자기 또 왜 나오시는지요?
맵 계열에도 적용한가요?
Obeject(맵계열), Array(Vector) 이미 분리해서 쓴다고 이전 글에서 이미 얘기했습니다. 이미 댓글 단 글이구요.
키값이 정수로만 이우러진 자료는 Array에만 담구요. 문자열키가 포함되 있으면 Object에 담습니다.
이미 댓글까지 다신 글이구요.
저 지금 벽에 대고 얘기하는 기분입니다.
혼합된 경우는 당연히 Object에 넣겠죠? 당연한 말씀좀 삼가해주세요.
var에는 object와 array가 동시에 쓰이구 있다고요.. 제발좀...벽에 대고 이야기하는 기분좀 안들게 해주세요.
또다시 원점으로 돌아가실 겁니까?
그러니까 allocator를 쓰면 map이 입력순서를 유지할수있다고요?
아무 구현도 없이 그냥 바로?
json 스펙은 유지될필요가 없지만 실상은 그렇지 않습니다. 그기능이 필요하니까 넣은겁니다.
자꾸원점으로 돌아가려고 하지마세요.
파일에서 json읽어왔다가 다시 저장해 보니 엉뚱한 순서 저장되있으면 참 보기가 좋겠네요.
적어도 3가지 타임을 경우에 따라 사용가능해야 합니다. 코드가 복잡해 지지 않으면서도요. 구현이 목적이 아니고 귀차니즘 해결이 목적이라 했습니다.
순서는 상관없다는건 본인 생각이시고요. 자꾸 본인위주로만 생각하지 마세요. 필요한 경우가 반드시 있습니다.
json구조 자체를 복잡하게 끌고 가지 않으면서도 문자열키 정렬이 필요한 경우 때문에 만들었습니다. 저장할때 꼬이는 문제도 있구요.
저장할때 꼬이는건 어떻게 해결하라는겁니까?
제발 1차원적으로만 생각하지마세요
설계잘못이래 나참
본인이 구현한 라이브러리 위주로만 생각하시네요. 제발 좀 그러지좀 마세요.
key입력 순서 보존 하지 않으면 꼬이죠. 왜꼬이다뇨?
알파벳순으로 정렬하는것도 꼬이는것중에 하나입니다.
원본을 그대로 유지해야죠
범용으로 쓰려고 만든거지 설계용으로 만든거 아닙니다
저장해보세요. 스트링 키값으로만 구성된 자료를. 완전 꼬이게 저장되지. 순서유지가 안됩니다
해보고 말씀하세요
만약에 json파일을 설정 파일 용도로 쓴다고 가정해봅시다. 자기가 알아보기 쉽게 키값을 배치해놨는데. 프로그램에서 읽었다가 다시 저장했더니 꼬여 있다면? 개빡치겠죠?
범용이 설계관점의 범용만을 위한것은 아닙니다만?
xml도 마찬가지입니다. 자식노드의 순서를 무시하고 저장하면 퍽이나 좋아하겠네요? 그게 혹시 자동으로 되니까 생각안하시나요?
또다시 원점으로 돌아가지 마세요
allocator써서 해결될 문제가 아닙니다.
그거쓰면 세부 구현이 또 복잡해집니다.
map구현이 복잡해진다는 의미가 아닙니다.