Yeah, it was sometime in the 90s. The only workaround I could think of was maybe to create a single compilation unit for template use, and there derive a trivial subclass of each used template specialization, then use that subclass elsewhere in lieu of the template. Needless to say, not a solution that scales nicely to any substantial team effort, because of the coordination problem involved in discovering when two team members are specializing the same template the same way (hopefully, earlier than when linkage errors break the build!), then adding it to the central file of template specialization subclasses, then communicating to *everyone* to use this new class instead of a particular template with particular parameters ... and once everyone's including the same unit (with these subclasses) there'd be a giant temptation to start shoving everything else widely referenced into there as well, including the kitchen sink, until it turned into a "god object" with all of the headaches *that* entails. And sooner or later the thing would grow unwieldy, leading to duplications bloating generated code size; or we'd have one single unit using some template directly at the end, also causing duplication. And if all went *well* the end result would contain not tidy vector<int>s and similarly regular and understandable C++, but vec_of_int and other nonstandard class names instead, leading to head-scratching among the maintenance programmers. Doubly so if the names ended up being less than fully self-explanatory, such as if hash_map<const char *,int,my_case_insensitive_hash,stricmp> was used to derive a trivial extension that got named person_salary because of its use in employee_directory.cpp and payroll.cpp ... and then wound up used also in orderform.cpp for SKU-quantity mapping, and in storelocator.cpp for store location-number of widgets in stock, and etc., later on down the line when other string to integer mappings started being needed.
On Sun, Dec 29, 2013 at 6:04 PM, Sean Corfield <seancorfi...@gmail.com>wrote: > That must have been a long time ago? That problem was solved well > before I left the C++ committee in '99 and gcc was normally pretty > good at tracking the emerging standard at the time... > > But, yes, the template compilation model and it's impact on linking > modules that specialized the same template had been problematic > earlier on. > > On Sun, Dec 29, 2013 at 2:30 PM, Cedric Greevey <cgree...@gmail.com> > wrote: > > (Incidentally, it was template woes that eventually broke the camel's > back > > for me with C++. I gave up on C++ when I found that one of the most > > widely-used free software C++ compilers would give duplicate definition > > errors at link time if the same template was used with the same > parameters > > in two separate compilation units, and the developers had *no sane fix or > > workaround* or even an ETA on a fix...imagine if importing java.util.Map > and > > using Map<String,Integer> in Foo.java and also importing java.util.Map > and > > using Map<String,Integer> in Bar.java and then running something using > both > > classes Foo and Bar had resulted in linkage errors instead of two classes > > coexisting at runtime that both used Map<String,Integer>s. Java 1.5 would > > have never gotten off the ground! But this C++ compiler -- and yes, it > was > > then-current gcc -- would do exactly that if you #included hash_map and > used > > hash_map<const char *,int,some_string_hashfn,strcmp> in two compilation > > units.) > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
