Oh PLEASE! Remove crappy forum "features"

Questions, comments, and suggestions about this site should go here.
ru2aqare
Member
Member
Posts: 342
Joined: Fri Jul 11, 2008 5:15 am
Location: Hungary

Re: Oh PLEASE! Remove crappy forum "features"

Post by ru2aqare »

JohnnyTheDon wrote:#define is also nice when you need to define a lot of numerical constants.
That can be done using the const modifiers. Any sane compiler will recognize it's a constant value, and will not generate a memory access for the variable, it will simply inline the value.
But I agree doing it with preprocessor macros looks nicer.
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re: Oh PLEASE! Remove crappy forum "features"

Post by Solar »

Code: Select all

#define MAX_BRAIN_CELLS 42

size_t const MAX_BRAIN_CELLS 42:

enum
{
    MAX_BRAIN_CELLS = 42;
}
The effect of the three is more or less identical. I prefer #2, because it's the only one that actually is straightforward and typesafe.
Every good solution is obvious once you've found it.
JohnnyTheDon
Member
Member
Posts: 524
Joined: Sun Nov 09, 2008 2:55 am
Location: Pennsylvania, USA

Re: Oh PLEASE! Remove crappy forum "features"

Post by JohnnyTheDon »

ru2aqare wrote:
JohnnyTheDon wrote:#define is also nice when you need to define a lot of numerical constants.
That can be done using the const modifiers. Any sane compiler will recognize it's a constant value, and will not generate a memory access for the variable, it will simply inline the value.
But I agree doing it with preprocessor macros looks nicer.
GCC isn't sane then. It exports the const variables, causing a bunch of multiple definitions. Also, when declaring global or stack arrays const variables cannot be used.
JJeronimo
Member
Member
Posts: 202
Joined: Wed Oct 18, 2006 3:29 pm

Re: Oh PLEASE! Remove crappy forum "features"

Post by JJeronimo »

JohnnyTheDon wrote:
ru2aqare wrote:
JohnnyTheDon wrote:#define is also nice when you need to define a lot of numerical constants.
That can be done using the const modifiers. Any sane compiler will recognize it's a constant value, and will not generate a memory access for the variable, it will simply inline the value.
But I agree doing it with preprocessor macros looks nicer.
GCC isn't sane then. It exports the const variables, causing a bunch of multiple definitions.
That they are exported doesn't mean they are not inlined in the current module. Also, to avoid that you can always declare them as static const (possibly in the header).
There's also a way I'm sure GCC inlines your constant. Inter-module analysis is achieved in GCC by feeding everything into it at once, and running with -O3 -fwhole-program -combine. Once, I did it on a university work and the boy inlined everything into a HUGE main(). I doubt this mass-inlining approach is always an intelligent optimization, however.
Also, when declaring global or stack arrays const variables cannot be used.
Did not remember that. In fact, in C this doesn't work.
However, in a modern language, you don't have to fear this limitation. In Java, you can put non-constant initializers in attributes (including static ones, afaik), and I guess you can do this in D and in C# either.

Alas, IMHO C has a very important role as a relatively low-level language, specially in operating system development (as all of you know). I think it would be a fairly good idea to redesign the language, not to bloat it and to add every imaginable feature, but just to modernize it. Removing that old header-inclusion scheme and that type-unsafe preprocessor, and instead rely on the compiler to optimize away unneeded code and function calls would help a lot. Adding namespaces and a template facility would also be a good idea.
Redesigning setjump/longjump in order to make it easer to implement threading libraries and SEH libraries without assembly code would be a good idea, too.
Personally, I don't like very much the C syntax. But killing would be a nasty idea. People love it. :-)

I don't think it would be easy, though. There are also a bunch on C dialects out there, and non of them has the goal of cleaning-up the original language, so I don't think there are many people inclined to this kind of redesign to the language.

JJ
JJeronimo
Member
Member
Posts: 202
Joined: Wed Oct 18, 2006 3:29 pm

Re: Oh PLEASE! Remove crappy forum "features"

Post by JJeronimo »

