Yea the old "put all #defines in a .h file" theory is one of my pet peeves. I've worked on quite a few projects where things were done that way even if the foo.h was purely local/internal and was only used by foo.c. To top it off, you put foo.h in a _separate_ directory with all the .h files so they don't get mixed up with the .c files (I never understood the reasoning behind that either).
--
Grant Edwards grante Yow! If elected, Zippy
at pledges to each and every
...because I'll have two versions of code, albeit temporarily, but it is an easy way to disappear up ones own exhaust pipe. Close the live one and click save changes and then close the reference one and click save changes without thinking and then you've lost all your edits.
Why? The editor should be able to handle multiple views into the same source file without building multiple copies. IIRC Brief could do this decades ago and I had thought that was now a common feature for a programming editor. OTOH, I haven't seen a Windows based editor that could split the edit window properly so maybe that capability has been lost as well. Hmm, just tried Eclipse and it couldn't, definitely a black mark against it. I'll have to check my main editor, I haven't had reason to use this feature for a little while.
Yes it could. And so could emacs and any other serious editor I can think of.
It better be, it's probably one of the most basic features that's required of a programming editor.
eclipse can't show you two disjoint regions of a file? In my book that makes it completely useless for doing real work. Very, very few of the source files I edit will fit entirely on screen all at once.
Maybe he needs to use a real editor. ;)
--
Grant Edwards grante Yow! I know things about
at TROY DONAHUE that can't
The same file is open twice. One for each window. Unless the editor you're thinking of has two views of the same file and changes made in one window appear in the other.
Colloquialism meaning to become confused.
The one you are editting is live, the second copy is opened for reference to the aforementioned macros.
I think that may have originated with library writers where the .h files are in a inc or include subdirectory that gets shipped with the .lib. Somehow that led other programmers to think that .h files need to have their own directory.
I just did a quick check on an XML editor component. Given Eclipse's structure it's entirely possible that the C editor works properly. Obviously something to check before using it seriously though.
I'm using an Eclipse based environment with CDT and it has "Window|New Editor" which opens up a second window of the same file. Then you can rearrange the window how you want (tiled horizontal or whatever).
Not as quick as brief-split-window or the the split bar in VS but gets the job done.
Good point. To extend it a bit, memcpy() really is the important piece of this puzzle, not the array or how to create an interface to its length.
So the key to solving it is to get rid of memcpy(), and you can: wrap the array in a struct and use struct assignment instead of memcpy() to copy it around.
Yes, there is bounds checking going on before the memcpy and that's where the sizeof really shows up. I didn't want to complicate things in the post but you are absolutely right. Typically I have a numToCopy go into memcpy (or strncpy).
Even CodeWright gets this right. Of course, CodeWright gets a lot of things right. Too bad Borland's trying to kill it...
If you just want to split the current window into two (or 4) independently-scrollable panes, there are splitter bars at the top of the vertical, and to the left of the horizontal, scrollbars. If you want independent (overlapable, if that's a word) windows, you simply open the same file in a new window. Changes in one widow are reflected instantaeously in the other(s) (or as close to instantaeous as Windoze gets).
You got to view both windows at the same time? How did you do that? I used Window|new and got a new tab at the top. Couldn't work out how to tile them.
The other thing that would be useful is a method of easily changing the colour scheme from white background to black (with appropriate font colours) - sometimes easier on my eyes. I don't think you you do this easily with eclipse though.
C makes it too easy to shoot yourself in the foot unless you have your own rules. If your rules for global data ensure that every piece of global data has a full "extern" declaration, including the size of the array, in a header file, and that one and only one C file defines it using the same size (and #including the same header file), then no mistakes about the size can be made.
Again, C is too flexible. There is a difference between an array and a pointer. Just because the underlying implementation makes no distinction, does not mean the source code should be equally loose. Thus in well structured code, no one would convert an array to a pointer (a pointer to the first element in arr is not "arr", but "&arr[0]").
If you are considering the array as a block of memory, then sizeof(array) is the clearest method. If you are considering the number of elements in the array, then use SIZE_ARR. If your code is written with a reasonable set of code style rules, then both will work fine.
Add to that, every function prototype has to have a large comment block to explain that the function "foobar" foos the bar.
Every exported global item, be it function, data, type, macro, or whatever, should be prototyped *fully* in a module's header. Everything that is not to be accessed globally should be kept in the implementation C file of the module, where all the non-global functions and data are defined as "static" and therefore don't need separate prototype declarations.
Yes, looks like the both update "live". Only glitch seems to be that when I save one modified copy the othe one still looks like it's been modified (*).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.