- "Jonathan Blow: "C++ is a weird mess"" - 8 Updates
- Some C++14 code - 2 Updates
- Fizz Buzz - 12 Updates
- newbie: sqlite3 programm - 2 Updates
| BGB <cr88192@hotmail.com>: Jul 26 02:07PM -0500 >> Compiler binary is currently approx 2.5 MB. >> Compiler can also be itself recompiled within a few seconds. > That sounds like quite a substantial product. My 'C' compiler is about 20Kloc (of original source, as it's not written in C; expressed in C it's only a bit longer). As noted, it is tiny vs GCC or Clang, which are generally in the MLOC range. Also, it can be rebuilt from source much faster (helped along some also because it uses a "unity build" strategy). > That targets only x64, and outputs x64 asm source. (My own format and run through my own assembler, which assembles/links multiple .asm files to .exe at some 2-3Mlps. Perhaps about 9Kloc for that.) > Compilation speed on a PC, .c to .asm, is typically 0.6Mlps. (Plus .asm preocessing, but that stage could be incorporated into the main compiler without probably affecting that 0.6Mlps much.) In my case, ASM preprocessing uses the main C preprocessor, but is forwarded through the other stages as a blob. Granted, the backend needs to provide an ASM parser for this. Some things which are currently part of the per-target backends could be split off into a shared area, as there is a lot of stuff in there that doesn't really change much from one ISA to another. > However, it only processes one C file per compiler invocation, so multi-module projects are slow. Also, it has so many other problems that I now just call it a C dialect compiler (suitable for the intermediate C I sometimes generate). While it can compile and run certain open-source programs (eg. Lua), making it work for arbitrary C code involves going down a rabbit-hole I'm longer interested in exploring. Yeah, mine is given all the code at the same time. It could in theory be used to process one C file at a time, emitting each as a RIL file, and then invoked afterwards as a "linker", but this would probably make everything a lot slower. Also using it this way is basically untested. > I'm concentrating at the minute on an alternative low-level language, visually different from C, with a module system and designed for whole-program compilation. This needs more passes to compile, and I'm only getting up to 0.4Mlps, but there are no C-like headers to repeatedly process so all of that throughput is usable. My idea for a "C alternative" would be different from C, but not too drastically. It would also drop use of header files, and instead use a system more like the one used in C#, though in some areas, the syntax more follows after Java and AS3. > Neither product optimises code, which looks pretty terrible when you look at the output. But on my apps, the difference between this code, and gcc-O3, is fairly narrow; gcc might be 20-50% faster. Mine is "passable" in terms of optimizations. It doesn't do anything particularly fancy, but manages to keep variables in registers for the most part (so, mostly passable code generation). Comparably, x86 is a much more level playing field though. In my CPU ISA designs, it is more a case that "naive" code consisting mostly of memory loads/stores or similar would have rather dismal performance. This is mostly because the CPU core itself needs to be simple (contrast with x86 cores which do large amounts of "heavy lifting" internally, and are very expensive if compared with a simpler RISC-style core). This is admittedly part of the motivation for why it has 32 GPRs. Having this many GPRs is itself pretty expensive, but they pay off well in functions with a lot of register pressure. Though, there are pros/cons, and the compiler decides via heuristics whether each function should enable use of all 32 GPRs, or only use the first 16 GPRs. Though, my C compiler still falls short of what I can do with hand-written ASM. > (Which is still worthwhile enough that I am reinstating a C target for this compiler - which will always be a single whole-project C source file - just so I can pass it through gcc-O3 and step up those lps figures a couple of notches. > Not that it needs them on the PC: all my 20-25Kloc multi-module programs each build from source to .exe, including asm processing, in the time it takes me to press Enter. But it'll be useful on a slower machine.) OK. >> the PE/COFF format is based on the PE32+ format, but lacks anything in >> the MZ stub. > PE/COFF formats are horrible (trust MS to overcomplicate matters). I used to generate COFF for object files, but since I generated PE directly, I hardly ever bother. (My PEs don't support DLLs so I might need COFF still which have to be passed through a conventional linker.) However I find my PEs attract unwelcome attention from AV software. The PE/COFF header is pretty nasty, granted. However, some of the complexity here is mostly superficial (doesn't actually effect the loader all that much). However, comparing ELF/SO linkage with PE/COFF DLL linkage, PE/COFF is a little simpler to deal with (once one accounts for what goes into making "ld.so" able to do its thing). In the simple case, there isn't really all that much of a difference between them (it is basically the same process but with different headers). Had considered my own binary format, but it didn't seem that notable so didn't do so yet. Some of my ideas went in the direction of vaguely resembling an LZ compressed Mach-O like format. Loading a binary would effectively involve stream decompression into the target memory. After unpacking the main sections, it might reach an optional "reloc" section (for binaries which support rebasing), and some sections related to "DLL" loading (these parts would be absent for simple statically-linked binaries). Note that shared copy-on-write mappings could exist for "DLL's" in this system, but would be done differently than the "mmap the SO file" strategy used by Linux and friends. > Anyway, in response to the query, it is possible to streamline compilation of a C-like language to it can be done quickly if you don't care about code-speed. > C itself doesn't make things easy with its macro language and its textual include files which must be reprocessed not only in different TU but within the same one, unless you use guards or things like #pragma once, all very messy. > But Tiny C shows it can be done. Mine does try to be "decent" with code speed. In its present form, it is more because "do my own compiler" looked like less pain than trying to do a new experimental arch in GCC. GCC seems to spread its target-specific stuff nearly everywhere, and is a fairly large and complicated codebase, which isn't something I really wanted to deal with. And, for Clang/LLVM, well, it tending to take about an hour to be recompiled and taking absurd amounts to RAM in the process doesn't really help matters. > As for C++ though, I can only say it's making a rod for its own back. Yeah. I am not personally willing to face trying to write an a C++ compiler at the moment... |
| bart4858@gmail.com: Jul 26 12:28PM -0700 On Thursday, 26 July 2018 14:10:43 UTC+1, Thiago Adams wrote: > I would like to have a group to talk about compilers > and language design and implementation. What do you think? > Why not create a google group for that? There's a group called comp.lang.misc which has been used for that purpose. Usually very quiet but if you post something it will likely get replies. -- bart |
| Ian Collins <ian-news@hotmail.com>: Jul 27 07:48AM +1200 >> inline function bodies. > If someone is so lazy they need an editor to do something as basic and quick > as indentation then perhaps development isn't the right job for them. It's not laziness, it's an editor changing what I write! -- Ian. |
| jacobnavia <jacob@jacob.remcomp.fr>: Jul 26 09:51PM +0200 Le 26/07/2018 à 15:02, Paavo Helde a écrit : >> completely >> messed up, you can quickly indent it by simply pressing tab on each line. > Agreed. No, I do not agree. The problem is that for doing that you have to spend precious BM (brain memory). You have to know the trick, and recall it when you use emacs, to be able to do something very simple; you just indent as you want by writing tabs or spaces. Instead of learning for each editor which trick does it, I just indent my text as I want. Very simple but 100% effective, and uses zero BM. I do not have to remember anything. Editing your text is a very basic functionality of your IDE, the original topic of this thread. Microsoft one is well done, because many people are working on it, and Microsoft finances that development. As an IDE, emacs falls quite short. One of the best things of Microsoft IDE is its debugger, of course. Very solid debugger. I used that debugger to debug the debugger I wrote for windows. It will catch any crash in your debugger and doesn't get confused. Eventually, my debugger got to the point where I could debug it with itself. Of course, my windowed debugger under windows wasn't very portable, and the daunting task of translating all windows API to GTK... I started using gdb when I moved to linux. Gdb can also debug itself, but as a part of an IDE it is quite awfull really. The many commands that you have to remember... pages and pages of documentation... It does some simple stuff, for instance if you start the name of an identifier it will fill it when you press tab, if there is one in the current scope that starts with those letters. A text mode application can't display much information though. Windows are much better for display info in a debugger. I built several window displays in my debugger, with a one called "auto". I scanned the line before the current one, the current line and the next, extracted all identifiers, looked which ones the debugger has info about, and displayed their values automatically at each stop. It is quite effective and simple that method. I do not know if emacs has an index, i.e. if it builds automatically the list of functions in a file. My IDE did it automatically, when you loaded a source file. The editor allowed you to move entire functions, to place them somewhere else. Everything was written in C and (of course) in assembly language. Actually, my IDE was just an aid to generate assembly from C source. Pressing F9 it will call the included compiler, then call the included linker. Then you would run or debug the executable. The compiler is so fast, that scans regularly the source code and reports any syntax errors you do when you write code >> The major drawback of emacs is that configuring the indentation is >> complicated, as there are no easy menus with mouse-clickable options. It is not "complicated" but you have to learn too much computer trivia to be able to use it. Point and click interfaces do not use brain memory, and that's why they are easier to use. >> It also doesn't always get the indentation of certain types of code >> as I like, and it's difficult to configure it to do so. (It's possible, >> but usually requires you to understand elisp.) Even more brain memory and there you have for a whole "language". Computer languages are simple lisp is: (function arguments) for instance (+ 2 3) is 2+3; in other languages like C++ Can elisp drive gdb? Gdb can be driven by the text commands interface. Apparently has no API. You have to read the results of gdb by parsing text output... Of course, since the source code of gdb is open, you can figure out what the point in that gdb source code is getting executed for doing that command. Then, you can call it directly. The same for output: you figure out what is printing those lines, and read the result directly. But that is awfully complicated. I started writing a linux debugger some ages ago, using the ptrace interface, that is quite good, as the windows one. You can put breakpoints, be notified about them, etc. |
| Paavo Helde <myfirstname@osa.pri.ee>: Jul 26 11:11PM +0300 On 26.07.2018 22:51, jacobnavia wrote: > The problem is that for doing that you have to spend precious BM (brain > memory). You have to know the trick, and recall it when you use emacs, > to be able to do something very simple; To be honest, to use emacs productively you need to know tens of keyboard shortcuts anyway which are all harder to remember than the mundane TAB. What's more, to enter a literal tab for manual indentation is much harder, I have not managed to memorize the command in ca 20 years of casual exposure (I now looked it up, it is Ctrl+Q TAB). |
| legalize+jeeves@mail.xmission.com (Richard): Jul 26 08:22PM [Please do not mail me a copy of your followup] Ian Collins <ian-news@hotmail.com> spake the secret code >don't like Visual Studio's indentation, but it has excellent code >completion which I don't really use. NetBeans has near infinite code >layout configuration, but sluggish code completion. If you find clang-format acceptable for your indentation rules, then VS 2017 has built-in support for clang-format (you can even specify the particular clang-format executable to use) and it will then format according to clang-format's configuration. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| legalize+jeeves@mail.xmission.com (Richard): Jul 26 08:25PM [Please do not mail me a copy of your followup] jacob@jacob.remcomp.fr spake the secret code >Gdb can also debug itself, but as a part of an IDE it is quite awfull >really. The many commands that you have to remember... pages and pages >of documentation... You can debug linux applications using the VS debugger. It will connect to the remote gdb instance and show everything in the VS IDE. *poof* No reason to learn all the cryptic gdb commands anymore. (gdb CLI is basically unchanged for 30 years.) -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| woodbrian77@gmail.com: Jul 26 03:16PM -0700 On Thursday, July 26, 2018 at 3:25:56 PM UTC-5, Richard wrote: > *poof* > No reason to learn all the cryptic gdb commands anymore. (gdb CLI is > basically unchanged for 30 years.) Or you can learn the few commands that you need. It's not very hard and if you one day find yourself on a system where you don't have VS, you'll still be able to do your job. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| woodbrian77@gmail.com: Jul 26 08:26AM -0700 On Thursday, July 26, 2018 at 12:58:59 AM UTC-5, Juha Nieminen wrote: Brian Ebenezer Enterprises - Enjoying programming again. http://webEbenezer.net |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 26 09:09PM +0100 On 18/07/2018 08:53, Juha Nieminen wrote: > The advantage of using std::list is that the code becomes simpler, > and thus the likelihood of bugs is smaller. > Know your tools, and use them efficiently. Another reason (which you may have implied also) to use std::list over std::vector is that std::list elements have identity (their address never changes) whilst std::vector elements do not; object identity is quite important sometimes. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 26 10:29AM -0400 On 7/26/2018 9:29 AM, David Brown wrote: > resort to comments when necessary (but don't skimp on them if they /are/ > necessary). Extra comments have a tendency to lose synchronisation when > the source code changes - information held in the source itself does not. That's one viewpoint. It's not the only one. And it's good practice to err on the side of over-documenting if the documentation is also clear and even obvious to some, because not everybody will be thinking the way you were, or you do, when they read that. The little bit of extra prompting might kick their brain cells into gear and get them from where they are to where they need to be. > says you need big sections of doxygen commenting (or any commenting, for > that matter) for every little function or bit of code, so that you can't > find the real code in all the commentary. Yes. Yours is one viewpoint. I've also worked with/for people who like to see documentation over code, because then even managers can follow along with what it's doing. Chocolate, vanilla and strawberry flavored ice cream. They all exist for a reason. Not everybody likes your chocolate, David. A lot of people do. And probably most people like it from time to time. But, many people prefer vanilla, strawberry, or other, or if they're like me and Captain Janeway, coffee-flavored ice cream (she's also from Indiana you know, from a town about an hour south of where I live). -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 26 10:37AM -0400 On 7/26/2018 10:29 AM, Rick C. Hodgin wrote: > the way you were, or you do, when they read that. The little bit of > extra prompting might kick their brain cells into gear and get them > from where they are to where they need to be. I'd also like to say that while I've never seen this before, and I don't know why it doesn't exist, but I would like to see a debugger that has the ability to single-step through comments. I don't always want to step through code. I'd like to step through things like this: // Open the record // Is it valid? // No, report error Three lines of stepping, rather than this: // Open the record r = open_record(...); // Is it valid? if (r->isValid && r->data != NULL) { // No, report error err = create_error_report(...); log_error(err); if (guiState->isUiActive) present_error(err); delete_error(err); return; } // We're good In many cases, I don't care about the details of what I'm debugging because that code is working and I just want to get through it, so I'd like to be able to switch between single-step mode, between the comments, and between the actual code, and also between the assembly underlying. This is the concept behind my CFSCA concept (Comments, Flowchart, Source Code, Assembly) that I incorporated into my Debi Debugger for my Exodus operating system: View in VLC if you can't view the video: http://www.visual-freepro.org/videos/2014_02_13__exodus_debi_debugger.ogv -- Rick C. Hodgin |
| David Brown <david.brown@hesbynett.no>: Jul 26 04:51PM +0200 On 26/07/18 16:29, Rick C. Hodgin wrote: > the way you were, or you do, when they read that. The little bit of > extra prompting might kick their brain cells into gear and get them > from where they are to where they need to be. That is a view that /sounds/ right - after all, if some documentation or commenting is good, then surely more is better? However, the reality is different. Documents and comments need to be written and maintained - but they don't contribute directly to the working of the code. So their maintenance is invariably given lower priority than the code, and they quickly become something to fix when you have time, rather than an integral part of development. They get more and more separated from the reality of the code, and become confusing, outdated, or even completely wrong. At this point they are highly counter-productive. Compare these two code snippets for scaling an analogue measurement from a weighing system: // Convert raw analogue input value into a weight measurement // The reference weight is 5 kg, and it gives a reading of 4 volts. double scale(double x) { return x * 1.25; } vs. double adc_to_weight_in_kg(double raw) { const double referenceWeight = 5.0; const double referenceReading = 4.0; return x * referenceWeight / referenceReading; } What happens to the code when a more accurate check of the reference weight gives 4.02 volts, found just before the system goes live? The code gets changed to: // Convert raw analogue input value into a weight measurement // The reference weight is 5 kg, and it gives a reading of 4 volts. double scale(double x) { return x * 1.243781095; } vs. double adc_to_weight_in_kg(double raw) { const double referenceWeight = 5.0; const double referenceReading = 4.02; return x * referenceWeight / referenceReading; } Which do you prefer now - the one with the data in the code, or the one with the comments? You /could/ argue that you can have the data and names in the code, /and/ comments. But then your final version would not be much better: // Convert raw analogue input value into a weight measurement // The reference weight is 5 kg, and it gives a reading of 4 volts. double adc_to_weight_in_kg(double raw) { const double referenceWeight = 5.0; const double referenceReading = 4.02; return x * referenceWeight / referenceReading; } Having /no/ comments is clearer, safer, and easier to maintain than having the comments. Of course, the correct balance between code and comments (or other documentation) is going to vary significantly depending on the project, its lifetime, its complexity, the development team, and many other factors. I am not giving a "one size fits all" answer here - I am just suggesting that it is something to think about, and comments are not necessarily a helpful thing. (No comments, /and/ poor choice of names and no indication of what is going on is also a very bad idea - but I think everyone agrees on that!) > Yes. Yours is one viewpoint. I've also worked with/for people who > like to see documentation over code, because then even managers can > follow along with what it's doing. I am not arguing against comments or documentation - I am arguing against /unnecessary/ comments and documentation. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 26 11:04AM -0400 On 7/26/2018 10:51 AM, David Brown wrote: > [snip] I'm glad it works for you, David! (and those it works for) We each need those things which make us do and be better in the things we do. I'm happy for you, that you've found this solution which is what you need. I encourage you toward those ends. Be blessed. -- Rick C. Hodgin |
| David Brown <david.brown@hesbynett.no>: Jul 26 05:14PM +0200 On 26/07/18 16:37, Rick C. Hodgin wrote: > return; > } > // We're good How about stepping through the code: r = open_record(...); if (!r->isValid()) { report_error(); return; } Three things to step through, with as much information as the comments were giving. And unlike your mix of code and comment, it actually does what it says it should. I fully realise that the error in your code above is just because it is quickly typed sample code in a Usenet post, not real code. But it is still an excellent demonstration of the problem. Your comments say "Is it valid? No, report error", but the code is "Is it valid? Yes, report error". > I'd like to be able to switch between single-step mode, between the > comments, and between the actual code, and also between the assembly > underlying. Split your code into functions, and use "Step over", "Function step", "Call step", or whatever term your debugger uses to run a complete function in one step. That has been a standard debugging technique since I first used a proper debugger some 25 years ago. > my Exodus operating system: > View in VLC if you can't view the video: > http://www.visual-freepro.org/videos/2014_02_13__exodus_debi_debugger.ogv (You know I am not going to be looking at that video. I am sure you are happy with the tools you are making for yourself, but they are not relevant to me nor to C++. I am happy to discuss comments in Usenet posts, but not to go chasing videos. I know you like videos as a medium for this sort of thing, but I do not.) |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 26 11:17AM -0400 On 7/26/2018 11:14 AM, David Brown wrote: > [snip] I offered up my idea. If it's not for you then don't incorporate it into your debugger. Here are some other ones I've had: http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/ideas/debugger.txt If they're not for you either, don't incorporate them into your debugger. ----- Be blessed in the things you do, David. I wish you the best. -- Rick C. Hodgin |
| David Brown <david.brown@hesbynett.no>: Jul 26 06:23PM +0200 On 26/07/18 17:17, Rick C. Hodgin wrote: > http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/ideas/debugger.txt > If they're not for you either, don't incorporate them into your > debugger. I am not writing a debugger - I am just telling you how to get the effect you are describing using existing tools. |
| David Brown <david.brown@hesbynett.no>: Jul 26 06:34PM +0200 On 26/07/18 17:04, Rick C. Hodgin wrote: > We each need those things which make us do and be better in the > things we do. I'm happy for you, that you've found this solution > which is what you need. I encourage you toward those ends. I am not talking about a personal preference like flavours of ice cream. Imagine a line with development practices like "write clear code" and "test your code" on the far left - things that are considered standard practice for any serious programmer. And on the far right, you have things like "use camelCase" or "use underscores" - things that are purely a stylistic preference. Avoiding unnecessary comments and preferring to write things in code rather than comments is a good way to the left on that line. It is perhaps similar to "indent consistently" or "break your code into manageable pieces". It is the kind of thing that most serious, experienced programmers will agree on, regardless of language. Exactly how much documentation or commentary is necessary or appropriate will vary tremendously depending on the project, the team, the requirements, the code complexity, etc. This is clearly something that /you/ should adopt, as demonstrated accidentally by your example for debugging code. (Please don't take this as personal criticism - these recommendations are for everyone who programs.) |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 26 12:35PM -0400 On 7/26/2018 12:23 PM, David Brown wrote: >> debugger. > I am not writing a debugger - I am just telling you how to get the effect you > are describing using existing tools. Ah... Then it shouldn't affect you very much because you have a system that works well for you, and I'm glad about that. I like when people have thing which prop them up in this world. We all need things like that. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 26 12:38PM -0400 On 7/26/2018 12:34 PM, David Brown wrote: >> things we do. I'm happy for you, that you've found this solution >> which is what you need. I encourage you toward those ends. > I am not talking about a personal preference like flavours of ice cream. Oh... My mistake. Please forgive my ignorance. -- Rick C. Hodgin |
| David Brown <david.brown@hesbynett.no>: Jul 26 07:47PM +0200 On 26/07/18 18:38, Rick C. Hodgin wrote: >> I am not talking about a personal preference like flavours of ice cream. > Oh... > My mistake. Please forgive my ignorance. No problem. But I'd suggest you re-read some my posts in this thread, and see if it changes your mind about what I've been saying. I suspect you will either see the benefit in what I have been saying and learn from it, or find that you misunderstood what I wrote (maybe I wasn't clear) and agree with it all along. However, if you still think it is a reasonable choice to use comments instead of writing clear code with good names, and are happy to have your comments say one thing and the code say something significantly different, or if you work for the department of redundancy department, then fair enough. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 26 02:08PM -0400 On 7/26/2018 1:47 PM, David Brown wrote: > No problem. But I'd suggest you re-read some my posts in this thread... You really don't get it do you, David? People are complex. Applications of the things that exist are nuanced. There's more than one solution to nearly everything that exists, and here's more than one time things will be appropriate or not. There's some times things will have some value, and other times they will not. I agree with "your" points in some areas, but not all. And on the whole, I disagree with you on almost everything related to software development. Where we do overlap it's from my own personal experience in things and not from your teaching, as there are some things which are fundamental and they exist regardless of anyone's point of view. This disparity between us in beliefs is long-established between us over years, and I'm content with that. I'm also content to be where I am and I offer up the things I do to help other people with those things I have interest or inspiration in. It's my offering unto God first, people second, and there's not one soul anywhere under any obligation to take the things I offer and use them ... but I give them over to people so they can use them if they choose to do so. -- Rick C. Hodgin |
| tokauf@gmail.com: Jul 26 07:39AM -0700 Hi there, here is my prog: #include <iostream> using std::cout; #include <string> using std::string; #include <stdlib.h> #include <sqlite3.h> static int callback(void *NotUsed, int argc, char **argv, char **azColName) { int i; for(i = 0; i<argc; i++) { printf("%s = %s\n", azColName[i], argv[i] ? argv[i] : "NULL"); } cout << "\n"; return EXIT_SUCCESS; } void openDb(const string &fn, sqlite3 *db) { // Open database int rc = sqlite3_open(fn.c_str(), &db); // ??? if( rc ) { fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db)); exit(EXIT_FAILURE); } else { fprintf(stderr, "Opened database successfully\n"); } } //--- main -------------------------------------------------------------------- int main(int argc, char* argv[]) { sqlite3 *db; // ??? char *zErrMsg = 0; int rc; const char *sql; openDb("tester.db", db); // ??? // Create SQL statement sql = "SELECT * FROM COMPANY;"; // Execute SQL statement rc = sqlite3_exec(db, sql, callback, 0, &zErrMsg); if( rc != SQLITE_OK ){ fprintf(stderr, "SQL error: %s\n", zErrMsg); sqlite3_free(zErrMsg); } else { fprintf(stdout, "Records created successfully\n"); } sqlite3_close(db); return EXIT_SUCCESS; } -------------------------------------------------- It does not work correctly. When I compile my prog there is a warning: sqlite3.cpp: In function 'int main(int, char**)': sqlite3.cpp:43:25: warning: 'db' is used uninitialized in this function [-Wuninitialized] openDb("tester.db", db); // ??? I have comment out critical parts with // ??? Can anyone help me please? Thanx a lot. Here is the result when I call the prog: Opened database successfully SQL error: (null) o-o Thomas |
| Barry Schwarz <schwarzb@dqel.com>: Jul 26 10:02AM -0700 >Here is the result when I call the prog: >Opened database successfully >SQL error: (null) You define db in main but do not set its value (initialization or assignment). Since db is passed to openDb by value, the compiler correctly notifies you that this is invalid. This indeterminate value is then copied to the local variable db in openDb. You pass the address of this local variable to sqlite3_open which will replace the current value by dereferencing this address. The local variable db now contains the result of sqlite3_open. Unfortunately, this local variable is destroyed when openDb returns. The end result is the variable db in main still has the original indeterminate value (which happened to be NULL on your system). You apparently wanted openDb to change the value of db in main. The way to do this is: Call openDb with &db as the second argument. (Since you are not passing the value of db, the fact that its value has not been set is irrelevant. The address of db is a valid address regardless of the value it points to.) Change the signature of openDb to receive sqlite** instead of sqlite*. (Since db in main has type sqlite*, &db has type sqlite**.) Change the call to sqlite3_open from &db to db. (db in openDb has the correct type, sqlite**. Its value is the address of db in main. sqlite3_open will dereference the value it receives and update the variable pointed to, which happens to be db in main. At this point, db in main will contain the value (address) you need it to.) It would be easier to understand these concepts if you used different names for the variable in main and the parameter in openDb. Using db for both variables led to wrong conclusion that when sqlite3_open updated db in openDb it would somehow affect the value of db in main. -- Remove del for email |
| 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