| "R.Wieser" <address@not.available>: Aug 10 09:20AM +0200 Hello All, -- First question: I've created, in Visual C++ 2008, a class like the below (to communicate with a non-VC++, dynamically loaded object). class ExternalObject { public: ExternalObject(); ~ExternalObject(){}; virtual void Destructor(ExternalObject* TheObject) = 0; virtual int Message(ExternalObject* TheObject, int* type, void* data) = 0; }; As you can see each virtual method currently contains a manually provided "this" argument (TheObject), and needs to be called like this: MyObject->Message(MyObject, 0, "Hello World"); My question is, how can I change the class in such a way that the "MyObject" 'this' argument is automatically added ? Or to be more precise, how can tell Visual C++ 2008 to transfer the 'this' *by argument* instead of by the ECX register. -- Second question: How do I do the reverse -- When an external object calls an object within the Visual C++ 2008 program have it accept a provided 'this' *argument* and make it available inside the called method by way of the 'this' keyword. Remark: The code, using the described class, already works. I just want to know if I can create a "cleaner" implementation of the above. Regards, Rudy Wieser |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 10 09:27AM +0200 On 10.08.2017 09:20, R.Wieser wrote: > MyObject->Message(MyObject, 0, "Hello World"); > My question is, how can I change the class in such a way that the "MyObject" > 'this' argument is automatically added ? Possibly you can modify the `ExternalObject` class directly, but depending on what it does, maybe not. If so a general solution is create a wrapper class W where each W instance holds a `this` pointer for the external object. > Or to be more precise, how can tell Visual C++ 2008 to transfer the 'this' > *by argument* instead of by the ECX register. Don't. > How do I do the reverse -- When an external object calls an object within > the Visual C++ 2008 program have it accept a provided 'this' *argument* and > make it available inside the called method by way of the 'this' keyword. That's just the reverse, a wrapper whose member functions call your real C++ object's member functions. > Remark: The code, using the described class, already works. I just want to > know if I can create a "cleaner" implementation of the above. Yes, you can. That's what almost every GUI framework does. Cheers & hth., - Alf |
| Kalle Olavi Niemitalo <kon@iki.fi>: Aug 10 10:58AM +0300 > Or to be more precise, how can tell Visual C++ 2008 to transfer the 'this' > *by argument* instead of by the ECX register. I would try the __stdcall keyword. https://msdn.microsoft.com/en-us/library/zxk0tw93(v=vs.90).aspx |
| "R.Wieser" <address@not.available>: Aug 10 10:58AM +0200 Alf, > If so a general solution is create a wrapper class W where each > W instance holds a `this` pointer for the external object. I don't think so, as that would make the mess bigger, not smaller. Also, the 'this' argument is just a copy of the object-reference left of the "->". In other words: *its already there*. And yes, I could do it that way. Defining a number of static public callable methods which than in turn call the, declared as private, actual external methods. But thats not what I'm currently looking for ... > > Or to be more precise, how can tell Visual C++ 2008 to transfer > > the 'this' *by argument* instead of by the ECX register. > Don't. Why ? I'm prepared to listen to a good reason for not doing it. Is there one ? Mind you, that class is there to define what the external object looks like (and needs!), nothing else. > Yes, you can. > That's what almost every GUI framework does. I do not quite understand. What has a *GUI* framework to do with what I described ? But if I understand you correctly, what I'm asking for is *not possible* in Visual C++ 2008 ? Heck, I thought it would be a simple request. Regards, Rudy Wieser -- Origional message: Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> schreef in berichtnieuws omh1lj$khf$1@dont-email.me... > > ~ExternalObject(){}; > > virtual void Destructor(ExternalObject* TheObject) = 0; > > virtual int Message(ExternalObject* TheObject, int* type, void* data) = 0; > > }; > > As you can see each virtual method currently contains a manually provided > > "this" argument (TheObject), and needs to be called like this: > > MyObject->Message(MyObject, 0, "Hello World"); > > My question is, how can I change the class in such a way that the "MyObject" > a wrapper class W where each W instance holds a `this` pointer for the > external object. > > Or to be more precise, how can tell Visual C++ 2008 to transfer the 'this' > Don't. > > -- Second question: > > How do I do the reverse -- When an external object calls an object within > > the Visual C++ 2008 program have it accept a provided 'this' *argument* and > That's just the reverse, a wrapper whose member functions call your real > C++ object's member functions. > > Remark: The code, using the described class, already works. I just want to |
| "R.Wieser" <address@not.available>: Aug 10 10:29AM +0200 Kalle, > I would try the __stdcall keyword. I've taken a peek at that MSDN page, but I do not see any reference (directly or indirectly) to the 'this' argument ... Regards, Rudy Wieser -- Origional message: Kalle Olavi Niemitalo <kon@iki.fi> schreef in berichtnieuws 87lgmrrh0n.fsf@Niukka.kon.iki.fi... > "R.Wieser" <address@not.available> writes: > > Or to be more precise, how can tell Visual C++ 2008 to transfer the 'this' |
| Kalle Olavi Niemitalo <kon@iki.fi>: Aug 10 01:43PM +0300 > I've taken a peek at that MSDN page, but I do not see any reference > (directly or indirectly) to the 'this' argument ... The MSDN page says __stdcall can be used for "non-static class functions", so the 'this' argument has to be passed somewhere; and __stdcall has no special rule for 'this', so 'this' will go on the stack, which I understand is what you wanted. I don't know whether 'this' will become the first or last argument, though. Compare __stdcall to the default __thiscall, which passes 'this' in ECX and the rest on the stack. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 10 12:46PM +0200 Please don't top-post. Thank you. On 10.08.2017 10:58, R.Wieser wrote: |
| "Öö Tiib" <ootiib@hot.ee>: Aug 10 03:58AM -0700 On Thursday, 10 August 2017 13:46:55 UTC+3, Alf P. Steinbach wrote: > Please don't top-post. Thank you. Is it some sort of joke? Can you elaborate, hopefully I'm not the only one who missed it. For me he clearly did not top-post. |
| "Öö Tiib" <ootiib@hot.ee>: Aug 10 04:48AM -0700 On Thursday, 10 August 2017 11:58:53 UTC+3, R.Wieser wrote: > I don't think so, as that would make the mess bigger, not smaller. Also, > the 'this' argument is just a copy of the object-reference left of the "->". > In other words: *its already there*. It is because what you are trying looks like mess (wrappers) and you are asking how to make it bigger mess (more wrappers). We can make bigger mess by doing a bigger mess. > callable methods which than in turn call the, declared as private, actual > external methods. > But thats not what I'm currently looking for ... May be you need to provide real minimum example of what you want together with example of what you have tried to achieve that. C++ is so anarchistic language that something close to any piece of text is possible to make compile as C++. Especially C++2014 However your example does not compile into any motivating examples. > one ? > Mind you, that class is there to define what the external object looks like > (and needs!), nothing else. Since using __stdcall for every non-static member function can also make the mess conceivably bigger not smaller. > > That's what almost every GUI framework does. > I do not quite understand. What has a *GUI* framework to do with what I > described ? Every GUI framework tries (and usually quite successfully) to make itself extendable being not too intrusive and requiring minimal boilerplate code. Yes those also use macros, templates and wrappers but hide that in library. > But if I understand you correctly, what I'm asking for is *not possible* in > Visual C++ 2008 ? > Heck, I thought it would be a simple request. How can be request about C++98 compiler simple today? For example I start to forget its constraints and limitations and don't have it installed anywhere to try either. |
| "R.Wieser" <address@not.available>: Aug 10 02:03PM +0200 Kalle, > so the 'this' argument has to be passed somewhere; > and __stdcall has no special rule for 'this', so 'this' will > go on the stack I have no idea how you came to that "must go on the stack" conclusion. Why would __stdcall even *know* of the existance of the "this" object-reference ? (and why isn't it mentioned <grumble>) But! I just tried/tested it and it looks you're right. So, my thanks. :-) One thing though: as far as I know stdcall differs from a c-calling mechanism in that the former expects the called method to remove the arguments from the stack, while the latter expects the caller to do it. Do you know if there is a "the caller is responsible for the stack" version of __stdcall (so nothing changes but for the 'this' handling) ? Regards, Rudy Wieser -- Origional message: Kalle Olavi Niemitalo <kon@iki.fi> schreef in berichtnieuws 87d183r9cj.fsf@Niukka.kon.iki.fi... |
| "R.Wieser" <address@not.available>: Aug 10 02:12PM +0200 Alf, > Please don't top-post. Thank you. I'm not going to argue this with you, but I suggest you look again. At my posting style as wel as what "top posting" means. And for the record: you can stop reading when you encounter the "-- Origional message:" line. That is what its there for. :-) Regards, Rudy Wieser P.s. And as always funny to see someone complain about something his own post is guilty of itself ... -- Origional message: Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> schreef in berichtnieuws omhdae$l2t$1@dont-email.me... > >> If so a general solution is create a wrapper class W where each > >> W instance holds a `this` pointer for the external object. > > I don't think so, as that would make the mess bigger, not smaller. Also, > > the 'this' argument is just a copy of the object-reference left of the "->". > > In other words: *its already there*. > > And yes, I could do it that way. Defining a number of static public > > callable methods which than in turn call the, declared as private, actual > >>> the 'this' *by argument* instead of by the ECX register. > >> Don't. > > Why ? I'm prepared to listen to a good reason for not doing it. Is there > > one ? > > Mind you, that class is there to define what the external object looks like > > I do not quite understand. What has a *GUI* framework to do with what I > > described ? > > But if I understand you correctly, what I'm asking for is *not possible* in > > Rudy Wieser > > -- Origional message: > > Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> schreef in berichtnieuws > >>> Hello All, > >>> -- First question: > >>> I've created, in Visual C++ 2008, a class like the below (to communicate > >>> ~ExternalObject(){}; > >>> virtual void Destructor(ExternalObject* TheObject) = 0; > >>> virtual int Message(ExternalObject* TheObject, int* type, void* data) > >>> 'this' argument is automatically added ? > >> Possibly you can modify the `ExternalObject` class directly, but > >> depending on what it does, maybe not. If so a general solution is create > >>> How do I do the reverse -- When an external object calls an object > > within > >>> the Visual C++ 2008 program have it accept a provided 'this' *argument* > > and > >>> make it available inside the called method by way of the 'this' keyword. > >> That's just the reverse, a wrapper whose member functions call your real |
| "R.Wieser" <address@not.available>: Aug 10 02:35PM +0200 Öö Tiib, > It is because what you are trying looks like mess (wrappers) You have to explain that one to me I'm afraid. As far as I can see the method that I use to call the extenal object while providing it a manual "this" reference can't be unwrapped at all. Can you provide an unwrapped/less messy calling method ? If so, please do! > May be you need to provide real minimum example of what you > want together with example of what you have tried to achieve that. You already got it. And forgive me for not providing more, *non relevant to the question*, code. The last times I did that the replies only side-tracked (and downright evaded!) the question, leaving me without an answer and rather frustrated. I have no desire to repeat it. What I asked is what I want/need to know. No more, no less. After that I will (most likely!) test the sh*t outof it, just to see how-and-when it breaks when I abuse it -- and by it learn its limitations. :-) > Since using __stdcall for every non-static member function can > also make the mess conceivably bigger not smaller. Yes ...? How ? Mentioning that there could be pitfalls without pointing them out is rather cruel, especially as I'm already walking the path ... > > Heck, I thought it would be a simple request. > How can be request about C++98 compiler simple today? I have no idea. But Kalle's suggestion to add the "__stdcall" keyword seems simple enough. :-) Regards, Rudy Wieser -- Origional message: Öö Tiib <ootiib@hot.ee> schreef in berichtnieuws 830e50da-184e-4154-b4b5-2842d5a36ec1@googlegroups.com... > On Thursday, 10 August 2017 11:58:53 UTC+3, R.Wieser wrote: > > Alf, > > Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> schreef in berichtnieuws > > > If so a general solution is create a wrapper class W where each > > > W instance holds a `this` pointer for the external object. > > I don't think so, as that would make the mess bigger, not smaller. Also, > > the 'this' argument is just a copy of the object-reference left of the "->". > mess by doing a bigger mess. > > And yes, I could do it that way. Defining a number of static public > > callable methods which than in turn call the, declared as private, actual > > > > the 'this' *by argument* instead of by the ECX register. > > > Don't. > > Why ? I'm prepared to listen to a good reason for not doing it. Is there > > one ? > > Mind you, that class is there to define what the external object looks like > Yes those also use macros, templates and wrappers but hide that in > library. > > But if I understand you correctly, what I'm asking for is *not possible* in > > Heck, I thought it would be a simple request. > How can be request about C++98 compiler simple today? For example I > start to forget its constraints and limitations and don't have it installed |
| David Brown <david.brown@hesbynett.no>: Aug 10 02:41PM +0200 On 10/08/17 14:12, R.Wieser wrote: >> Please don't top-post. Thank you. > I'm not going to argue this with you, but I suggest you look again. At my > posting style as wel as what "top posting" means. Your posting style is not top-posting - but neither is it standard Usenet style. > And for the record: you can stop reading when you encounter the "-- > Origional message:" line. That is what its there for. :-) No, that is /not/ what "-- " is for. "-- " on a line of its own (that part is important) starts a signature in Usenet and email. The signature should be short - typically 4 lines maximum - and is used for things like the sender's name, addresses, favourite quotation, etc. A compliant Usenet client will skip the signature when replying to the post. I don't know whether it is your Usenet client (Outlook Express? I don't think I have seen that for a decade or so) that mangles your posts, or whether you have set this up by default. But your posts /are/ mangled in a non-standard format, and it is not surprising that some people express a dislike for it. Whether you continue to use your non-standard style, or choose to fix it, is of course up to you. But you may cause people who would otherwise help you, to ignore you. (I have never used MSVC, and don't do any C++ programming on Windows, so I can't offer any help for your problem.) > Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> schreef in berichtnieuws > omhdae$l2t$1@dont-email.me... >> Please don't top-post. Thank you. <snip> |
| "R.Wieser" <address@not.available>: Aug 10 03:00PM +0200 Kalle, [I wrote] > do it. Do you know if there is a "the caller is responsible for the > stack" version of __stdcall (so nothing changes but for the 'this' > handling) ? No need to answer that one anymore. I should have quenched my urge for an explanation, and should have googeled *before* having posted it. :-| It seems that Visual C++ 2008 already uses a stdcall method, and all that the by you suggested "__stdcall" does is to override the 'this' behaviour (correct me if I'm wrong here please). Regards, Rudy Wieser |
| "R.Wieser" <address@not.available>: Aug 10 03:42PM +0200 David, I wrote a full reply to you, only to realize that it would be rather fruitless. The only thing it would lead to would be a "discussion" like between a catholic and a protestant arguing their believes, with them fully ignoring they both worship the same god. So, let anyone do whatever he pleases and reject whomever he wants over some minor "your way is not my way" gripe, and I will talk with the ones that are than left. Actually, those "left overs" are most likely less inclined to try to force me to follow whatever programming approach they favour, so thats a big win for me. :-) Regards, Rudy Wieser -- Origional message: David Brown <david.brown@hesbynett.no> schreef in berichtnieuws omhk19$99u$1@dont-email.me... > > Alf, > >> Please don't top-post. Thank you. > > I'm not going to argue this with you, but I suggest you look again. At my > > Rudy Wieser > > P.s. > > And as always funny to see someone complain about something his own post is > > guilty of itself ... > > -- Origional message: > > Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> schreef in berichtnieuws |
| "Öö Tiib" <ootiib@hot.ee>: Aug 10 07:42AM -0700 On Thursday, 10 August 2017 15:36:02 UTC+3, R.Wieser wrote: > method that I use to call the extenal object while providing it a manual > "this" reference can't be unwrapped at all. Can you provide an > unwrapped/less messy calling method ? If so, please do! Non-virtual destructor and virtual member function called "Destructor" seem like pointless over-engineering with wrappers. Isn't that mess? Why there can't be just virtual destructor? > What I asked is what I want/need to know. No more, no less. After that I > will (most likely!) test the sh*t outof it, just to see how-and-when it > breaks when I abuse it -- and by it learn its limitations. :-) Note "may be". Lack of information what you want to achieve with all that can not help me any to understand what you want. ;-) > > also make the mess conceivably bigger not smaller. > Yes ...? How ? Mentioning that there could be pitfalls without pointing > them out is rather cruel, especially as I'm already walking the path ... I thought it was obvious. Text like "__stdcall" to every non-static member function is ugly and makes the whole thing harder to read, replacing it with some macro say "STC" is confusing and you won't still get some benefits that you might want (like be able to cast member function pointers into ordinary function pointers) without making it fragile. > > How can be request about C++98 compiler simple today? > I have no idea. But Kalle's suggestion to add the "__stdcall" keyword > seems simple enough. :-) If it does what you want then it is good. It was unclear from your post. |
| David Brown <david.brown@hesbynett.no>: Aug 10 05:30PM +0200 On 10/08/17 15:42, R.Wieser wrote: > David, > I wrote a full reply to you, only to realize that it would be rather > fruitless. I am not looking for a discussion - I am just giving you a statement of facts about Usenet and standard Usenet posting conventions. You can choose to follow them or not. But be very clear on this - there /is/ a convention, the majority of regulars in this group and other technical groups follow the convention, and there are knowledgeable and helpful people who are less inclined to reply to people who flout that convention. And while your posting style is not strictly "top posting", it is an unconventional style that some (including me) find unpleasant. Those are /facts/ - not opinions, or personal preferences. Google Usnet posting style articles until you understand, if you do not accept my word for it. Whether any given person chooses to respond to you or not is, of course, personal preference of those posters. Whether or not you think your posting style is better than the one used by almost everyone else, is of course /your/ opinion. Whether you think it is so much "better" that you are happy to alienate potential helpful responders, is also /your/ choice. As I say, I can't give you any help on the subject of the thread in this case - it is simply something I know almost nothing about. (Indeed, I don't make many posts in this particular group.) Would I respond helpfully in the future if you asked something that I /could/ answer? I can't say at the moment. I am not the fussiest of Usenet users, but I do find non-standard posting styles somewhat annoying. |
| "R.Wieser" <address@not.available>: Aug 10 07:28PM +0200 嘱 Tiib, > Non-virtual destructor and virtual member function called > "Destructor" seem like pointless over-engineering with > wrappers. Isn't that mess? Nope. You think you are seeing, nonwithstanding me *obviously* still being busy with it, a finished product. > Why there can't be just virtual destructor? Good question, and one I had already lined up to ask after my current, 'this' argument related, question was answered. Yes, it was/is my intention to have the "~ExternalObject" destructor replace the "Destructor" function. That I have both is because of that. Actually, I thought that both the constructor as well as destructor where mandated. I didn't directly realize that that does not seem to be the case for a pure virtual (never instanciated) object. I do now. :-) But you can read all about it in my next question/thread. > Note "may be". Lack of information what you want to achieve > with all that can not help me any to understand what you want. ;-) Just assume that what I'm asking is what I "want". No more, no less. That should be much easier than to try to second-guess what I *really* want, no ? :-) As I mentioned, I've encountered to many responders which went off on tangents and left me rather frustrated as a result to want to give anyone that chance again. Just take yourself: Instead of concentrating on answering the question I put forward you instead thought it was a good idea to make some unsubstanciated "wrappers" and "bigger mess" claims (which both have fizzeled out). > I thought it was obvious. Text like "__stdcall" to every non-static > member function is ugly and makes the whole thing harder to read You're not serious there, are you ? I could say the exact same about the "virtual" keyword (or any other), and it would be as silly. But, do you have a better solution ? If not, are you sure you're not just complaining because you can ? So no, adding a single directive (to each of my virtual methods) is not what I consider "a bigger mess", *especially not* when it does exactly what I requested. > ...and you won't still get some benefits that you might want > (like be able to cast member function pointers into ordinary > function pointers) without making it fragile. I have *no* idea what you are talking about there. Are you again trying to second-guess my intentions (regarding the code) maybe ? That would not be a good idea you know. :-| > If it does what you want then it is good. It was unclear from your post. Was *what* unclear please ? And knowing what you now know I asked for how could I have done better ? Also, Kalle understood my question well enough to answer it with a single line, even a single (key)word ... And for the record, do you realize that, apart from the "Is it some sort of joke?" remark in a post to Alf (which I should thank you for), you have only given me grief ? Why ? Regards, Rudy Wieser -- Origional message: 嘱 Tiib <ootiib@hot.ee> schreef in berichtnieuws c05c1d5e-f3fd-4b92-b5d1-856876f9547a@googlegroups.com... On Thursday, 10 August 2017 15:36:02 UTC+3, R.Wieser wrote: > method that I use to call the extenal object while providing it a manual > "this" reference can't be unwrapped at all. Can you provide an > unwrapped/less messy calling method ? If so, please do! Non-virtual destructor and virtual member function called "Destructor" seem like pointless over-engineering with wrappers. Isn't that mess? Why there can't be just virtual destructor? > > want together with example of what you have tried to achieve that. > You already got it. > And forgive me for not providing more, *non relevant to the question*, code. > evaded!) the question, leaving me without an answer and rather frustrated. > I have no desire to repeat it. > What I asked is what I want/need to know. No more, no less. After that I > will (most likely!) test the sh*t outof it, just to see how-and-when it > breaks when I abuse it -- and by it learn its limitations. :-) Note "may be". Lack of information what you want to achieve with all that can not help me any to understand what you want. ;-) > > Since using __stdcall for every non-static member function can > > also make the mess conceivably bigger not smaller. > Yes ...? How ? Mentioning that there could be pitfalls without pointing > them out is rather cruel, especially as I'm already walking the path ... I thought it was obvious. Text like "__stdcall" to every non-static member function is ugly and makes the whole thing harder to read, replacing it with some macro say "STC" is confusing and you won't still get some benefits that you might want (like be able to cast member function pointers into ordinary function pointers) without making it fragile. > > How can be request about C++98 compiler simple today? > I have no idea. But Kalle's suggestion to add the "__stdcall" keyword > seems simple enough. :-) If it does what you want then it is good. It was unclear from your post. |
| scott@slp53.sl.home (Scott Lurndal): Aug 10 05:39PM >As I mentioned, I've encountered to many responders which went off on >tangents and left me rather frustrated as a result to want to give anyone >that chance again. Ask for free advice, and you get what you pay for. And please, please, use the canonical Usenet posting style with correct attributions. |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Aug 10 12:38AM -0700 On Wednesday, August 9, 2017 at 2:36:09 PM UTC+5:30, kushal bhattacharya wrote: > What is "normal encoding"? The encoding of "normals" of 3D space or in floating point have nothing to do with uuencode format. ok thanks no i meant i am confused about the base 64 encoding format and all the other encoding formats out there is there any signficant difference among them? |
| Kalle Olavi Niemitalo <kon@iki.fi>: Aug 10 11:28AM +0300 > ok thanks no i meant i am confused about the base 64 encoding > format and all the other encoding formats out there is there > any signficant difference among them? Sure, there are differences in * how pleased a programmer will be to hear that they must use this encoding format to interface with your system * how widely the encoding format is supported in libraries for various programming languages * which characters can occur in the encoded text; this affects how likely the data is to get corrupted if processed by programs intended for text, and whether it can be embedded as is in data formats that reserve some characters (like URIs or XML) * how long the encoded text becomes * whether metadata such as file names can be encoded * whether there is a checksum (as in yEnc) * whether the implementation needs division and multiplication operations (as in Ascii85), or just bit shifts and small lookup arrays |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 10 01:49PM On Wed, 2017-08-09, kushal bhattacharya wrote: >> license which permits that. > thanks for the info :) so is there any difference between normal > encoding and the uuencode format? Check Wikipedia, like I did. There's a whole table of different ways to encode binary data as text. Base64 is one of the most common ones, and maybe the one you're thinking of as normal. https://en.wikipedia.org/wiki/Binary-to-text_encoding#Encoding_standards Yes, there are differences. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Ian Collins <ian-news@hotmail.com>: Aug 10 05:39PM +1200 On 08/10/17 10:48 AM, Alf P. Steinbach wrote: > Difficult to get rid of such habit! > Re your prefix `k` for constants: remember, one person's constant is > another's variable, and vice versa. The constness can change in maintenance. They drive me nuts in my current work codebase! We end up having silly philosophical debates about whether a std::unique_ptr variable is should be pWhatsit or just whatsit... -- Ian |
| "Öö Tiib" <ootiib@hot.ee>: Aug 09 11:35PM -0700 On Thursday, 10 August 2017 08:40:12 UTC+3, Ian Collins wrote: > They drive me nuts in my current work codebase! > We end up having silly philosophical debates about whether a > std::unique_ptr variable is should be pWhatsit or just whatsit... Various kinds of such silly bikeshedding are normal in organization. It helps a bit when team acknowledges it as a problem and tries to fight with it but not much. |
| "Ross A. Finlayson" <ross.finlayson@gmail.com>: Aug 09 08:33PM -0700 On Wednesday, August 2, 2017 at 6:55:29 AM UTC-7, Alf P. Steinbach wrote: > Thanks for that feedback! > Cheers!, > - Alf These days Java seems a lot more well read. Though, maybe there's as much C++ written, these days. I almost always find Java well-engineered (the language and the libraries). Now I'm thinking of the program model and the runtime and especially the JVM loading with commands that run Java, here C++ definitely excels in the extended program model for example a process model. It loads so much faster then to the idea of breaking up the commands and otherwise starting the virtual machine each time with then the idea of the "java" server basically running refreshed versions of the environment. (Just as an example of an accommodation for Java that C++ would make "simple".) |
| 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