C Coding style question

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
 Click to see the full signature
Reply to
Grant Edwards
Loading thread data ...

hPeeve List += Every function has a prototype, which must be in the .h file.

--
 
 
 Click to see the full signature
Reply to
CBFalconer

...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.

Reply to
Tom Lucas

What?

I've no clue what you're talking about.

What "live one" and "reference one"???

What sort of brain-damaged editor are you using that it can't show you two different spots in the same file?

--
Grant Edwards                   grante             Yow!  Two with FLUFFO,
                                  at               hold th' BEETS...side of
 Click to see the full signature
Reply to
Grant Edwards

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.

Maybe your files are just too large? :)

Robert

Reply to
Robert Adsett

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
 Click to see the full signature
Reply to
Grant Edwards

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.

What would you suggest?

Reply to
Tom Lucas

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.

Andrew

Reply to
andrew queisser

Of course. Every programming Editor I've used for the past 20 years has been able to do that.

Brief (for DOS), Jed, Emacs, Vim. I didn't know there were serious programming editors that didn't have that feature.

--
Grant Edwards                   grante             Yow!  RELAX!!... This
                                  at               is gonna be a HEALING
 Click to see the full signature
Reply to
Grant Edwards

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.

Robert

Reply to
Robert Adsett

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.

Andrew

Reply to
andrew queisser

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.

Reply to
Hans-Bernhard Bröker

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).

Couldn't agree more.

Reply to
andrew queisser

wrote: [...]

Ditto.

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).

Regards, -=Dave

Reply to
Dave Hansen

Do changes in one window get reflected in the other. When I checked an XML editor in Eclipse they did not.

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

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.

Reply to
Paul Taylor

JEdit also has this feature

Reply to
Paul Taylor

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.

Reply to
David Brown

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.

Reply to
David Brown

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 (*).

Andrew

Reply to
andrew queisser

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.