- "Death to C, ++" - 10 Updates
- Difference between type(type) and type(*)(type) - 3 Updates
- optional va_args argument - 7 Updates
| Jerry Stuckle <jstucklex@attglobal.net>: Jul 19 03:55PM -0400 On 7/19/2017 11:52 AM, jacobnavia wrote: > log(pow(3.4,5.6))/log(3.4) > 5.6 > That means the system is working OK. That didn't answer my question. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Juha Nieminen <nospam@thanks.invalid>: Jul 19 08:20PM > C is readable, C++ is NOT. Clearly you haven't seen any C projects out there. Take something like mplayer, with its thousand-line-long functions with zero comments and completely cryptic logic (not to talk about variable names). |
| "Öö Tiib" <ootiib@hot.ee>: Jul 19 01:26PM -0700 On Wednesday, 19 July 2017 23:21:03 UTC+3, Juha Nieminen wrote: > Take something like mplayer, with its thousand-line-long > functions with zero comments and completely cryptic logic > (not to talk about variable names). ,--[quote] | Besides, the determined Real Programmer can write FORTRAN programs | in any language. '-- http://web.mit.edu/humor/Computers/real.programmers |
| jacobnavia <jacob@jacob.remcomp.fr>: Jul 19 10:51PM +0200 Le 19/07/2017 à 22:20, Juha Nieminen a écrit : > In comp.lang.c++ jacobnavia <jacob@jacob.remcomp.fr> wrote: >> C is readable, C++ is NOT. > Clearly you haven't seen any C projects out there. Yes, I know, I am a novice. I have always been actually. There is always something new to learn for me. > Take something like mplayer, with its thousand-line-long > functions with zero comments and completely cryptic logic > (not to talk about variable names). Yes, but those problems are easy to solve. By the way there is nothing in C that forbids to write comments, just people in a hurry (like many programmers) that do not have the time to comment anything. Software can be difficult to follow, granted, but the complexity of C++ adds several layers of language specific problems. c = foo(pData,42); Is this a macro or a function call? Here C++ shares the lack of distinction between macros and function calls of C. In C, the declarations of pData, foo and c are mostly in the local frame. Or maybe not and you have to hunt for that in the headers, that in any significant project, are always a mess. But in C++ foo could be a method of the current object too. Normally you add an "m_" to the method's name, but not all people follow that. And if you see the 'm_', indicating a method call, you have to figure out where in the class hierarchy a method has been defined with that name. This can no longer be done with vi and grep. Yes, I should put into that computer (an embedded system) a super-duper dev system that does that, but it would overwhelm the micro-sd card with 64GB that I bought for it. Yes, I could send the sources to my mac, and there make an Xcode project to figure out the C++, but that would complexify the dev system, that is running ok with Unix, vi and grep. Worst, the clang c++ compiler behaves differently than the g++ of the arm system Besides, it is fun. I feel that I am really having fun, ignoring all the new stuff and just using vi, make, gcc, and grep. I am writing a JIT compiler for that system: you pass it a buffer of C code, and it will return a buffer full of machine instructions that you can execute on the fly. The C code is generated by a C++ SQL database, that translates each SQL statement into C code, that is compiled and executed on the fly. That is the context: I am trying to compile the database. |
| Siri Cruise <chine.bleu@yahoo.com>: Jul 19 01:55PM -0700 In article <okoeuv$2o5d$1@adenine.netfront.net>, > In comp.lang.c++ jacobnavia <jacob@jacob.remcomp.fr> wrote: > > C is readable, C++ is NOT. > Clearly you haven't seen any C projects out there. I don't know what the problem is, but C++ isn't the answer. In article <oklgjm$foc$1@dont-email.me>, Lynn McGuire <lynnmcguire5@gmail.com> wrote: > But, if one cannot walk the tightrope then one should find something > else to do in life. After all, working on the high wire is not for > everyone. You're not going to improve on C without changing some deeply held ideas about what is 'efficient', like array bound checking and garbage collection. C++ sucks because, besides the rampaging featurism, it tries to do automatic storage collection without garbage collection. It means things like closures cannot be implemented without considerable work by the programmer. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ Free the Amos Yee one. This post / \ Yeah, too bad about your so-called life. Ha-ha. insults Islam. Mohammed |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jul 19 09:10PM > because, besides the rampaging featurism, it tries to do automatic storage > collection without garbage collection. It means things like closures cannot be > implemented without considerable work by the programmer. But C++ already has closures ;p GC is not in fashion any more as both Rust and Swift does not have it. Rust had it, but they dropped it later... There is lot of pressure on Walter (D author) to make D std lib GC free and language to work without it. -- press any key to continue or any other to quit... |
| Chris Ahlstrom <OFeem1987@teleworm.us>: Jul 19 05:25PM -0400 Lynn McGuire wrote this copyrighted missive and expects royalties: > But, if one cannot walk the tightrope then one should find something > else to do in life. After all, working on the high wire is not for > everyone. All languages have a valid domain. -- Q: What do you call a boomerang that doesn't come back? A: A stick. |
| Paavo Helde <myfirstname@osa.pri.ee>: Jul 20 12:41AM +0300 On 19.07.2017 23:51, jacobnavia wrote: > c = foo(pData,42); > Is this a macro or a function call? Here C++ shares the lack of > distinction between macros and function calls of C. In C++ there is about zero need for function macros and they bring increased danger of name clashes, so in proper C++ code foo() is a function, with a very high probability (unless the name is long, ugly and fully capitalized). > add an "m_" to the method's name, but not all people follow that. And if > you see the 'm_', indicating a method call, you have to figure out where > in the class hierarchy a method has been defined with that name. In C++ most functions tend to be members of some class, so the probability that foo() is a class member function is way higher than 50%. It's the free functions that are the exception, and these are often marked specially with the namespace name, e.g. std::lower_bound() or ::ShellExecuteW(). Note however that the fact that a function is a class member does not tell very much without knowing if it is also static or const. > This can no longer be done with vi and grep. Yes, I should put into that > computer (an embedded system) a super-duper dev system that does that, > but it would overwhelm the micro-sd card with 64GB that I bought for it. The feature which I very often use for such code lookup in my IDE is "find in all project files". This is basically just a grep and it finds me all the overloads and overrides of foo. Of course, in order to know which one is called at any point requires some familiarity with the relevant class hierarchies. Admittedly, this is because my IDE is too stupid and its "go to definition" feature does not work correctly half of the time or is just unbearably slow. > Yes, I could send the sources to my mac, and there make an Xcode project > to figure out the C++, but that would complexify the dev system, that is > running ok with Unix, vi and grep. TANSTAAFL. If you want to save on the hardware by using a small embedded system, then you have to pay somewhere else. |
| Ian Collins <ian-news@hotmail.com>: Jul 20 09:57AM +1200 On 07/20/17 08:51 AM, jacobnavia wrote: > programmers) that do not have the time to comment anything. > Software can be difficult to follow, granted, but the complexity of C++ > adds several layers of language specific problems. What I don't get is why you can't recognise that C++ can simplify spaghetti C code. You only have to take a brief look through something like the Linux kernel, which is good well reviewed C, and you will find many cases of almost identical goto ridden code like: struct autogroup *ag = kzalloc(sizeof(*ag), GFP_KERNEL); struct task_group *tg; if (!ag) goto out_fail; tg = sched_create_group(&root_task_group); if (IS_ERR(tg)) goto out_free; Which could be rewritten in a clean, goto free, manner by adding RAII. C + a little bit of C++ is a great way to write cleaner, goto free, code. -- Ian |
| Paavo Helde <myfirstname@osa.pri.ee>: Jul 20 01:55AM +0300 On 19.07.2017 23:55, Siri Cruise wrote: > because, besides the rampaging featurism, it tries to do automatic storage > collection without garbage collection. It means things like closures cannot be > implemented without considerable work by the programmer. What's so special about closures that they would not be able to manage any needed storage automatically, similar to all other C++ features? (Hint: they are not special). And what's so special about garbage collection that one should definitely embrace it? It's just a sloppy fallback mechanism if the language or the programmer is not able to manage the object lifetimes properly. But thanks to RAII C++ is fully capable to manage the object lifetimes properly. |
| Manfred <noname@invalid.add>: Jul 19 08:46PM +0200 On 7/19/2017 5:57 PM, Juha Nieminen wrote: > it gets as a constructor parameter there (if one is given). > I suppose a "function type" simply is a special type that cannot be > instantiated by itself (even though normally types can be). Probably so, anyway my point was more about the fact that Key is a generic data member, while Compare is a predicate, so it would make more sense for map to allow for a function type for it. It doesn't, so it is a bit less trivial than it looks. In fact, with respect to the OP, the following works: > std::map<const char*, int, bool(const char*, const char*)> m2; // error std::map<const char*, int, std::function<bool(const char*, const char*)>> m2; // works It looks that the type(type) syntax, which was introduced in C++11 as /call signature/ (20.14.1) to identify a function type, has not been deployed completely and uniformly throughout the language where a function object type is expected - thus the need for the std::function wrapper. |
| "Öö Tiib" <ootiib@hot.ee>: Jul 19 12:56PM -0700 On Wednesday, 19 July 2017 21:47:05 UTC+3, Manfred wrote: > Probably so, anyway my point was more about the fact that Key is a > generic data member, while Compare is a predicate, so it would make more > sense for map to allow for a function type for it. Function is not object and so can not be copied. The std::map is very desired to be assignable so how it makes sense? > deployed completely and uniformly throughout the language where a > function object type is expected - thus the need for the std::function > wrapper. I don't think so. Function object is object that can be called as if it is a function. Therefore function is not function object since it is not an object. Pointer to function however (if actually made to point at a function) is function object since it is object and can be called like a function. The confusion here can be similar as with array and the pointer to its first element. Every time we try to use a function to something it slyly tries to convert to function pointer. About like array tries to convert to pointer of its first element on first chance. #include <iostream> using Function = void(int);// function type Function function; // declaration of function with external linkage void function(int i) // definition of that function { std::cout << i << std::endl; } int main() { Function x; // again a declaration of function with external linkage // x = function; <- no way! bonus points for obfuscation go to gcc :D Function* function_pointer = nullptr; // function pointer is object function_pointer = function; // function converted to pointer void (*other)(int); // other = function_pointer; // assignable to other object other(42); // and callable like function } |
| Manfred <noname@invalid.add>: Jul 19 11:00PM +0200 On 7/19/2017 9:56 PM, Öö Tiib wrote: >> sense for map to allow for a function type for it. > Function is not object and so can not be copied. The std::map is very > desired to be assignable so how it makes sense? In the same way as std::function<> is. > I don't think so. Function object is object that can be called as if it > is a function. Therefore function is not function object since it is not > an object. You are right, according to how the language works, thanks! However, if you think in terms of pure metaprogramming (which Bjarne likes a lot), handling functions as objects is exactly why features like std::function<> have been introduced. So, the way I see it, <functional> made it possible to use functions as if they were objects, but this is not quite how the rest of the language works. This is what I meant above for "non uniform" deployment. Beware, it may very well be that this would be too much obfuscation (see below), my remark here is only about theoretical semantics. > first element. Every time we try to use a function to something it > slyly tries to convert to function pointer. About like array tries to > convert to pointer of its first element on first chance. Probably so, or (like Alf also pointed out) similar to references, that must be initialized, and cannot be assigned (and in fact Bjarne says that references are not objects). > { > Function x; // again a declaration of function with external linkage > // x = function; <- no way! bonus points for obfuscation go to gcc :D Thanks again for the good example (and for the error message above :) |
| jacobnavia <jacob@jacob.remcomp.fr>: Jul 19 08:03PM +0200 This code void SetErrorN(ErrorCode ec, int mc, const char* emf = NULL, va_list args = NULL); was compiling OK until 2015 or so. It still compiles OK in my macintosh using clang. But in an arm 64 architecture it gives me EventLog.h:16:61: error: could not convert '0l' from 'long int' to 'va_list {aka __va_list}' How could I fix that? There are MANY calls to those functions all over the place. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jul 19 06:06PM > EventLog.h:16:61: error: could not convert '0l' from 'long int' to > 'va_list {aka __va_list}' > How could I fix that? Try with: args = va_list()? > There are MANY calls to those functions all over the place. Only one definition I hope ;) -- press any key to continue or any other to quit... |
| jacobnavia <jacob@jacob.remcomp.fr>: Jul 19 08:14PM +0200 Le 19/07/2017 à 20:06, Melzzzzz a écrit : > Try with: args = va_list()? >> There are MANY calls to those functions all over the place. > Only one definition I hope ;) Thanks, I did not know that the constructor would yield the equivalent of an empty list. |
| scott@slp53.sl.home (Scott Lurndal): Jul 19 07:00PM >This code >void SetErrorN(ErrorCode ec, int mc, > const char* emf = NULL, va_list args = NULL); It is not legal to set a default argument value for va_list, which is an opaque implementation defined type. |
| "Öö Tiib" <ootiib@hot.ee>: Jul 19 01:09PM -0700 On Wednesday, 19 July 2017 22:00:31 UTC+3, Scott Lurndal wrote: > > const char* emf = NULL, va_list args = NULL); > It is not legal to set a default argument value for va_list, > which is an opaque implementation defined type. Yes initializing with NULL is not quaranteed to work but not because va_list is opaque. It is required to be complete object type that must be default-constructible so va_list() must work as default argument. |
| jacobnavia <jacob@jacob.remcomp.fr>: Jul 19 10:24PM +0200 Le 19/07/2017 à 21:00, Scott Lurndal a écrit : >> const char* emf = NULL, va_list args = NULL); > It is not legal to set a default argument value for va_list, > which is an opaque implementation defined type. It may be not legal now, but it compiled without any problem until 2016 for at least a dozen of years. Thanks to Mr Melzzzz I know now that the NULL argument must be replaced by va-list(), i.e. a call to some constructor of a default value. This is provoked by a change in the architecture: arm64 has a LOT of registers and almost never the stack is used anymore for that purpose. How it happens now when that default argument is passed anyway explicitely is not clear. I suppose the default assignment is discarded and the variable has the actually passed in value. Luckily I haven't seen any comparisons with NULL in that code for that "args" variable. I suppose that now any comparison (test of) NULL will not work, so that the comparisons should be done with the default value. But the programmer has not any access to the default value when an actual value is passed. NULL was a practical default value. Maybe there is an overload of va_list with NULL comparisons? Software is made of these ever deepening problems... |
| Ian Collins <ian-news@hotmail.com>: Jul 20 08:44AM +1200 On 07/20/17 08:24 AM, jacobnavia wrote: >> which is an opaque implementation defined type. > It may be not legal now, but it compiled without any problem until 2016 > for at least a dozen of years. By luck! > Thanks to Mr Melzzzz I know now that the NULL argument must be replaced > by va-list(), i.e. a call to some constructor of a default value. As Öö Tiib pointed out above, va_list is a default constructable complete object type. "va-list()" creates a default constructed va_list. > How it happens now when that default argument is passed anyway > explicitely is not clear. I suppose the default assignment is discarded > and the variable has the actually passed in value. The args parameter *is* passed by value! > Luckily I haven't seen any comparisons with NULL in that code for that > "args" variable. Probably because the "emf" parameter is a format string. No format string, no args. I guess you could hit a snag if the there was a simple string and no args such as "fred"... > programmer has not any access to the default value when an actual value > is passed. NULL was a practical default value. Maybe there is an > overload of va_list with NULL comparisons? Pass a va_list* instead? Or use a variadic template? -- Ian |
| 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