Sepplesox General

Looks like there are many improvements to Sepples, but I'm not so sure that some of them are improvements. I'm going to use my post to go over some of these things that I think are downfalls.

Particularly, I'm not so sure that the inheritance specifiers are a good thing. The syntax is ugly, and like Bjarne says about the casts: Perhaps people would reconsider using them because they're so ugly.^[1] One of the major points FOR using Sepples is its inheritance system, so I'm not precisely certain what they hope to resolve with this particular addition.

The lambdas are ugly. The new string literals don't cover the primary problem with string handling: It's a pain to convert and support more than one type of string. The alternate function declaration syntax is... while necessary without creating something new entirely, I imagine that it's going to be more confusing than not, though that's probably more of a personal preference.

The rest of the features, I'm either indifferent to or like, though remanding concepts to a technical report was a bad call, imo.

^{[1] - http://www2.research.att.com/~bs/bs_faq2.html#static-cast}

I'd rather use PHP.

Why do they keep calling it C++0x?

If it's not going to be C++09, then aren't we supposed to call it C++1x?

>>3
C++0xA

pantsu

>>4
I like the way you think.

I always understood C++0x to be a temporary name. It's a dumb name.

>>4
NOW YOUR THINKING IN HEXADECIMAL

>>6
C++ is a dumb name too. Didn't stop the Bjarne.

2010 will be the year of C++0x.

>>3
lol the solution is like 3 lines if youre a recursive expert.

>>10
wat

>>8
c++; //makes c bigger but returns old value

C++ could be improved by:

– Loosening the requirement that references be nonnnull
– Modifying the syntax so that x =(T)y produces the same code as x = dynamic_cast<T>(y)
– Requiring all functions to be defined inside a namespace, and enforcing, at compile-time, a 1:1 correspondence between the namespace hierarchy and directory/source-file hierarchy.
– Removing C array support and making int *n = new int[3]; an alias for vector<int> n = new vector<int>(3);
- Similarly, making the literal "lol" a const string rather than const char *

>>13
I like the sound of most of these. Would fap again.

>>13
– Requiring all functions to be defined in a namespace, and enforcing, at compile-time, a 1:1 correspondence between the namespace hierarchy and directory/source-file hierarchy.
Uhm. No thanks. I like that I'm not tied and bound to such restrictive packaging mechanisms and the fact that I can logically lay out the files differently than the physical layout.

– Modifying the syntax so that x =(T)y produces the same code as x = dynamic_cast<T>(y)
(T) y already does all the casting functions that Sepples added. They introduced the new casting syntax to clarify your intent, make optimization opportunities, and discourage the use of casting through making it painful to type.

Literals should be const string, I agree, though I think that comes with some costs and one of the stated design goals of Sepples is to not incur unnecessary costs to the program. I should think this could be optimized in an ideal implementation, but I'm not an expert on compiling.

For null references, do you suggest that they introduce something similar to nullptr except for references? Something like nullref? That would actually be pretty nice.

C arrays are the right tool for the job occasionally. Why would you want to remove support for them completely? Writing a wrapper class like boost::array would be common and may as well be in the standard library if you remove C arrays, in which case, you still have arrays. I don't see the point of removing support.

>>13
forced vector overhead
forced to use STL strings, which are nasty for several use cases
make references even more like pointers
-9001/10

Have fun trying to program an AVR with that.

– The compiler shouldn't generate a default copy constructor, nor default assignment operator. Invoking either of those when they haven't been provided explicitly by the user should generate a compilation error.

– The cognitive complexity introduced by references is not worth the benefit.

>>16
STL strings are primarily garbage for repeated concatenation, which wouldn't happen in the context of const strings.

>>17
Strong primary point.

>>17
I agree with this.
Although changing either is out of the question. It would be a compatibility nightmare.

>>19
It would make a nice #pragma, though... one you'd have to type like,
#pragma I_LIKE_LOW_LEVEL_CODING_OTHER_GUYS_ARE_FAGS_BUT_I_DO_NOT_WANT_TO_MAKE_MY_OWN_DESTRUCTOR_WHICH_IS_NOT_HYPOCRITICAL_OF_ME_AND_A_BRILLIANT_FEATURE_THANKS_BJARNE

>>20
EXPERT GENIUS

Some of the new stuff in sepplesox is good. For example a range based for loop, bounds-checked std::array, etc. Things that should have been there for decades of course, but I won't complain about them. Other things are nice; for instance I never really considered the language complete without move semantics, and a few object model features are very useful (such as larger scope of pod types and unions, constructor chaining, etc). Also proper enums are great, except they left regular enums as broken instead of changing them back into their C counterparts so we could use them for bitmasks again.

Threading and a proper memory model is nice, but I don't really see it as something vendors will implement any time soon (as in not for a good 10 years). Someone will write the easy bits as an open library wrapping the native threading API, and the features that require actual compiler support will fall by the wayside, never to be used. (Example: Capturing and propagating exceptions across threads, so that accessing e.g. a future will throw the transferred exception. What the fuck?)

The lambdas are also really dumb. Why the ridiculous syntax? What's wrong with lambda or function? Also, why the fuck do I have to declare the variables I'm closing the function over to create a closure? Didn't Algol solve this 60 years ago?

Meanwhile C99 features are still outright missing. Variadic templates are nice; where are variadic macros? Variable length arrays? Where is restrict?

After that it goes past crazy and gets into the downright bizzare. The biggest WTF: User-defined non-string literals by overriding operator"" as a variadic template of char parameters. What the fucking fuck? Who thought that was a good idea? What the fuck is the problem with a regular inline constructor that takes a string. You really want to get variadic template arguments instead of a *string* just to hope the compiler optimizes it better?

Honestly, I swear Stroustrup just piles in anything anyone ever dreamt of as a feature. Forcing all vendors to implement this bullshit feature no one will ever use, and meanwhile actual useful things like garbage collection get pushed out of the standard.

And as usual, the biggest problem with C++ grows ever worse: Of course you ignore those features that are dumb, you only use the 10% that are useful to you... until you need to combine it with someone else's code and you realize, everyone has a different 10%.

>>22
original content. why did i bother with this shit?

>>22
I really do like the enum stuff, though I should think you also still have the ability to do:

enum class X {
    X,
    Y,
    Z = X | Y
};

// ...
X value;
// ...
if (value & X::X) {

}
If that's what you mean, I don't see how things have changed?

>>22
10/10 I appreciated

>>22
User-defined non-string literals by overriding operator"" as a variadic template of char parameters.
Oh man I am so switching to Sepplesocks right now.

Holy shit. I've been reading about Sepplesox in Wikipedia and everywhere else, and it's PLAIN FUCKING RIDICULOUS.

>>27
What did you expect from a plain fucking ridiculous language?

/prog/ will be spammed continuously until further notice. we apologize for any inconvenience this may cause.