- "Jonathan Blow: "C++ is a weird mess"" - 4 Updates
- Some C++14 code - 10 Updates
- Just some code - 1 Update
- ReKilling Cortana zombies. - 1 Update
- auto return type - 1 Update
| bitrex <user@example.net>: Jul 12 09:30PM -0400 On 07/10/2018 08:48 AM, Bo Persson wrote: > So, starting from scratch might look promising initially, but... > Bo Persson C++ is a good language to write functional sections that need to be high-performance and utilized as "black box" modules, in some other language, in. |
| Vir Campestris <vir.campestris@invalid.invalid>: Jul 13 11:27PM +0100 On 10/07/2018 22:57, Ian Collins wrote: >> Studio. I haven't found a Linux one as good. > Visual Studio Code? > https://code.visualstudio.com/ I'll have a look. Thanks. It wasn't around when I was last looking for a tool. Andy |
| Ian Collins <ian-news@hotmail.com>: Jul 14 10:46AM +1200 On 14/07/18 10:27, Vir Campestris wrote: >> https://code.visualstudio.com/ > I'll have a look. Thanks. It wasn't around when I was last looking for a > tool. Most of out ex-Windows developers use it. It's an excellent tool for anyone moving to Linux who is used to Visual Studio. -- Ian. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 13 07:12PM -0400 On 7/13/2018 6:46 PM, Ian Collins wrote: >> tool. > Most of out ex-Windows developers use it. It's an excellent tool for anyone > moving to Linux who is used to Visual Studio. From Visual Studio 2015 on VS supports GDB directly from the Visual Studio Debugger. Visual Studio GDB Debugger https://www.youtube.com/watch?v=-3toI8L3Oug -- Rick C. Hodgin |
| Tim Rentsch <txr@alumni.caltech.edu>: Jul 12 07:39PM -0700 > The _runtime_ component of C++, the actual stuff that gets parsed > directly into object code, is really nothing much more than a mild > superset of C, [...] "a mild superset". That's a good one. :) |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jul 13 03:01AM >> directly into object code, is really nothing much more than a mild >> superset of C, [...] > "a mild superset". That's a good one. :) It is better to say that C++ has compatibility with C, then speaking in terms of superset. -- press any key to continue or any other to quit... |
| keepgoingalf@what.a.hero.com: Jul 13 09:23AM On Thu, 12 Jul 2018 17:23:23 +0200 >On 12.07.2018 16:38, pooroldalf@has.no.clue.com wrote: > > [idiocy redacted] >5th Boltar identity killfiled. Keep going mate! :) |
| boltar@cylonHQ.com: Jul 13 09:32AM On Thu, 12 Jul 2018 12:29:54 -0400 >I think if you want to make a counterpoint it would be fair to provide >examples of what you consider to be a high-performance non-showboaty >codebase that approaches your ideals or else it's hard to say what we're Sorry, I have better things to do than rewrite Alfs code. You'll just have to believe me when I say I believe its needlessly overcomplicated. >C++ is all about performance that's why you use features like move >semantics and template gobblediegook. If one prefers less "complicated" I'm not saying new features shouldn't be used. But there's a time and place. For example he just loves to use this sort of syntax (look back in his posts): auto func() -> int { } Why? The point of auto is when you DON'T know the return type. What is so wrote with just writing: int func() { }. Answer - nothing. He just likes to show off. >languages that many people seem to like better; Python, C#, Go, Rust, >and so forth. I also use python. C# only runs on windows and Go and Rust seem to be just wannabe C++'s which isn't a good enough reason to use them. You also forgot 'D' which is another. >leverage them to make super-clean non-showoffy simple code that also has >C-like performance some of the stuff you end up with isn't going to be >that much more parsable than what we've seen here. If I need C like performance I'll just use C. It has the advantage (unlike C++) of being almost entirely explicit - what you see is what you get. Unlike in C++ where all sorts of hidden things can happen and can sometimes be missed even by professionals when looking at code. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 13 12:50PM +0200 On 13.07.2018 11:23, "Boltar" wrote: > On Thu, 12 Jul 2018 17:23:23 +0200 [redacted] 6th Boltar identity killfiled. "Boltar" REALLY likes to troll by posting with fake identities to clc++. So maybe there are two nutcases with that behavior pattern in clc++. |
| Manfred <noname@add.invalid>: Jul 13 03:45PM +0200 On 7/10/2018 5:44 PM, Alf P. Steinbach wrote: > expression. I would be happy to learn of some better way than the > `move(*this)`. It was the first I could think of, but it is very very > ugly to my eyes... So, suggestions/ideas/knowledge very welcome. One alternative could be non-member operators << : struct Itemlist { std::string description() const { // do something return ""; } }; template<class Item> static Itemlist&& operator << (Itemlist&& lhs, Item item) { return std::move(lhs); } struct Sub : Text_item , Itemlist { Sub(const std::string& text) : Text_item(0, text) { } }; template< class Item > static Sub&& operator << (Sub&& lhs, Item item ) { return static_cast<Sub&&>( operator << ( static_cast<Itemlist&&>(lhs), item ) ); } It still insists on requiring std::move(lhs) on the operator << for Itemlist, but at least it gets rid of the really ugly |
| boltarsdog@kennel.com: Jul 13 02:49PM On Fri, 13 Jul 2018 12:50:06 +0200 >6th Boltar identity killfiled. >"Boltar" REALLY likes to troll by posting with fake identities to clc++. >So maybe there are two nutcases with that behavior pattern in clc++. No, its just amusing to watch your pomposity. :) |
| Daniel <danielaparker@gmail.com>: Jul 13 09:09AM -0700 > C# only runs on windows No. My music player Roon consists of a Roon Server running on a dedicated linux box and a Roon app running on an ipad mini, all using C#. Daniel |
| Vir Campestris <vir.campestris@invalid.invalid>: Jul 13 10:28PM +0100 > having to use specialisation and/or typeid() sprinkled around your code when > you get down to the point where types have to processed individually which > is little different to what you'd have to do in C from the start. I think you must be using them wrongly. Andy |
| Vir Campestris <vir.campestris@invalid.invalid>: Jul 13 11:27PM +0100 > just for example purposes, not a definitive API. However the point is that > for probably 90% of what C++ containers get used for the C equivalent wouldn't > be too much extra work to use. Oh, but it would. Those smart pointers, for example, mean you don't have to remember to call free when you've finished with the memory. You just let the smart pointer go out of scope, and the target vanishes. And this happens down all your obscure error paths too. And the copy - once you've taught the object how to copy itself nobody else has to mess about with memcpy(target, source, sizeof(type)) then fix any embedded pointers. Andy |
| Tim Rentsch <txr@alumni.caltech.edu>: Jul 13 05:56AM -0700 > co-authored with Andrei Alexandrescu (author of ?Modern C++ Design?), > is a classic. But most of it addresses C++03 concerns, at the time > C++98 concerns, that are not particularly relevant in C++11 and later. To me the key idea is using a closure to hold a deferred action. Tying the closure to an object destructor is just a detail of this application. > improvement of efficiency. Marginean's main contribution was a > trick to do this in C++03, using lifetime extension of a temporary > bound to a reference to const. [...] I have the sense that the cleverness is needed to get around a fundamental property of object construction being tied to declarations, which have a fixed type. That makes me wonder whether this technique might be not the right tool to use. If I were faced with a similar problem in the future I would probably look for a different approach. > one should really have two distinct scope guard classes, one > dismissable and one not, so that what can happen, the possible > effects on the code, is more clear. Spot on. I might even say it more strongly, that the two are totally different animals, and using the same name for both (modulo the "dismissable" adjective) is an accident waiting to happen. > The simple C++11 implementations, like yours and Microsoft's, > implicitly make an important design decision opposite of > Marginean and Alexendrescu. Presumably they wanted to provide flexibility. But I agree it is important to distinguish the two different cases. > discussing that with Andrei in a short e-mail exchange, because > it bit me, but I didn't get a satisfactory answer as to their > rationale or goals. That sounds like it might be interesting but as details were left out I will drop it and move on. :) >> Fixer supersede_with( const char * ), use_stdin(); > Style nitpick: hiding function declarations inside a function > hinders at-a-glance code comprehension. I deliberately put the declarations inside the definition of main(), both to limit visibility and to indicate that they are in effect "private" functions. It would have been better though to put in an explicit "extern". > Ditto style nitpick: when I see a variable that's not `const` I > start looking for the place where it's modified, how it affects > the code. Different people have different ideas about when using 'const' is important. I think people in the C++ community tend to be more prone to using 'const' reflexively. I don't do that. I do use 'const' in places where I think it adds more than it costs; in very short functions, like this one, it seems like more of a distraction than a help, which gives a net negative. I realize other people have different views or put different weights on the various factors. YMMV. >> Running the program produced the expected output in both case. > >> (Also thanks due to Manfred, from whose program I cribbed a bit.) > Thanks for this approach, I didn't think of it ? stuck in Old Ways?. :) Thank you very much. Is there some reason you were expecting it to be tied to "Old Ways"? > Sorry for responding so late. [...] No worries. I can't afford to always (or even often) give responses quickly, 'cause I got other things in need of attention that must get priority. So I can't very well let some "late" responses from other people bother me. :) |
| Jeff-Relf.Me @.: Jul 13 01:47AM -0700 |
| Tim Rentsch <txr@alumni.caltech.edu>: Jul 12 08:44PM -0700 > mutable global state). Most people would say the word 'pure' has > something to do with the notion of a mathematical function, where > mutable global state has no meaning. I haven't seen any evidence for this assertion. On the other hand, there is evidence for my earlier statement, in the form of statements in the Wikipedia article (which presumably has been read by thousands of people), and in the literature discussing various functional languages. Some might say these things are rather weak or indirect evidence, and I won't argue with that, but they are still _some_ evidence. I still don't see that any evidence has been presented for your position. > So I think this is a point on > which we are going to have to agree to disagree about what is the > common understanding, which is in any event a matter of opinion. Which understanding is more common is a question of fact, not of opinion. It isn't feasible to verify which one is the case, but in principle an answer can be objectively determined just by polling the appropriate audience set about what their views are. That makes the matter a question of fact. Note by the way that my statement was made for the set of people "in the general programming community." > "referentially_transparent". "Pure" is short and snappy and does the > business in my view, and is malleable enough to mean what you have > decided you need it to mean. I am opposed on principle to bending the meaning of words to fit incongruous situations just because the word happens to be short or in some other way convenient. Moreover the word "pure" isn't really very descriptive of what's going on, ie, for functions that don't depend on the outside environment. A better term might be "self-contained", or if we really need a shorter word, "closed". > At least two people think that another name should be chosen > because "pure" is already taken in C++, in the expression "pure > virtual function". My best understanding now is that people take this to be a compound adjective followed by a noun; that is, not "pure, virtual function", but instead "(pure virtual) function". So that may not impinge on what "pure" means by itself. > constexpr arguments may be impure on any view of what it means > for a function to be 'pure'. I am disappointed but on that point duly > enlightened. You're disappointed? To me it seems like cause for celebration, because it shows that what "constexpr" means cuts across other function-classification terms, and so it deserves its own name. |
| 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