JohnnyTheDon wrote:That isn't allways true. There are some things (like conditional compilation) that can't be done w/o the preprocessor, at least not in a sane way.
I forgot to comment this.
This point, once again, should be done by the compiler. See: You create your static const value and then you employ and if() around the code that will be the subject of the conditional compilation.
At compile time, the static const gets inlined by the optimizer, which then observes that the if is always true/false and optimizes away the extra code.

If you are worried about legibility, then syntactic sugar could be used. There could be, for example, a capitalized IF() or a IFDEF(), semantically equivalent to if(), but intended to be used, by convention, for conditional compilation.

This solution has also the advantage that if you wanted, e.g., to compile a kernel that would use SSE instructions on machines supporting SSE, but would not crash on machine without SSE support, you could just remove the const and set the variable on initialization.

JJ
JohnnyTheDon
Member
Member
Posts: 524
Joined: Sun Nov 09, 2008 2:55 am
Location: Pennsylvania, USA

Re: Oh PLEASE! Remove crappy forum "features"

Post by JohnnyTheDon »

I think it would be a fairly good idea to redesign the language, not to bloat it and to add every imaginable feature, but just to modernize it.
This is what D tried to do. It actually declares itself as a systems programming language, but kind of falls short. IMHO, anything with a GC is going to be unreliable for systems programming, at least in the kernel.
User avatar
Firestryke31
Member
Member
Posts: 550
Joined: Sat Nov 29, 2008 1:07 pm
Location: Throw a dart at central Texas
Contact:

Re: Oh PLEASE! Remove crappy forum "features"

Post by Firestryke31 »

One feature I wish this forum had is to put any code above a certain size into it's own "frame" so that code dump posts aren't 6 miles long. It's really quite easy, just add "max-height: Xpx; overflow: auto" to the code tag's css/style. IIRC there were a few display problems getting it working on my site, though.
Owner of Fawkes Software.
Wierd Al wrote: You think your Commodore 64 is really neato,
What kind of chip you got in there, a Dorito?
User avatar
Love4Boobies
Member
Member
Posts: 2111
Joined: Fri Mar 07, 2008 5:36 pm
Location: Bucharest, Romania

Re: Oh PLEASE! Remove crappy forum "features"

Post by Love4Boobies »

This already happens.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
User avatar
Firestryke31
Member
Member
Posts: 550
Joined: Sat Nov 29, 2008 1:07 pm
Location: Throw a dart at central Texas
Contact:

Re: Oh PLEASE! Remove crappy forum "features"

Post by Firestryke31 »

Under which themes? It would be nice if the default theme did this to, as that's the one I prefer.
Owner of Fawkes Software.
Wierd Al wrote: You think your Commodore 64 is really neato,
What kind of chip you got in there, a Dorito?
JJeronimo
Member
Member
Posts: 202
Joined: Wed Oct 18, 2006 3:29 pm

Re: Oh PLEASE! Remove crappy forum "features"

Post by JJeronimo »

JohnnyTheDon wrote:
I think it would be a fairly good idea to redesign the language, not to bloat it and to add every imaginable feature, but just to modernize it.
This is what D tried to do. It actually declares itself as a systems programming language, but kind of falls short. IMHO, anything with a GC is going to be unreliable for systems programming, at least in the kernel.
The problem with that approach is, if you add GC, then you are adding a core feature (and in this case, it's a fairly expensive one).
No. I think a C replacement must be based on the same simplistic principles as C. Traditional procedural programming, minimalistic standard library, data manipulation similar to the asm programmer's usual approach (e.g. strings being just arrays of characters), minimalistic abstractions imposed by the language, no GC, classical pointers, no exceptions, no additional runtime support required for the basic language constructs apart from the usual stub that calls main(), easily optimizable for speed, etc. Additional features could then be added as extensions, or as a PlusPlus variant of the language, but the base being simple, while still fixing some of the longstanding C flaws.

About what I called "templates" in the last post, I meant something like "parametric namespaces", where the namespace could be "imported" and accessed with different parameters. Those parameters could be either integers or pointers. This would help implementing e.g. linked lists, because the compiler would just have to reserve the needed space where the parameter type is unknown at compile time.

JJ
Last edited by JJeronimo on Fri Jan 30, 2009 7:35 am, edited 1 time in total.
User avatar
Love4Boobies
Member
Member
Posts: 2111
Joined: Fri Mar 07, 2008 5:36 pm
Location: Bucharest, Romania

Re: Oh PLEASE! Remove crappy forum "features"

Post by Love4Boobies »

Firestryke31 wrote:Under which themes? It would be nice if the default theme did this to, as that's the one I prefer.
It works just fine for me under the default theme. Let's check again:

Code: Select all
























































EDIT: yep, it looks just fine here...
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
User avatar
Firestryke31
Member
Member
Posts: 550
Joined: Sat Nov 29, 2008 1:07 pm
Location: Throw a dart at central Texas
Contact:

Re: Oh PLEASE! Remove crappy forum "features"

Post by Firestryke31 »

Subsilver 2 doesn't. Relevant CSS:

Code: Select all

.codecontent {
	direction: ltr;
	margin: 0 5px 10px 5px;
	padding: 5px;
	border-color: #A9B8C2;
	border-width: 0 1px 1px 1px;
	border-style: solid;
	font-weight: normal;
	color: #006600;
	font-size: 0.85em;
	font-family: Monaco, 'Courier New', monospace;
	background-color: #FAFAFA;
}
Could be changed to:

Code: Select all

.codecontent {
	direction: ltr;
	margin: 0 5px 10px 5px;
	padding: 5px;
	border-color: #A9B8C2;
	border-width: 0 1px 1px 1px;
	border-style: solid;
	font-weight: normal;
	color: #006600;
	font-size: 0.85em;
	font-family: Monaco, 'Courier New', monospace;
	background-color: #FAFAFA;

	max-height: 400px;
	overflow: auto;
}
Edit: When I said "default" theme, I meant the one guests see, which is the one set when I registered.
Owner of Fawkes Software.
Wierd Al wrote: You think your Commodore 64 is really neato,
What kind of chip you got in there, a Dorito?
User avatar
Brynet-Inc
Member
Member
Posts: 2426
Joined: Tue Oct 17, 2006 9:29 pm
Libera.chat IRC: brynet
Location: Canada
Contact:

Re: Oh PLEASE! Remove crappy forum "features"

Post by Brynet-Inc »

It doesn't work on the MegaTokyo theme.. which, IMHO, should be the default. ;)
Image
Twitter: @canadianbryan. Award by smcerm, I stole it. Original was larger.
User avatar
AndrewAPrice
Member
Member
Posts: 2300
Joined: Mon Jun 05, 2006 11:00 pm
Location: USA (and Australia)

Re: Oh PLEASE! Remove crappy forum "features"

Post by AndrewAPrice »

There are times when the preprocessor is useful. I wrote an event system and I had a file called EVENTS.H which basically contained:

Code: Select all

DEFEVENT(MouseMove, (int x, int y))
DEFEVENT(MouseButtonDown, (int button))
DEFEVENT(MoseButtonUp, (int button))
// insert 50 or so relevant events
and each time I included EVENTS.H DEFEVENT(name, params) was defined to something different. (e.g. first time it would define fireMouseMove(int x, int y)), second time it would create an array of each object listening to that event, and third time it would create a virtual function called void onMouseMove(int x, int y)). A lot of other stuff was also preprocessed (register that the object listens for an event).

I'm sure there could have been a better way to do it, but it was designed to add/remove lots of events easily.
My OS is Perception.
earlz
Member
Member
Posts: 1546
Joined: Thu Jul 07, 2005 11:00 pm
Contact:

Re: Oh PLEASE! Remove crappy forum "features"

Post by earlz »

What about using the preprocessor to increase speed of the program, and ease on the developer?

I discovered the C preprocessor was capable of this nifty little thing earlier yesterday.

Code: Select all

#define PANIC(x)\
	epbp_panic(x,__FILE__,__FUNCTION__,__LINE__)
With this, I get where the panic occured in my code, and the code(x) for the panic. Before I knew of this, I had to either type that huge long line, or just use codes, which didn't tell me exact information.

the preprocessor is very handy in the hands of those that know how to use it. But, it can be easily abused too.

edit:
Is there any way to do this in your precious D? I didn't see any replacement for such a macro in that C preprocessor vs. D link...
Post Reply