- A C++ program - 6 Updates
- Onwards and upwards - 2 Updates
- The concept "Compare" - 1 Update
- Container that has iterators to itself in the value_type - 3 Updates
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 28 11:56PM -0500 legalize+jeeves@mail.xmission.com (Richard) wrote in > Please god, no. > IMO, cygwin/mingw is a giant PITA on Windows and there isn't any need > for it. Cygwin is fine for getting a bunch of decent Unix tools working on Windows. For developing unrelated software, not so much. |
| David Brown <david.brown@hesbynett.no>: Apr 29 09:08AM +0200 On 29/04/15 06:56, Paavo Helde wrote: >> for it. > Cygwin is fine for getting a bunch of decent Unix tools working on Windows. > For developing unrelated software, not so much. Talking about cygwin/mingw is like talking about C/C++ - they are different things, with a certain overlap and common history. Cygwin was used a lot in the past as a way to get *nix software and tools running on Windows - it emulates most of posix. It has the disadvantages of being big, bulky, slow, and feeling "alien" in Windows (plus not everyone likes the licensing terms). Mingw provides a much smaller wrapper to make Windows look a bit more posix-like, but without covering everything. (As an example, cygwin provides "fork", even though it is very expensive to implement on Windows. mingw is limited to "spawn" which is much faster and less obtrusive. Mingw also lets you work with filenames and directories in Windows style, rather than converting them to a bastardisation between *nix and Windows.) Mingw is a perfectly good toolchain for Windows - it's C support (especially for the Mingw-w64 variant) is far superior to MS' tools. And msys (or now msys2) is a solid set of *nix tools and command-line utilities that are efficient and fit well with the rest of Windows. But if you need to compile *nix software unchanged on Windows, then cygwin might be the only way to do it. |
| legalize+jeeves@mail.xmission.com (Richard): Apr 29 03:29PM [Please do not mail me a copy of your followup] Paavo Helde <myfirstname@osa.pri.ee> spake the secret code >Cygwin is fine for getting a bunch of decent Unix tools working on Windows. >For developing unrelated software, not so much. Agreed. If what you want is sed/awk/grep, then by all means get cygwin. If what you want is a C++ development environment, then get VS community edition. I am very comfortable and productive with the command-line, but I first used a C++ IDE (VC6) in the late 1990s and now I don't want to go back to the primitive tools of the unix command-line for building, writing, editing, and debugging C++ code. (I'm OK with writing CMakeLists.txt, because cmake operates at a higher level than make.) I found myself much more productive using an IDE. Until recently, the best IDE for C++ development was Visual Studio, but with the release of CLion, it has a serious challenger. There are some things I like about both; CLion has a much faster feel than VS for navigating, editing and writing C++ code. VS has a truly awesome debugger. It makes gdb look like the early 1990s immitation of dbx that it is. VS has a better docking system than CLion. CLion has better refactoring support, although I haven't yet tried the VS2015 refactoring support. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| legalize+jeeves@mail.xmission.com (Richard): Apr 29 03:33PM [Please do not mail me a copy of your followup] David Brown <david.brown@hesbynett.no> spake the secret code >Mingw is a perfectly good toolchain for Windows - it's C support >(especially for the Mingw-w64 variant) is far superior to MS' tools. I think you're confusing C with POSIX here. They aren't the same thing. The POSIX implementation in MSVC has always been weak, although apparently they're finally getting around to plugging some of the holes in VS 2015. >But if you need to compile *nix software unchanged on Windows, then >cygwin might be the only way to do it. I agree with this because you said "unchanged". I've been dealing with system differences between unix implementations for decades and most of the time, dealing with the differences isn't a huge deal, although it is annoying. That's the whole reason people have configure scripts and the whole mess that is autotools and so-on. Personally I find CMake's approach to the problem better than autotools and it is more portable because it doesn't depend on bash or perl or python or whatever. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| David Brown <david.brown@hesbynett.no>: Apr 29 11:30PM +0200 On 29/04/15 17:33, Richard wrote: > The POSIX implementation in MSVC has always been weak, although > apparently they're finally getting around to plugging some of the > holes in VS 2015. No, MSVC has always been notoriously bad at standard C. It barely implements the language parts of C99, and until only a couple of years ago, it was missing substantial parts of the C99 library. For C++, I believe it is only a few years behind the mainstream (gcc, llvm, Intel) - but I haven't used it myself for quite some time. Posix support is an issue for Windows and translation layers (like cygwin, or the much smaller and thinner layers in mingw libraries) - and despite promises when NT was new, Windows has never tried to support posix properly. > Personally I find CMake's approach to the problem better than > autotools and it is more portable because it doesn't depend on bash or > perl or python or whatever. Indeed - autotools is not an efficient or pleasant system in my (limited) experience. But if you need to use it for something, then cygwin is the way to go for the greatest compatibility. When I first compiled a gcc cross-compiler on Windows, cygwin was the only "easy" option - but for many years it's been possible (and /much/ faster and easier) with mingw. |
| David Brown <david.brown@hesbynett.no>: Apr 29 11:34PM +0200 On 29/04/15 17:29, Richard wrote: >> Cygwin is fine for getting a bunch of decent Unix tools working on Windows. >> For developing unrelated software, not so much. > Agreed. If what you want is sed/awk/grep, then by all means get cygwin. No, get msys (or now msys2), which includes these tools compiled with mingw. They are faster, and a lot easier to use along with other Windows stuff. Only use cygwin if you need fork() and other "tougher" posix calls. > If what you want is a C++ development environment, then get VS > community edition. Or mingw-w64 and an IDE (Eclipse, Code Blocks, JEdit, etc. - or even emacs or vim). > makes gdb look like the early 1990s immitation of dbx that it is. VS > has a better docking system than CLion. CLion has better refactoring > support, although I haven't yet tried the VS2015 refactoring support. There's nothing wrong with using an IDE - but MSVS is not the only option for an IDE on Windows. |
| drew@furrfu.invalid (Drew Lawson): Apr 29 04:45PM In article <D9GdnRDo_MGucqLInZ2dnUU7-cednZ2d@giganews.com> >What the fuck are you doing mate? Exceptions should be thrown rarely not >routinely (mainly for exceptional conditions) so who cares about bloody >string allocations? I share that view, but not everyone does. A couple jobs back, I was in an organization where exceptions were the preferred response to almost everything. If a request was not a pure, unqualified, success, the server threw an exception. Some parts would make a request, catch the exception, change the request parameters, throw a "try again" exception, catch that further up the stack, and then resubmit the request. Probably 1/4 of the application was try/catch blocks. Drove me crazy, especially trying to find where in that flow to make an otherwise simple change. -- Drew Lawson | Radioactive cats have | 18 half-lives | |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 29 10:11PM +0100 On Tue, 28 Apr 2015 15:01:11 -0700 (PDT) > Leigh, please don't swear here. I wish you could get it into your somewhat curious system of reasoning that "fuck" is not swearing. It is bad language (for some of the more fastidious at least, personally I couldn't care a fuck). Swearing is an offence to your god. Bad language is an offence to man. Chris |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 29 07:24PM On Tue, 2015-04-28, Stefan Ram wrote: > about the concept »Compare« that I gave might help the > OP to learn what kind of type is expected in his code, > and something similar might become part of C++17 or C++2x. The SGI STL documentation from 1998 explains it clearly, too: https://www.sgi.com/tech/stl/List.html https://www.sgi.com/tech/stl/LessThanComparable.html /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Victor Bazarov <v.bazarov@comcast.invalid>: Apr 28 07:49PM -0400 On 4/28/2015 6:44 PM, Marcel Mueller wrote: >> What would your container contain if it only had one element? IOW, what >> happens when it goes from empty to ??? upon the first insertion? > The first entry gets end(). OK, so the first entry makes your map non-empty. In other words, the map contains one element, and therefore its iterators are now end() (which is kept in the first element) and the one that is not 'end()', i.e. the iterator to the "first" entry, whose content is 'end()', yes? And where is that iterator kept? You seem to immediately need to insert another element into your map which should contain the iterator to the first non-end() iterator. That is, your map now contains two entries, the first of which is 'end()', the other is the iterator of the "real" element... And so on. > When the second entry is inserted the first > one is changed to the iterator returned from the second insert and so > forth. When? And where is the consistency of the map? It will always contain one element iterator to which is not kept in the same map? 8-O > oldest elements after a specified size has been reached. I only need to > keep an iterator to the oldest element (head) for removal and one to the > newest element (tail) for replacing end() of the last entry. What is it you're trying to model with that paradoxical structure? And why a map? If you need a circular buffer, find and use a circular buffer. I am sure there are numerous examples of such an adapter. V -- I do not respond to top-posted replies, please don't ask |
| "Öö Tiib" <ootiib@hot.ee>: Apr 28 05:32PM -0700 On Wednesday, 29 April 2015 02:49:23 UTC+3, Victor Bazarov wrote: > What is it you're trying to model with that paradoxical structure? And > why a map? If you need a circular buffer, find and use a circular > buffer. I am sure there are numerous examples of such an adapter. It feels like when there is std::array<Something,SpecifiedSize> insertion_sequence; whose elements can be same time also in boost::intrusive::multiset<Something> lookup_set; So he can O(log SpecifiedSize) find an element by some criteria from the sequence instead of O(SpecifiedSize). |
| "K. Frank" <kfrank29.c@gmail.com>: Apr 29 11:50AM -0700 Hello Marcel! You raise a very interesting question (for which I don't have a clean answer). On Tuesday, April 28, 2015 at 4:16:47 PM UTC-4, Marcel Mueller wrote: > The iterators are required to maintain a second independent sort order, > that only needs a linked list because it only requires the operations > pop_front and push_back. Without going into why you might want to do this or whether it would be a good idea, I do think you raise a very interesting general point. In the "old days" you might do something like: typedef struct Element { Element* pElement; } element_type; typedef element_type collection_type[30]; This is a very standard usage, purposely supported by the language, and used, e.g., by the classic linked list. This works because you can use pointers to incomplete types. (You can also forward-declare incomplete types.) Now one aspect of iterators is that they are abstractions or generalizations of pointers. So you raise the very natural question of how or whether the same thing might be done with iterators. As far as I know, you can't, but I would love to be shown wrong. Of course, "All problems can be solved by another level of indirection." So you could do something like: #include <map> using std::multimap; struct iterator_wrapper; typedef int key_type; typedef iterator_wrapper* element_type; typedef multimap<key_type, element_type> map_type; typedef map_type::iterator iterator_type; struct iterator_wrapper { iterator_type it; }; This, to my mind, has two imperfections: Iterators are already a form of indirection, so the extra level of indirection -- element_type is a pointer -- seems conceptually unnecessary, and could add a little cost. Also, while adding no run-time cost, the need to wrap the iterator in iterator_wrapper (I don't see any way to avoid this.) seems unfortunate. Your desired use case illustrates a feature of pointers that iterators do NOT provide. Would it make sense for the language / standard library to provide such functionality for iterators? (And would it be possible, given that standard-library collections are templates?) > Marcel Best regards. K. Frank |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment